-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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
bpo-29463: Add docstring field to some AST nodes. #46
Conversation
Doc/library/ast.rst
Outdated
|
||
.. versionchanged:: 3.7 | ||
The docstring is exported from attribute of the node, instead of first | ||
statement in it's body. |
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.
of its body
16facf2
to
e7ec3c1
Compare
Codecov Report
@@ Coverage Diff @@
## master #46 +/- ##
==========================================
- Coverage 82.37% 82.37% -0.01%
==========================================
Files 1427 1427
Lines 350948 350806 -142
==========================================
- Hits 289089 288970 -119
+ Misses 61859 61836 -23 Continue to review full report at Codecov.
|
ClassDef, ModuleDef, FunctionDef, and AsyncFunctionDef has docstring field for now. It was first statement of there body.
e7ec3c1
to
7666aaf
Compare
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.
Just a minor nit, not a blocker one.
Doc/library/ast.rst
Outdated
|
||
.. versionchanged:: 3.7 | ||
The docstring is exported from attribute of the node, instead of first | ||
statement of its body. |
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.
Sorry, the doc still sounds strange to me. I propose:
The docstring is now exported from the node docstring
field, instead of the first body statement.
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.
thanks. In above, I feel "AsyncFunctionDef is added" wrong too. How do you think?
Added :class:`AsyncFunctionDef` support
:class:`AsyncFunctionDef` is supported now
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.
Ah, you're right:
:class:AsyncFunctionDef
is now supported.
Thanks for the last documentation fix ;-) Nice enhancement, it should help to make AST code simpler! |
Thanks for this ! Improvement to the AST are welcome ! Would it have been possible to make the docstring optional ? (It's already breaking things, like IPython). Should I comment on upstream bpo ? |
@Carreau Yes, please discuss on bpo. Merged pull request is not good place to discussion, |
I created http://bugs.python.org/issue29622 |
Thanks @Haypo, responded and subscribed to both. |
python/cpython#46 or bpo-29463 added docstring as a property to the module class that comes out of AST (so the free strings no longer appear an the first element in the parsed files).
python/cpython#46 or bpo-29463 added docstring as a property to the module class that comes out of AST (so the free strings no longer appear an the first element in the parsed files).
python/cpython#46 / https://bugs.python.org/issue29463 move the module comment into the AST node and hence out of the tree which means the 2nd entry in the tree is now the import rather than the `__version__` string. Adds nightly on travis.
* FIX: install on python 3.7 python/cpython#46 / https://bugs.python.org/issue29463 move the module comment into the AST node and hence out of the tree which means the 2nd entry in the tree is now the import rather than the `__version__` string. Adds nightly on travis. * BLD: update python tags in setup.py * CI: switch to 3.7-dev * CI: allow failure on 3.7 dev
* Pin pytest to latest version 3.3.2 * Pin pytest-asyncio to latest version 0.8.0 * Pin pytest-aiohttp to latest version 0.3.0 * Update cherry_picker from 0.2.5 to 0.2.7 * Pin aiohttp to latest version 2.3.9 * Pin gidgethub to latest version 2.4.1 * Pin cachetools to latest version 2.0.1 * Pin requests to latest version 2.18.4 * Pin redis to latest version 2.10.6 * Pin celery to latest version 4.1.0 * Comment out python 3.7 from travis CI
Bump version number Closes python#46
Update pyproject.toml and setup.py Closes python#46 See merge request python-devs/importlib_resources!47
…sprint test: Fix fstring related tests in test_tokenize.py
Co-authored-by: Ken Jin <kenjin4096@gmail.com>
Email generators had been incorrectly flattening non-ASCII email addresses to RFC 2047 encoded-word format, leaving them undeliverable. (RFC 2047 prohibits use of encoded-word in an addr-spec.) This change raises a ValueError when attempting to flatten an EmailMessage with a non-ASCII addr-spec and a policy with utf8=False. (Exception: If the non-ASCII address originated from parsing a message, it will be flattened as originally parsed, without error.) Non-ASCII email addresses are supported when using a policy with utf8=True (such as email.policy.SMTPUTF8) under RFCs 6531 and 6532. Non-ASCII email address domains (but not localparts) can also be used with non-SMTPUTF8 policies by encoding the domain as an IDNA A-label. (The email package does not perform this encoding, because it cannot know whether the caller wants IDNA 2003, IDNA 2008, or some other variant such as UTS python#46.)
Email generators had been incorrectly flattening non-ASCII email addresses to RFC 2047 encoded-word format, leaving them undeliverable. (RFC 2047 prohibits use of encoded-word in an addr-spec.) This change raises a ValueError when attempting to flatten an EmailMessage with a non-ASCII addr-spec and a policy with utf8=False. (Exception: If the non-ASCII address originated from parsing a message, it will be flattened as originally parsed, without error.) Non-ASCII email addresses are supported when using a policy with utf8=True (such as email.policy.SMTPUTF8) under RFCs 6531 and 6532. Non-ASCII email address domains (but not localparts) can also be used with non-SMTPUTF8 policies by encoding the domain as an IDNA A-label. (The email package does not perform this encoding, because it cannot know whether the caller wants IDNA 2003, IDNA 2008, or some other variant such as UTS python#46.)
Email generators had been incorrectly flattening non-ASCII email addresses to RFC 2047 encoded-word format, leaving them undeliverable. (RFC 2047 prohibits use of encoded-word in an addr-spec.) This change raises a ValueError when attempting to flatten an EmailMessage with a non-ASCII addr-spec and a policy with utf8=False. (Exception: If the non-ASCII address originated from parsing a message, it will be flattened as originally parsed, without error.) Non-ASCII email addresses are supported when using a policy with utf8=True (such as email.policy.SMTPUTF8) under RFCs 6531 and 6532. Non-ASCII email address domains (but not localparts) can also be used with non-SMTPUTF8 policies by encoding the domain as an IDNA A-label. (The email package does not perform this encoding, because it cannot know whether the caller wants IDNA 2003, IDNA 2008, or some other variant such as UTS python#46.)
Email generators had been incorrectly flattening non-ASCII email addresses to RFC 2047 encoded-word format, leaving them undeliverable. (RFC 2047 prohibits use of encoded-word in an addr-spec.) This change raises a ValueError when attempting to flatten an EmailMessage with a non-ASCII addr-spec and a policy with utf8=False. (Exception: If the non-ASCII address originated from parsing a message, it will be flattened as originally parsed, without error.) Non-ASCII email addresses are supported when using a policy with utf8=True (such as email.policy.SMTPUTF8) under RFCs 6531 and 6532. Non-ASCII email address domains (but not localparts) can also be used with non-SMTPUTF8 policies by encoding the domain as an IDNA A-label. (The email package does not perform this encoding, because it cannot know whether the caller wants IDNA 2003, IDNA 2008, or some other variant such as UTS python#46.)
Email generators had been incorrectly flattening non-ASCII email addresses to RFC 2047 encoded-word format, leaving them undeliverable. (RFC 2047 prohibits use of encoded-word in an addr-spec.) This change raises a ValueError when attempting to flatten an EmailMessage with a non-ASCII addr-spec and a policy with utf8=False. (Exception: If the non-ASCII address originated from parsing a message, it will be flattened as originally parsed, without error.) Non-ASCII email addresses are supported when using a policy with utf8=True (such as email.policy.SMTPUTF8) under RFCs 6531 and 6532. Non-ASCII email address domains (but not localparts) can also be used with non-SMTPUTF8 policies by encoding the domain as an IDNA A-label. (The email package does not perform this encoding, because it cannot know whether the caller wants IDNA 2003, IDNA 2008, or some other variant such as UTS python#46.)
ClassDef, ModuleDef, FunctionDef, and AsyncFunctionDef has docstring
field for now. It was first statement of there body.