create week5 and 6 repo and notes

[LeoLin2115]

Important

Add educational notes on Python basics and advanced functions in Leo_note.md for weeks 5 and 6.

• Files Added:
  • week_05_basics/Leo_note.md: Notes on tuples, sets, and basic functions in Python.
  • week_06_basic/Leo_note.md: Notes on advanced function concepts like lambda, closures, and generators.
• Content Summary:
  • Week 5 covers tuples (immutable, single-element syntax) and sets (operations like intersection, union, difference).
  • Week 5 also introduces basic function syntax, scope rules (LEGB), and variable access (global, nonlocal).
  • Week 6 discusses expressions vs. statements, lambda expressions, map/filter functions, closures, decorators, and generators.

^{This description was created by for f1167f0. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to f1167f0 in 1 minute and 47 seconds. Click for details.

• Reviewed 82 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 12 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. week_05_basics/Leo_note.md:10

• Draft comment:
  Typo: 'date2' should be 'data2'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is a real typo, this is a personal notes file, not actual code. The typo doesn't affect functionality since this is just documentation. The meaning is still clear despite the typo. Comments about typos in documentation are generally not valuable enough to include. The typo could be confusing to other readers of these notes, especially since this is educational material. Consistency in variable names is important for learning. While consistency is good, this is clearly a personal notes file (titled "Leo_note.md") and the typo is minor enough that the meaning remains clear from context. Delete this comment as it's a minor documentation typo in what appears to be personal notes, not production code.

2. week_05_basics/Leo_note.md:31

• Draft comment:
  Clarify expected output: consider using a code snippet (e.g., print('Python')) rather than the phrase 'print out Python'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This appears to be someone's personal study notes, mixing natural language with code examples. The current format using "print out Python" is clear enough in context - it's describing the output rather than showing exact code. Making it more code-like isn't necessarily better since this is documentation/notes rather than actual code. The informal style is fine for notes. The suggestion would make the notes more technically precise. It could help maintain consistency with other code examples in the file. While technically more precise, enforcing strict code syntax in personal notes is overly pedantic and doesn't meaningfully improve understanding. Delete the comment. This is a stylistic suggestion for personal notes where the current natural language description is perfectly clear.

3. week_05_basics/Leo_note.md:43

• Draft comment:
  Clarify expected output: consider using a code snippet (e.g., print('Ruby')) rather than 'print out Ruby'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a personal note file, not production code. The current format "print out Ruby" is clearly meant as explanatory text describing the output, not actual code. While using code formatting might be more precise, this is a matter of documentation style preference rather than a technical issue requiring correction. The suggestion would make the notes more consistent with code formatting. It could help prevent confusion between explanatory text and actual code examples. However, this is a personal notes file where the current format adequately conveys the meaning. The suggestion is more about style than substance and doesn't identify a real problem. Delete the comment as it's a purely stylistic suggestion for documentation that doesn't identify a significant issue requiring change.

4. week_06_basic/Leo_note.md:1

• Draft comment:
  The heading 'Week5' does not match the directory (week_06). Consider updating it to 'Week6'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a notes file, likely for personal use. The week number mismatch is minor and doesn't affect functionality. The rules state not to make purely informative comments or comments that are obvious/unimportant. This seems like a trivial formatting issue that doesn't require a code change. The week number inconsistency could potentially cause confusion for other students or instructors using these notes. It might be worth fixing for clarity. While consistency is nice, this is a personal notes file and the week number mismatch doesn't impact functionality or code quality. The rules explicitly say not to make purely informative comments. The comment should be deleted as it's purely informative and doesn't address any significant code issues.

5. week_06_basic/Leo_note.md:4

• Draft comment:
  Typo: 'Lambda experssion' should be 'Lambda expression'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a personal notes file, not production code. The typo doesn't affect functionality. The rules state not to make purely informative comments or obvious/unimportant ones. Spelling corrections in documentation/notes, while technically correct, don't require action unless they affect understanding. The spelling error could potentially confuse other readers of these notes. Documentation quality is important for learning materials. While documentation quality matters, this is clearly a personal note file (titled "Leo_note.md") and the meaning is still clear despite the typo. The comment doesn't add significant value. Delete this comment as it's purely informative and points out a minor spelling issue in what appears to be personal notes.

6. week_06_basic/Leo_note.md:13

• Draft comment:
  Typo: 'vairalbe' should be 'variable' and consider rephrasing to 'cell object points to the variable'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a new file being added, so the changes are part of the diff. However, these are personal notes (evidenced by the filename 'Leo_note.md') rather than official documentation. The typo doesn't impact code functionality. Comments about spelling/grammar in personal notes are not particularly valuable and could be seen as nitpicking. Personal notes might be shared with others later or used as reference material, so clarity could be important. The current text is somewhat confusing. While clarity is good, these appear to be informal personal notes. We should respect that not all documentation needs to be perfect, especially private notes. The comment should be deleted as it's nitpicking grammar/spelling in what appears to be personal notes rather than addressing a substantive code or documentation issue.

7. week_06_basic/Leo_note.md:16

• Draft comment:
  Typo: 'Genarator' should be 'Generator'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the spelling error, this appears to be a personal notes file. The spelling mistake doesn't impact code functionality. The rules specifically say not to make purely informative comments and to only comment when there's clearly a code change required. The spelling error could make the notes less useful as a reference material. It could be argued that maintaining correct technical terminology is important. However, this is clearly a personal notes file, not production code or documentation. The meaning is still clear despite the typo, and fixing spelling in personal notes is not a valuable use of code review. The comment should be deleted as it's purely informative and doesn't impact functionality. It violates the rule about only commenting when there's clearly a code change required.

8. week_06_basic/Leo_note.md:17

• Draft comment:
  Consider formatting the generator example as a proper code block with correct indentation.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a personal notes file, not production code. The file appears to be informal study notes. While the indentation is technically incorrect, suggesting formatting changes on personal notes feels overly pedantic and doesn't align with our review guidelines about only commenting on important issues that require code changes. The code indentation is genuinely incorrect from a Python syntax perspective, and proper formatting could help with readability and learning. However, this appears to be a personal notes file for learning purposes, not production code. Our guidelines specifically say not to make purely informative comments or obvious suggestions. The comment should be deleted as it's a purely formatting suggestion on a personal notes file, which doesn't meet our bar for required code changes.

9. week_05_basics/Leo_note.md:10

• Draft comment:
  Typo on line 10: 'date2' is likely a typo and should be 'data2' in the description of the set difference.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the typo, this is a personal notes file, not actual code. The typo doesn't affect functionality since it's just in explanatory text. The rules state we should only comment if there's clearly a code change required. Documentation/notes typos generally don't meet this threshold. The typo could potentially confuse future readers of these notes. Also, since this is a new file, all changes are technically "changes in the diff". While true, these appear to be personal study notes, not official documentation. The meaning is still clear from context, and fixing documentation typos isn't a critical code review concern. Delete the comment. While it points out a real typo, commenting on documentation typos in personal notes falls outside the scope of what code review comments should focus on.

10. week_06_basic/Leo_note.md:4

• Draft comment:
  Typo detected: 'experssion' on line 4 should be corrected to 'expression'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a personal notes file, not production code. The typo doesn't affect functionality. While the comment is technically correct about the misspelling, fixing typos in personal notes is not a critical code quality issue. This seems more like nitpicking than a valuable code review comment. The typo could make the notes harder to read or search for later. It's also good practice to maintain correct spelling in all files in a repository. While correct spelling is good, this is clearly a personal notes file and the meaning is still clear despite the typo. The comment doesn't improve code quality or functionality. Delete this comment as it's too minor and doesn't affect code quality or functionality. Personal notes don't need this level of spelling scrutiny.

11. week_06_basic/Leo_note.md:13

• Draft comment:
  Typographical error: 'vairalbe' on line 13 should be corrected to 'variable'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a documentation/notes file, not code. The typo doesn't affect functionality. The rules state we should focus on logic issues, not purely informative comments. While the comment is technically correct about the typo, fixing typos in personal notes isn't a critical code review concern. The typo could make the notes harder to read or understand for other team members. Documentation quality is important for maintainability. While documentation quality matters, this appears to be a personal note file (named "Leo_note.md") rather than official documentation. The rules explicitly state not to make purely informative comments. The comment should be deleted as it's purely informative and doesn't affect code logic or functionality.

12. week_06_basic/Leo_note.md:16

• Draft comment:
  Typo detected: 'Genarator' on line 16 should be corrected to 'Generator'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a new file being added. The typo is real - "Genarator" is definitely misspelled. However, this appears to be a personal notes file, not production code. The typo doesn't affect functionality and is in what appears to be informal study notes. The rules say not to make purely informative comments or obvious/unimportant ones. The typo could make the notes harder to read or search for later. It's technically a valid correction. While technically correct, fixing typos in personal study notes is not an important code quality issue that requires addressing in a PR review. This comment should be deleted as it's a minor spelling correction in what appears to be personal notes, not production code that affects functionality.

Workflow ID: wflow_1M9kIutQZEM8WSvG

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Typo on line 5: Consider replacing 'common' with 'comma' in the phrase "if only one element in tuple you have to add common tuple = (element,)".

Suggested change

	3. if only one element in tuple you have to add common tuple = (element,)
	3. if only one element in tuple you have to add comma tuple = (element,)