-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[New Concept]: Decorators #2838
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar suggestion for vertical white space, though, of course, there is only one EOL missing at the end of the file.
Instead of the merge of main into this branch, it would be better to rebase this branch onto main. Feel free to do a force push to this branch as well, it is yours to work with. |
@kotp git checkout decorators
git rebase main |
e1f6969
to
80ca0df
Compare
Hi! I have got to the point of returning a different function in decorators, and am struggling to decide how to introduce it. Edit: Having once again read the RealPython article linked in #2356 I have an idea as to what to do. I will attempt to write it and will commit for feedback once done! |
On 22/01/06 01:52AM, mathstrains21 wrote:
> Instead of the merge of main into this branch, it would be better to rebase this branch onto main. Feel free to do a force push to this branch as well, it is yours to work with.
@kotp
For rebasing can I confirm that this is what I should do:
```cmd
git checkout decorators
git rebase main
```
You might want to make sure that main is fetched. I usually do:
```
git fetch --all
git checkout decorators
git rebase origin/main
```
You could checkout main and do a `git pull origin main` and then do your
two steps, results are the same.
|
ec61cf4
to
ca00367
Compare
Is there any tool we are using that will validate the python code in code blocks? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, I think this needs some re-arranging for clarity. I'd also suggest dividing the decorator examples into categories -- so that you have an explicitly titled section for (these are just quick examples - not requests) decorators that take arguments
and decorators that extend behavior
vs decorators that change behavior
or decorators that register
, etc.
I also think this topic is complex enough that having real-world examples to anchor need/understanding is helpful. So while a few simple examples are good in the ramp-up, something like building up to the logging decorator Aaron Maxwell describes here I think would really help students understand the power of what they can do with them.
Apologies, @mathstrains21 - I didn't see your comment from yesterday until just now, so my comments are for the whole thing, and not that particular section. 😱 I agree that the first example should be without I did link to additional articles and authors that I think have some good decorator examples, but rather than have you plow through all the review comments, I will also just link them here: David Beazley, in his Practical Python Programming course: function decorators |
An additional article from Dan Bader, that has a good structure, I think: python-decorators |
On Fri, Jan 7, 2022 at 12:18 PM mathstrains21 ***@***.***> wrote:
Is there any tool we are using that will validate the python code in code
blocks?
—
Reply to this email directly, view it on GitHub
<#2838 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABNGCFUCVQEP5WPF4XK427DUU5C7VANCNFSM5LE7B2AQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because your review was requested.Message ID:
***@***.***>
Apologies, This note is not showing on the GH comments for the PR, so it
got buried in my email notifications.
Currently, no - we don't have a specific tool. Do you have any
suggestions? I have a note on my to do list to figure out a tool for this
and incorporate it as part of our CI -- but haven't had the time to really
investigate.
-Bethany
Edited to add the following links/packages I found and am considering trying out.
The last one looks pretty promising:
[doctest](https://docs.python.org/3/library/doctest.html)
[mkcodes](https://github.com/ryneeverett/mkcodes)
[pmdoctest](https://tmarktaylor.github.io/phmdoctest/)
|
On 22/01/07 12:18PM, mathstrains21 wrote:
Is there any tool we are using that will validate the python code in code blocks?
I am not sure how to take the question, but I use an editor that I can
focus on the block, set the file type to python, and can get syntax
highlighting, and linting.
|
Ok! That is roughly what I am doing anyway! |
Have looked through your review, will review it in more detail this afternoon and start doing the rearranging! |
ca00367
to
0ce5a0b
Compare
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
Co-authored-by: BethanyG <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requested change is the "decorater" typo. Others are suggestions, are, well, suggestive.
concepts/decorators/about.md
Outdated
pass | ||
``` | ||
|
||
If a decorator has defined default arguments, you must use parenthesis in the `@decorator()` call for the decorator to work: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? We might want to explain what the problem is being presented to the parser when there is no parenthesis. Or pose it as a "Getting to Deep Dive Python" point…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Next commit will include , as you would in calling any function:
concepts/decorators/about.md
Outdated
It could be coded to raise a `ValueError` instead. | ||
So, the inner function wraps `func`, and returns either `func` or does something that substitutes what `func` would do. | ||
The decorator returns its _inner function_. | ||
It does not _directly_ return the original, passed-in function. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This suggests that it either must or may return the original passed in function indirectly. This could be clarified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The last line will be changed in the next commit to
The inner_function may or may not return the original, passed-in function.
concepts/decorators/about.md
Outdated
So, the inner function wraps `func`, and returns either `func` or does something that substitutes what `func` would do. | ||
The decorator returns its _inner function_. | ||
It does not _directly_ return the original, passed-in function. | ||
Depending on what happens in the wrapper function, `func` may or may not be returned. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not, for me, clarify the prior sentence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole paragraph will be rephrased in the next commit to
The inner function returns either func
or, if planet
equals Pluto
, it will print that Pluto is not a planet.
It could be coded to raise a ValueError
instead.
So, the inner function wraps func
, and returns either func
or does something that substitutes what func
would do.
The decorator returns its inner function.
The inner_function may or may not return the original, passed-in function.
Depending on what code conditionally executes in the wrapper function or inner_function, func
may be returned, an error could be raised, or a value of func
's return type could be returned.
It states and then repeats itself to hopefully be more reinforcing than obfuscatory.
Co-authored-by: Victor Goff <[email protected]>
Co-authored-by: Victor Goff <[email protected]>
Co-authored-by: Victor Goff <[email protected]>
Co-authored-by: Victor Goff <[email protected]>
@kotp Thank you for your substantive observations! Please let me know if I have not addressed them successfully. |
... | ||
>>> my_func("Pluto") | ||
Entering my_func with Pluto argument | ||
Pluto is not a planet! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adds concept / concept exercise for #2356. This is in a WIP state and is up for any feedback to come in earlier!
Notes:
In line with the above, should I be basing code samples off 3.8 or 3.9? (I assume when the track updates code samples would have to be updated to)
I will edit this as I add things that are useful to note and when I mark this PR as ready for review!