Skip to content
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

Merged
merged 3 commits into from
Feb 22, 2017

Conversation

methane
Copy link
Member

@methane methane commented Feb 12, 2017

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

@methane methane added the type-feature A feature request or enhancement label Feb 12, 2017

.. versionchanged:: 3.7
The docstring is exported from attribute of the node, instead of first
statement in it's body.
Copy link
Member

Choose a reason for hiding this comment

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

of its body

@codecov
Copy link

codecov bot commented Feb 12, 2017

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.
Copy link
Member

@vstinner vstinner left a 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.


.. versionchanged:: 3.7
The docstring is exported from attribute of the node, instead of first
statement of its body.
Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

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.

@vstinner vstinner merged commit cb41b27 into python:master Feb 22, 2017
@vstinner
Copy link
Member

Thanks for the last documentation fix ;-)

Nice enhancement, it should help to make AST code simpler!

@Carreau
Copy link
Contributor

Carreau commented Feb 22, 2017

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 ?

@methane methane deleted the ast-docstring branch February 22, 2017 16:31
@methane
Copy link
Member Author

methane commented Feb 22, 2017

@Carreau Yes, please discuss on bpo. Merged pull request is not good place to discussion,
because it's too hard to search.

@vstinner
Copy link
Member

Would it have been possible to make the docstring optional ? (It's already breaking things, like IPython).

I created http://bugs.python.org/issue29622

@Carreau
Copy link
Contributor

Carreau commented Feb 22, 2017

Thanks @Haypo, responded and subscribed to both.

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
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.
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
@gvanrossum gvanrossum mentioned this pull request Apr 10, 2022
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
Bump version number

Closes python#46
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.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants