bpo-29463: Add docstring field to some AST nodes. by methane · Pull Request #46 · python/cpython (original) (raw)

ClassDef, ModuleDef, FunctionDef, and AsyncFunctionDef has docstring
field for now. It was first statement of there body.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

of its body

Codecov Report

Merging #46 into master will decrease coverage by -0.01%.
The diff coverage is 100%.

@@ 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.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2294f3a...e7ec3c1. Read the comment docs.

ClassDef, ModuleDef, FunctionDef, and AsyncFunctionDef has docstring field for now. It was first statement of there body.

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.

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.

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

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,
because it's too hard to search.

Thanks @Haypo, responded and subscribed to both.

myint mentioned this pull request

May 14, 2017

myint mentioned this pull request

May 28, 2017

tacaswell added a commit to tacaswell/sphinx-gallery that referenced this pull request

Jul 9, 2017

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).

tacaswell added a commit to tacaswell/sphinx-gallery that referenced this pull request

Aug 5, 2017

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).

tacaswell added a commit to tacaswell/jedi that referenced this pull request

Oct 23, 2017

davidhalter pushed a commit to davidhalter/jedi that referenced this pull request

Nov 6, 2017

• 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

iritkatriel referenced this pull request in iritkatriel/cpython

Jul 22, 2021

jaraco pushed a commit that referenced this pull request

Dec 2, 2022

• 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

jaraco pushed a commit to jaraco/cpython that referenced this pull request

Feb 17, 2023

jaraco pushed a commit to jaraco/cpython that referenced this pull request

Feb 17, 2023

Update pyproject.toml and setup.py

Closes python#46

See merge request python-devs/importlib_resources!47

isidentical referenced this pull request in isidentical/cpython

Mar 25, 2023

…sprint

test: Fix fstring related tests in test_tokenize.py

oraluben pushed a commit to oraluben/cpython that referenced this pull request

Jun 26, 2023

Co-authored-by: Ken Jin kenjin4096@gmail.com

medmunds added a commit to medmunds/cpython that referenced this pull request

Aug 1, 2024

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.)

medmunds added a commit to medmunds/cpython that referenced this pull request

Aug 1, 2024

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.)

medmunds added a commit to medmunds/cpython that referenced this pull request

Aug 1, 2024

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.)

medmunds added a commit to medmunds/cpython that referenced this pull request

Aug 1, 2024

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.)

medmunds added a commit to medmunds/cpython that referenced this pull request

Aug 1, 2024

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.)

This was referenced

Feb 11, 2025