PEP 844: public and private builtins - #5079
Conversation
Documentation build overview
11 files changed ·
|
| Acknowledgements | ||
| ================ | ||
|
|
||
| Thanks to Peter Bierma and Neil Girdhar, whose :pep:`842` and PEP 843 prompted this proposal, and to |
There was a problem hiding this comment.
Even if PEP 843 PR is not merged yet, it would be better to use a link:
| Thanks to Peter Bierma and Neil Girdhar, whose :pep:`842` and PEP 843 prompted this proposal, and to | |
| Thanks to Peter Bierma and Neil Girdhar, whose :pep:`842` and :pep:`843` prompted this proposal, and to |
There was a problem hiding this comment.
I can't apply this one until 843 is actually published, otherwise the build fails. I have a TODO to clean these up.
There was a problem hiding this comment.
Oh, I didn't know that it emits an error. So it makes sense to not add a link yet!
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
ZeroIntensity
left a comment
There was a problem hiding this comment.
I caught a few grammatical issues, but otherwise this looks good. It'd be good to get this up soon so people can share thoughts on it in contrast to the new 842 revision.
| Motivation | ||
| ========== | ||
|
|
||
| The :attr:`module global variable <module.__all__>` ``__all__`` is the mechanism Python currently |
There was a problem hiding this comment.
This looks weird in the output because "module global variable" is rendered as code. I suggest doing this:
| The :attr:`module global variable <module.__all__>` ``__all__`` is the mechanism Python currently | |
| The module global variable :attr:`~module.__all__` is the mechanism Python currently |
|
|
||
| :pep:`842` gives two reasons why ``__all__`` is inadequate. The first is that ``__all__`` drifts | ||
| out of sync with the module. That is true, and it is precisely the problem ``atpublic`` and this | ||
| PEP solves. However a *new list of string literals in the same distant part of the file* does not |
There was a problem hiding this comment.
- The subject here is plural, so it should be "solve" instead of "solves".
- "However" needs a trailing comma.
| PEP solves. However a *new list of string literals in the same distant part of the file* does not | |
| PEP solve. However, a *new list of string literals in the same distant part of the file* does not |
|
|
||
| ``Widget`` is named once to import it, and twice more to export it. That's a big violation of DRY! | ||
| Hand-maintaining ``__all__`` would name it only twice, so for re-exports specifically, ``public()`` | ||
| is not merely unhelpful, it is a step backwards. |
There was a problem hiding this comment.
Comma splice:
| is not merely unhelpful, it is a step backwards. | |
| is not merely unhelpful; it is a step backwards. |
or:
| is not merely unhelpful, it is a step backwards. | |
| is not merely unhelpful, but rather it is a step backwards. |
|
|
||
| The conclusion is that the data and type alias use cases, which are the places a decorator | ||
| genuinely cannot be utilized, do not require new syntax at all. They require a function call that | ||
| tools can learn to read, alleviating the need for a dedicated, new ``export`` keyword. |
There was a problem hiding this comment.
"Alleviating" feels awkward here; you alleviate a problem, not a solution. Maybe "removing" instead?
| tools can learn to read, alleviating the need for a dedicated, new ``export`` keyword. | |
| tools can learn to read, removing the need for a dedicated, new ``export`` keyword. |
| gained over the decade of ``atpublic``'s existence that requiring a third-party dependency (or an | ||
| import at the top of every module) to spell something this fundamental is friction that discourages | ||
| its use. It is also awkward in exactly the places where it matters most: the standard library | ||
| itself, and small single file modules. |
There was a problem hiding this comment.
This needs a hyphen:
| itself, and small single file modules. | |
| itself, and small single-file modules. |
| tools can learn to read, alleviating the need for a dedicated, new ``export`` keyword. | ||
|
|
||
|
|
||
| .. _pep-844-urgency: |
| module-level objects may be decorated. Decorating a method inside a class body is not supported, | ||
| since ``__all__`` documents module contents, not class contents. |
There was a problem hiding this comment.
This is very nitpicky, but what happens if you decorate a method? Is it an error, or does it append the name to __all__?
Initial draft of a PEP to go along side 842 and 843 (hence the claim on 844)