[issue37741] importlib.metadata docs not showing up in the module index
Barry A. Warsaw added the comment: There's an importlib.metadata.rst file which describes how to use the API, but that doesn't appear to be linked from either the main library ToC or the importlib documentation itself. I'll see if I can put together a PR to fix this. -- assignee: docs@python -> barry ___ Python tracker <https://bugs.python.org/issue37741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37757] TargetScopeError not raised for comprehension scope conflict
Barry A. Warsaw added the comment: I know the PEP defines TargetScopeError as a subclass of SyntaxError, but it doesn't really explain why a subclass is necessary. I think seeing "TargetScopeError" will be a head scratcher. Why not just SyntaxError without introducing a new exception? -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue37757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37461] email.parser.Parser hang
Barry A. Warsaw added the comment: New changeset a4a994bd3e619cbaff97610a1cee8ffa87c672f5 by Barry Warsaw (Abhilash Raj) in branch 'master': bpo-37461: Fix infinite loop in parsing of specially crafted email headers (GH-14794) https://github.com/python/cpython/commit/a4a994bd3e619cbaff97610a1cee8ffa87c672f5 -- ___ Python tracker <https://bugs.python.org/issue37461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36564] Infinite loop with short maximum line lengths in EmailPolicy
Barry A. Warsaw added the comment: New changeset f69d5c61981ea97d251db515c7ff280fcc17182d by Barry Warsaw (Paul Ganssle) in branch 'master': Fix infinite loop in email folding logic (GH-12732) https://github.com/python/cpython/commit/f69d5c61981ea97d251db515c7ff280fcc17182d -- ___ Python tracker <https://bugs.python.org/issue36564> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35224] PEP 572: Assignment Expressions
Barry A. Warsaw added the comment: I might be missing it, but I think the Language Reference still doesn't document assignment expressions. https://docs.python.org/3/reference/lexical_analysis.html#operators There are likely other places in the LR that need to be filled out with PEP 572 documentation. -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue35224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37459] importlib docs improperly reference get_resource_loader()
Barry A. Warsaw added the comment: New changeset 070d3d928d20ccb4790dd077f3794af3c2932e5c by Barry Warsaw (Miss Islington (bot)) in branch '3.8': bpo-37459: importlib docs improperly reference get_resource_loader() (GH-14568) (GH-14580) https://github.com/python/cpython/commit/070d3d928d20ccb4790dd077f3794af3c2932e5c -- ___ Python tracker <https://bugs.python.org/issue37459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37459] importlib docs improperly reference get_resource_loader()
Barry A. Warsaw added the comment: New changeset d7d9c9f7c22113a405f1a340d050edfa2d024dff by Barry Warsaw (Miss Islington (bot)) in branch '3.7': bpo-37459: importlib docs improperly reference get_resource_loader() (GH-14568) (GH-14581) https://github.com/python/cpython/commit/d7d9c9f7c22113a405f1a340d050edfa2d024dff -- ___ Python tracker <https://bugs.python.org/issue37459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37459] importlib docs improperly reference get_resource_loader()
Change by Barry A. Warsaw : -- resolution: -> fixed stage: patch review -> backport needed status: open -> closed ___ Python tracker <https://bugs.python.org/issue37459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37459] importlib docs improperly reference get_resource_loader()
Barry A. Warsaw added the comment: New changeset b607d992e76e485f20be3bfd6b311525123f936b by Barry Warsaw (aldwinaldwin) in branch 'master': bpo-37459: importlib docs improperly reference get_resource_loader() (#14568) https://github.com/python/cpython/commit/b607d992e76e485f20be3bfd6b311525123f936b -- ___ Python tracker <https://bugs.python.org/issue37459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
Barry A. Warsaw added the comment:
I still think the only way to read the documentation for parseaddr('a@b@c') is
to return ('', '') - a tuple of empty strings.
The documentations says:
"Returns a tuple of that information, unless the parse fails, in which case a
2-tuple of ('', '') is returned."
Of course, it doesn't define exactly what a "failing parse" is, but I would
claim that a non-RFC compliant address should fail to parse, at least for the
parseaddr() interface.
I'm not concerned about inconsistencies between message_from_string() and
parseaddr(). They are difference APIs.
I'll follow up on the PR, but does anybody disagree with that reasoning?
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue34155>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37459] importlib docs improperly reference get_resource_loader()
Change by Barry A. Warsaw : -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python ___ Python tracker <https://bugs.python.org/issue37459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37459] importlib docs improperly reference get_resource_loader()
Barry A. Warsaw added the comment: Good catch. Are you going to submit a PR? -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue37459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37449] Move ensurepip off of pkgutil and to importlib.resources
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue37449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29412] IndexError thrown on email.message.Message.get
Barry A. Warsaw added the comment: New changeset b950cdb4beabeb093fa3ccc35f53d51cc0193aba by Barry Warsaw (Miss Islington (bot)) in branch '3.7': bpo-29412: Fix indexError when parsing a header value ending unexpectedly (GH-14387) (GH-14412) https://github.com/python/cpython/commit/b950cdb4beabeb093fa3ccc35f53d51cc0193aba -- ___ Python tracker <https://bugs.python.org/issue29412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29412] IndexError thrown on email.message.Message.get
Barry A. Warsaw added the comment: New changeset 82654a037211a3466a294d53952926fc87f8403d by Barry Warsaw (Miss Islington (bot)) in branch '3.8': bpo-29412: Fix indexError when parsing a header value ending unexpectedly (GH-14387) (GH-14411) https://github.com/python/cpython/commit/82654a037211a3466a294d53952926fc87f8403d -- ___ Python tracker <https://bugs.python.org/issue29412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29412] IndexError thrown on email.message.Message.get
Barry A. Warsaw added the comment: New changeset 7213df7bbfd85378c6e42e1ac63144d5974bdcf6 by Barry Warsaw (Abhilash Raj) in branch 'master': bpo-29412: Fix indexError when parsing a header value ending unexpectedly (GH-14387) https://github.com/python/cpython/commit/7213df7bbfd85378c6e42e1ac63144d5974bdcf6 -- ___ Python tracker <https://bugs.python.org/issue29412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33972] AttributeError in email.message.iter_attachments()
Barry A. Warsaw added the comment: New changeset 02257012f6d3821d816cb6a7e8461a88a05b9a08 by Barry Warsaw (Abhilash Raj) in branch 'master': bpo-33972: Fix EmailMessage.iter_attachments raising AttributeError. (GH-14119) https://github.com/python/cpython/commit/02257012f6d3821d816cb6a7e8461a88a05b9a08 -- ___ Python tracker <https://bugs.python.org/issue33972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34796] Tkinter scrollbar issues on Mac.
Christopher A. Chavez added the comment: > Apparently, the current ttk.Scrollbar on the 8.6.8 we currently deliver > should sort of work. I'm not sure if that is the case, though I have not tested with 8.6.8 (I do not currently have access to High Sierra or earlier). Based on a comment by the developer (Marc Culler) in https://core.tcl-lang.org/tk/tktview?name=0d63621b6c it sounds like the Ttk scrollbar is a completely new implementation for 8.6.10, whereas before (8.6.9.1? 8.6.8?) any code requesting a Ttk scrollbar on Aqua normally got a non-Ttk scrollbar instead. -- ___ Python tracker <https://bugs.python.org/issue34796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34796] Tkinter scrollbar issues on Mac.
Christopher A. Chavez added the comment: I have not successfully reproduced the issue here with tkinter 3.7.3 using 8.6.9.1 or recent core-8-6-branch on macOS Mojave. I understand the reporter of this issue believed this was not an upstream Tk issue. However there's a recently opened upstream ticket relating to scrollbars on Aqua which may be of interest: https://core.tcl-lang.org/tk/info/8476b757811b3694 At the moment, one of the Tk Aqua developers appears to advise against using the normal (non-Ttk) scrollbar at all on macOS because it has never worked properly and likely will not be fixed, and instead suggests using the new Ttk scrollbar implementation, which should be available in 8.6.10. -- ___ Python tracker <https://bugs.python.org/issue34796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34796] Tkinter scrollbar issues on Mac.
Change by Christopher A. Chavez : -- nosy: +chrstphrchvz ___ Python tracker <https://bugs.python.org/issue34796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36520] Email header folded incorrectly
Barry A. Warsaw added the comment: New changeset f6713e84afc5addcfa8477dbdf2c027787f711c0 by Barry Warsaw (websurfer5) in branch 'master': bpo-36520: Email header folded incorrectly (#13608) https://github.com/python/cpython/commit/f6713e84afc5addcfa8477dbdf2c027787f711c0 -- ___ Python tracker <https://bugs.python.org/issue36520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21315] email._header_value_parser does not recognise in-line encoding changes
Barry A. Warsaw added the comment: New changeset dc20fc4311dece19488299a7cd11317ffbe4d3c3 by Barry Warsaw (Miss Islington (bot)) in branch '3.7': bpo-21315: Fix parsing of encoded words with missing leading ws. (GH-13425) (#13846) https://github.com/python/cpython/commit/dc20fc4311dece19488299a7cd11317ffbe4d3c3 -- ___ Python tracker <https://bugs.python.org/issue21315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21315] email._header_value_parser does not recognise in-line encoding changes
Barry A. Warsaw added the comment: New changeset 66c4f3f38b867d8329b28c032bb907fd1a2f22d2 by Barry Warsaw (Abhilash Raj) in branch 'master': bpo-21315: Fix parsing of encoded words with missing leading ws. (#13425) https://github.com/python/cpython/commit/66c4f3f38b867d8329b28c032bb907fd1a2f22d2 -- ___ Python tracker <https://bugs.python.org/issue21315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30835] AttributeError when parsing multipart email with invalid non-decodable Content-Transfer-Encoding
Barry A. Warsaw added the comment: New changeset aa79707262f893428665ef45b5e879129abca4aa by Barry Warsaw (Abhilash Raj) in branch 'master': bpo-30835: email: Fix AttributeError when parsing invalid CTE (GH-13598) https://github.com/python/cpython/commit/aa79707262f893428665ef45b5e879129abca4aa -- ___ Python tracker <https://bugs.python.org/issue30835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35805] email package folds msg-id identifiers using RFC2047 encoded words where it must not
Barry A. Warsaw added the comment: New changeset 46d88a113142b26c01c95c93846a89318ba87ffc by Barry Warsaw (Abhilash Raj) in branch 'master': bpo-35805: Add parser for Message-ID email header. (GH-13397) https://github.com/python/cpython/commit/46d88a113142b26c01c95c93846a89318ba87ffc -- ___ Python tracker <https://bugs.python.org/issue35805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33725] Python crashes on macOS after fork with no exec
Barry A. Warsaw added the comment: On Jun 4, 2019, at 08:11, STINNER Victor wrote: > Ned Deily: >> No, it has *always* been unsafe. What's new as of 10.13/14 is that macOS >> tries much harder at runtime to detect such cases and more predictably cause >> an error rather than letter than let the process run on and possibly fail >> nondeterministically. > > Hum, in the doc, I wrote: > > .. versionchanged:: 3.8 > > On macOS, *spawn* start method is now the default: *fork* start method is no > longer reliable on macOS, see :issue:`33725`. > > Should we change this text? Any proposition? Thanks Victor. I don’t think “reliable” is strong enough, since this will definitely lead to core dumps under certain conditions. What about: On macOS, the *spawn* start method is now the default. The *fork* start method should be considered unsafe as it can lead to crashes of the subprocess. See :issue:`33725`. -- ___ Python tracker <https://bugs.python.org/issue33725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33725] Python crashes on macOS after fork with no exec
Barry A. Warsaw added the comment: On May 28, 2019, at 17:38, Ned Deily wrote: > > Ned Deily added the comment: > >> To be clear, what is unsafe on macOS (as of 10.13, but even more so on >> 10.14) is calling into the Objective-C runtime between fork and exec. > > No, it has *always* been unsafe. What's new as of 10.13/14 is that macOS > tries much harder at runtime to detect such cases and more predictably cause > an error rather than letter than let the process run on and possibly fail > nondeterministically. Right, thanks for the additional nuance. I think what changed is that in 10.13, Apple added a warning output when this condition occurred, and in 10.14 they actually abort the subprocess. -- ___ Python tracker <https://bugs.python.org/issue33725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33725] Python crashes on macOS after fork with no exec
Barry A. Warsaw added the comment: On May 28, 2019, at 17:21, STINNER Victor wrote: > > > STINNER Victor added the comment: > >> To be clear, what is unsafe on macOS (as of 10.13, but even more so on >> 10.14) is calling into the Objective-C runtime between fork and exec. The >> problem for Python is that it’s way too easy to do that implicitly, thus >> causing the macOS to abort the subprocess in surprising ways. > > Do only a few Python module use the Objective-C runtime? Or is it basically > "everything"? > > If it's just a few, would it be possible to emit a warning or even an > exception if called in a child process after fork? I think it’s hard to know, but I found it through a path that lead from requests to _scproxy.c. Here’s everything I know about the subject: https://wefearchange.org/2018/11/forkmacos.rst.html So yes, it’s theoretically possible to do *some* between fork and exec and not crash, and it’s of course perfectly safe to call exec pretty much right after fork. It’s just hard to know for sure, and there are surprising ways to get into the Objective-C runtime. I think we won’t be able to work around all of Apple’s choices here. Documentation is the best way to handle it in <=3.7, and changing the default makes sense to me for 3.8. -- ___ Python tracker <https://bugs.python.org/issue33725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33725] Python crashes on macOS after fork with no exec
Barry A. Warsaw added the comment: On May 28, 2019, at 16:43, Ned Deily wrote: > Thanks, I was just going to add that I would accept a doc change for 3.7. > But the wording should be a little clearer that fork has *always* been unsafe > on macOS, i.e. this is not a new issue for 3.7 which is one of the reasons it > should not be backported. To be clear, what is unsafe on macOS (as of 10.13, but even more so on 10.14) is calling into the Objective-C runtime between fork and exec. The problem for Python is that it’s way too easy to do that implicitly, thus causing the macOS to abort the subprocess in surprising ways. -- ___ Python tracker <https://bugs.python.org/issue33725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33725] Python crashes on macOS after fork with no exec
Barry A. Warsaw added the comment: On May 27, 2019, at 16:28, STINNER Victor wrote: > I don't see a clear consensus to switch to spawn on *all* platforms, so I > wrote PR 13603 which is the minimum fix: switch to spawn by default, but only > on macOS. Fair enough. Let’s fix what we have consensus on and go from there. Thanks for working on this! -- ___ Python tracker <https://bugs.python.org/issue33725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37044] Build/test artifacts not ignored for framework build
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue37044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37043] Buildbots fail when new files are added
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue37043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34632] Port importlib_metadata to Python 3.8
Barry A. Warsaw added the comment: New changeset 1bbf7b661f0ac8aac12d5531928d9a85c98ec1a9 by Barry Warsaw (Jason R. Coombs) in branch 'master': bpo-34632: Add importlib.metadata (GH-12547) https://github.com/python/cpython/commit/1bbf7b661f0ac8aac12d5531928d9a85c98ec1a9 -- ___ Python tracker <https://bugs.python.org/issue34632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34632] Port importlib_metadata to Python 3.8
Barry A. Warsaw added the comment: Thanks @jaraco! This is now merged into 3.8. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33725] Python crashes on macOS after fork with no exec
Barry A. Warsaw added the comment: On May 10, 2019, at 04:07, Josh Rosenberg wrote: > > I've seen far too many cases where Python code targeting Linux intentionally > uses the COW benefits of fork for multiprocessing to think it would be a good > idea to change the default start method there without *some* sort of > deprecation period. We need to resolve this for 3.8, and given that I think we have clear consensus to change the default on macOS to spawn to avoid the crashes, let’s do that. We’ll need to update the documentation. Then if we don’t have consensus to change the default on Linux, let’s issue a DeprecationWarning for the default ‘fork’ method in 3.8 and change it to ‘spawn' in 3.9. Do we want to issue a warning on set_start_method(‘fork’) on macOS, given that it’s unlikely to be safe? -- ___ Python tracker <https://bugs.python.org/issue33725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36837] Make il8n tools available from `python -m`
Barry A. Warsaw added the comment: One other suggestion: put the bulk of Tools/i18n/pygettext.py into Lib/_pygettext.py, then import its main() in both Lib/gettext.py and Tools/i18n/pygettext.py. Then just call that main(). -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue36837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36832] Port zipp to zipfile
Change by Barry A. Warsaw : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36832] Port zipp to zipfile
Barry A. Warsaw added the comment: New changeset b2758ff9553d8bebe4e9dd1cb3996212473810e3 by Barry Warsaw (Jason R. Coombs) in branch 'master': bpo-36832: add zipfile.Path (#13153) https://github.com/python/cpython/commit/b2758ff9553d8bebe4e9dd1cb3996212473810e3 -- ___ Python tracker <https://bugs.python.org/issue36832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36820] Captured exceptions are keeping user objects alive unnecessarily in the stdlib
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue36820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36817] Add = to f-strings for easier debugging.
Barry A. Warsaw added the comment: I'll assume you can resolve any weird corner cases, in which case +1 -- type: enhancement -> ___ Python tracker <https://bugs.python.org/issue36817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36817] Add = to f-strings for easier debugging.
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue36817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33725] Python crashes on macOS after fork with no exec
Barry A. Warsaw added the comment: On May 5, 2019, at 11:44, Davin Potts wrote: > > Victor raises an important question: should the *default* start behavior be > made consistent across platforms? Yes, I think it should. The pros of consistency and correctness outweigh the breaking change IMHO. -- ___ Python tracker <https://bugs.python.org/issue33725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36798] := breaks f-strings
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue36798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
Barry A. Warsaw added the comment: Well, at least we're not alone. Here's a screen capture from Mail.app Version 12.4 (3445.104.8). -- Added file: https://bugs.python.org/file48295/Screen Shot 2019-05-02 at 22.07.27.png ___ Python tracker <https://bugs.python.org/issue34155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35181] Doc: Namespace Packages: Inconsistent documentation of __loader__ being None
Barry A. Warsaw added the comment: I've approved both PRs, however I am rather uncomfortable about the code snippet in import.rst. Géry's change is a good one AFAICT, and thanks for the contribution! I would feel much better about the long term correctness of this code snippet if we had a doctest to run over it. But that's for another time. -- ___ Python tracker <https://bugs.python.org/issue35181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14905] zipimport needs to support namespace packages when no 'directory' entry exists
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue14905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36740] zipimporter misses namespace packages for implicit dirs
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue36740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36691] SystemExit & sys.exit : Allow both exit status and message
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue36691> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36256] parser module fails on legal input
A. Skrobov added the comment: Is it intentional that the fix is not backported to 3.6 as well? -- ___ Python tracker <https://bugs.python.org/issue36256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6721] Locks in the standard library should be sanitized on fork
Change by A. Jesse Jiryu Davis : -- nosy: -emptysquare ___ Python tracker <https://bugs.python.org/issue6721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36440] more helpful diagnostics for parser module
A. Skrobov added the comment: > Nothing was really "decided", just that meanwhile is better not to ship a > broken parser module. Totally true, but the issue is closed and resolved, meaning that no one will ever look at it again. -- ___ Python tracker <https://bugs.python.org/issue36440> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36440] more helpful diagnostics for parser module
New submission from A. Skrobov : Seeing that the implicit resolution at #36256 was to keep the parser module in place, may I suggest that the diagnostics it produces be improved, so that instead of "Expected node type 305, got 11", it would raise "Expected namedexpr_test, got COLON" -- components: Extension Modules messages: 338897 nosy: A. Skrobov, benjamin.peterson, berker.peksag, brett.cannon, fdrake, gregory.p.smith, pablogsal, python-dev, serhiy.storchaka, xcombelle priority: normal severity: normal status: open title: more helpful diagnostics for parser module type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue36440> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36440] more helpful diagnostics for parser module
Change by A. Skrobov : -- keywords: +patch pull_requests: +12510 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36440> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): remove empty strings when sep is not None
Barry A. Warsaw added the comment: @veky - Thank you for pointing out splitlines(keepends=True). If we wanted consistency, then we'd change the sense and use something like .split(keepempty=True), however: * I don't like run-on names, so I would suggest keep_empty * Maybe just `keep` is enough * Either way, this should be a keyword only argument * The default would still be None (i.e. current behavior), but keep_empty=True would be equivalent to prune=False and keep_empty=False would be equivalent to prune=True in the previous discussion. -- ___ Python tracker <https://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31973] Incomplete DeprecationWarning for async/await keywords
Barry A. Warsaw added the comment: My sense is that we will never fix this, so closing as Won't Fix. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36256] parser module fails on legal input
A. Skrobov added the comment: > The major problem with the parser module is that is unsynchronized with the > actual parser The parser module is "sort of" synchronised with the actual parser, in that it uses the same _PyParser_Grammar; this doesn't mean they always behave the same, as this bug shows :-) (But before #26526, it used to be much worse, with the parser module having a completely independent re-implementation of the parser.) > As a side note, the problem described in this bug was more or less foreseen. > This is in the header of Modules/parsemodule.c: Just to clarify, the bug is not about the cryptic exception message, it's about the exception firing when it shouldn't. -- ___ Python tracker <https://bugs.python.org/issue36256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36256] parser module fails on legal input
New submission from A. Skrobov :
Under #26526, I had optimised the validation code in parser module to use the
actual parser DFAs, but my code considers only the token types in the input,
and doesn't distinguish between different NAMEs (e.g. different keywords).
The result is this:
Python 3.7.0 (default, Aug 22 2018, 20:50:05)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import parser
>>> parser.sequence2st(parser.suite("if True:\n pass\nelse:\n pass").totuple())
Traceback (most recent call last):
File "", line 1, in
parser.ParserError: Expected node type 305, got 11.
The fix for this bug is quite simple, and in fact, it had been languishing for
2.5 years under #26415
I can easily enough extract the fix into a PR of its own, but the bigger
question is: parser module had been advised against using since Python 2.5; now
that it has been broken for 2.5 years, nobody even noticed. (if-else must be
quite a common code construct, so anybody trying to use the module would have
noticed!) So, should perhaps the module be discontinued rather than fixed?
--
components: Extension Modules
messages: 337619
nosy: A. Skrobov, benjamin.peterson, berker.peksag, brett.cannon, fdrake,
giampaolo.rodola, gregory.p.smith, pablogsal, python-dev, serhiy.storchaka,
xcombelle
priority: normal
severity: normal
status: open
title: parser module fails on legal input
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue36256>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Mar 7, 2019, at 10:46, Ionel Cristian Mărieș wrote: > > There's a simple `if 'COVSOMETHING' in os.environ` check to activate it. > That can't cost a significant amount of time. This is rather another bad > actor argument. You’re overlooking the significant cost of loading the module that does the check in the first place. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Mar 7, 2019, at 09:32, Anthony Sottile wrote: > >> I should have to start that package somehow. > > `pip install` is a pretty good opt-in already imo Except that it conflates responsibilities. I may not want to opt into coverage even being loaded in my application because I’m not going to use it and it has a negative impact on my application’s start up time. Yet because you’re on the same machine and you pip installed it, I have no choice but to pay those costs, which I haven’t explicitly opted in to. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Mar 7, 2019, at 07:38, Steve Dower wrote: > > Steve Dower added the comment: > > There are two features here, let's be clear about what we're removing. > > * extending sys.path with static (perhaps relative) directories > * arbitrary code execution (following "import " statements) > > Only Barry wants to remove the first one, and the rest of us will push back > hard enough to keep him in check ;) Not true! I’m okay with keeping the path extension feature, albeit with improvements: * Loading of .pth files and path extension should be expressed in verbose (`python -v`) output * It should be possible to much more easily debug .pth file loading (I believe there is a PR for this but I haven’t had time to look at it yet) * It should be possible to prevent .pth file loading, likely via interpreter switch or environment variable, akin to -s/-S -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Mar 6, 2019, at 19:04, Anthony Sottile wrote: > It assigns `subprocess.run`, which is an api in python3.5+. In those > versions, `subprocess.check_*` is implemented in terms of `subprocess.run`. > The `subprocess.run` provided by that package has a different api than the > stdlib one so any use of the subprocess module is broken just by having that > package installed Doesn’t that kind of prove my point? :) -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35843] importlib.util docs for namespace packages innaccurate
Barry A. Warsaw added the comment: +1 -- ___ Python tracker <https://bugs.python.org/issue35843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Mar 1, 2019, at 19:59, Ivan Pozdeev wrote: > > Ivan Pozdeev added the comment: > > On 02.03.2019 2:25, Barry A. Warsaw wrote: >> The fact that .pth files are global and affect the entire Python >> installation. <...> Right now, there’s no control over the scope of such >> environmental customizations; it’s all or nothing. > > That's the entire purpose of "customizing the environment in which the > program specified by the user would run". A customization can very well > be implemented to be application-specific but it doesn't have to. Python > was never designed to isolate modules from each other (an "application" > as you say it is just another module) -- on the contrary, the amount of > power it gives the user over the code that they don't control is one of > its key appeals. A Python installation acts as a unit where anything can > affect anything else, and the order is maintained with > https://en.wikipedia.org/wiki/Soft_security . So I just come at it from a different angle (I think Steve and I are aligned). Here’s a very real use case about the dangers. I use my Linux package manager to install a bunch of applications (I don’t totally agree with the “an application is just another package”). I don’t even know that they are Python applications, they’re just tools that do something I like. Now I have an idea for some cool Python thing to hack on and I just install a few development libraries with my package manager. Maybe those libraries come from a secondary repo that has a different level of scrutiny. Or maybe I think, hey what’s the harm to just `sudo pip install` a few things (yes, people do this all the time ;). Subtly, under the hood, one of those transient dependencies down the stack installs some .pth file that executes some arbitrary code and breaks some of those distro provided applications. And lets say I don’t notice weird things happening for a week. Now I think “whoa! how did that application break? I didn’t change it at all”. Not only did I mysteriously break things I relied on, but unless I’m an expert Pythonista and I know how to debug site.py, I’ve got almost no hope of fixing the problem by myself (SO to the rescue?). If I do manage to diagnose the problem, I’ll have to go and uninstall the bad package, and I *should* report things to my distro or upstream. Of course, upstream may say that it’s critical functionality to their library so too bad for you. I’m not even making that up. :) Sure, maybe the very concept of a distro-wide Python application is a mistake, but it’s what we have now, and it’s not going away. >> Applications should be able to opt in or out of them, just like they can >> with individual packages (which must be imported in order to affect the >> interpreter state). > Right on the contrary. To decide what environment an application shall > be run in is the user's prerogative. The application itself has > absolutely no business meddling in this. Again, I just look at this from a different perspective. The user probably doesn’t even know all the environmental factors that affect the operation of their applications, and changes in that environment can happen without the user’s knowledge. All they’re going to know is that application X which is critical to their work has just broken. Sadly, the engineer looking into the bug they filed on it will not be able to reproduce the problem. And now nobody is happy. :) > With "individual packages", it's actually completely the same: the app > can decide which ones it wants to use, but it's the user who decides > which ones are available for use! It’s actually not the same, and that’s the point. An application won’t ever import a library that actively harms it. But it has no such guards against changes to the environment — any environment, including magical Python code. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Mar 1, 2019, at 09:27, Ivan Pozdeev wrote: > Startup code (custom or not) is not a dependency of anything. It rather > customizes the environment in which the program specified by the user would > run, _before_ any user code could be allowed to get control. It is not a part > of the program to be run but rather of the environment that the user wants, > and it needs to be implicit so the user can use the same commands and code > (compare venv). This is a required feature because the stock Python startup > logic cannot possibly provide all the customizations that a user may need > (compare initrd). > > .pth's are equivalent to sitecustomize but allow the user to manage the set > of code chunks automatically using the packaging infrastructure (compare .d > directories in UNIX). The fact that this feature is mixed up with and often > supplements "real packages" that a program would explicitly use is actually > incidental: a package with a .pth does not need to have any functionality > intended for explicit use. > > We already identified a few real reasons: hard to see, hard to debug, > encourages unreadable code, run in arbitrary order when the order matters > (and IIRC I provided fixes for all). What else? The fact that .pth files are global and affect the entire Python installation. That’s not so bad in venvs where we have environmental isolation, but it’s really bad (IMHO) for the global Python interpreter. Right now, there’s no control over the scope of such environmental customizations; it’s all or nothing. Applications should be able to opt in or out of them, just like they can with individual packages (which must be imported in order to affect the interpreter state). The trick then is how to define opt-in for applications *before* the interpreter gets to user code. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Feb 28, 2019, at 09:40, Anthony Sottile wrote: > > I don't think even this is unanimous. Things like registering codecs, > instrumenting coverage in subprocesses, etc. all seem like legitimate uses of > the arbitrary code execution feature Except pth files are a terrible interface for that, given all the other problems, including weird wall-of-code inducing restrictions on what actually gets executed. I’m in agreement with Steve Dower in principle here. I would like to see a solution that deprecates and eventually removes arbitrary code execution in pth files, leaves sys.path extension alone (for now ), and improves the discoverability and debuggability of magical pth files. What I think Anthony is looking for are ways to register “start up functions” that get executed automatically when the Python interpreter starts up. Perhaps somewhat analogous to atexit functions? But if we’re going to officially support a feature like that, I think a PEP would be the right vehicle to suss out all the gory details, like, should these things be global across all invocations of the interpreter, how a user or application would disable that, how would bugs in start up functions get discovered, reported, and debugged, what if any execution order guarantees should be made, etc. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36128] ResourceReader for FileLoader inconsistently handles path separators
Barry A. Warsaw added the comment: On Feb 26, 2019, at 13:05, Gregory Szorc wrote: > > I would think the two would agree about whether a path with separators is a > resource or not. The documentation at > https://docs.python.org/3.7/library/importlib.html#importlib.abc.ResourceReader > implies that resources in subdirectories should not be allowed. Historical context is in the standalone tracker: https://gitlab.com/python-devs/importlib_resources/issues/58 Clearly, with the current definition of the API, open_resource() should not allow slashes. Please follow up on the above link if you have opinions about changing the behavior. We would have an opportunity to relax that constraint in Python 3.8, if it’s something we want to do. -- ___ Python tracker <https://bugs.python.org/issue36128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Feb 26, 2019, at 13:23, Ivan Pozdeev wrote: > > Easy. Insert a chunk into site.py that would call pdb.set_trace() if an > envvar (e.g. `PYSITEDEBUG') or a command line switch is set. > > Actually, why can't whoever has this problem add such a chunk themselves? Is > this really such a frequent and ubiquitous problem > that this needs to be in the stock codebase? I suspect we're dealing with a > vocal minority here. Basically yes, I’ve done this. But think of the poor user who doesn’t have that expertise or ability to hack on an installed Python’s site.py file. When their application breaks because some faulty pth was installed behind their back, how do they debug their application when the breakage has already occurred before Python even gets to their code? How do they answer questions like “where did that magical sys.path entry come from?” or “how did that module get in sys.modules already?” -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Feb 26, 2019, at 12:52, Ionel Cristian Mărieș wrote: > > Something bad was installed with sudo but suddenly sudo is not acceptable for > debugging? This seems crazy. Your sudo may not be my sudo. :) Let’s say I update my Ubuntu desktop and a new version of package with a pth breaks. Maybe I didn’t even know I was doing that, via automated updates, or management portal, etc. Now a poor user who depends on this has their code break. How do *they* debug the problem? FWIW, `sudo pip install` should just be banned IMHO :). > How exactly are pth files hard to debug? Are those files hard to edit? They > sure are, but the problem ain't the point where they are run, it's the fact > that a big lump of code is stuffed on a single line. Lets fix that instead! For sure. But here’s the thing: you need to know *which* pth file is problematic. Which means you have to debug the entire startup process where pth files are loaded. That means you’re not really debugging pth files themselves (often), but site.py. Debugging site.py for an installed Python is not trivial. Hopefully you are at least not squeamish about editing a system file and breaking Python worse than the original bug. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Feb 26, 2019, at 12:32, Steve Dower wrote: > > There are 100 other ways to end up in this situation though. Why is *this* > one so much worse? Because there’s no good place to stick a pdb/breakpoint to debug such issues other than site.py, and that usually requires sudo. > Can you offer an issue you hit that was caused by a .pth file that *wasn't* > debuggable by listing sys.path? I don’t remember the details, but yes I have been caught in this trap. The thing is, by the time user code gets called, the damage is already done, so debugging is quite difficult. This will be alleviated at least partially by deprecating the executing of random code. Maybe just allowing sys.path hacking will be enough to make it not so terrible, especially if e.g. (and I haven’t check to see whether this is the case today), `python -v` shows you exactly which .pth file is extending sys.path. The issue is discoverability. Since pth files happen before you get an interpreter prompt, it’s too difficult to debug unexpected, wrong, or broken behavior. My opposition would lessen if there were clear ways to debug, and preferably also prevent, pth interpretation. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Feb 26, 2019, at 05:19, Nick Coghlan wrote: > > I just don't want to lose the "add this location to sys.path" behaviour that > exists for lines in pth files that *don't* start with "import ", since that > has plenty of legitimate use cases, and the only downside of overusing it is > an excessively long default sys.path (which has far more consistent and > obvious symptoms than the arbitrary code execution case can lead to). It’s also very difficult to debug because pth loading usually happens before the user has a chance to intervene with a debugger. This means mysterious things can happen, like different versions of a package getting imported than you expect. Extending sys.path is a useful use case, but doing so in pth files is problematic. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11776] Constructor signatures missing in types module documentation
Change by Tz a : -- nosy: +Tz a ___ Python tracker <https://bugs.python.org/issue11776> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24658] open().write() and .read() fails on 2 GB+ data (OS X)
Change by Barry A. Warsaw : -- title: open().write() fails on 2 GB+ data (OS X) -> open().write() and .read() fails on 2 GB+ data (OS X) ___ Python tracker <https://bugs.python.org/issue24658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24658] open().write() fails on 2 GB+ data (OS X)
Barry A. Warsaw added the comment: Nosying myself since I just landed here based on an internal $work bug report. We're seeing it with reads. I'll try to set aside some work time to review the PRs. -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue24658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35905] macOS build docs need refresh (2019)
Barry A. Warsaw added the comment: All I know is that for 3.7 and 3.8 (3.6 is different), I have this little helper script to build against Homebrew libraries. #!/bin/sh export CPPFLAGS="-I$(brew --prefix sqlite3)/include -I$(brew --prefix zlib)/include" export LDFLAGS="-L$(brew --prefix sqlite3)/lib -L$(brew --prefix zlib)/lib" export PKG_CONFIG_PATH="/usr/local/opt/openssl/lib/pkgconfig" ./configure -- ___ Python tracker <https://bugs.python.org/issue35905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35905] macOS build docs need refresh (2019)
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue35905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35321] None _frozen_importlib.__spec__.origin attribute
Barry A. Warsaw added the comment: New changeset 69091cb497b2f0fe7e2789b30b43cf78caf9de9b by Barry Warsaw (Nina Zakharenko) in branch 'master': bpo-35321: Set the spec origin to frozen in frozen modules (#11732) https://github.com/python/cpython/commit/69091cb497b2f0fe7e2789b30b43cf78caf9de9b -- ___ Python tracker <https://bugs.python.org/issue35321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35839] Suggestion: Ignore sys.modules entries with no __spec__ attribute in find_spec
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue35839> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35321] None _frozen_importlib.__spec__.origin attribute
Change by Barry A. Warsaw : -- versions: +Python 3.6 ___ Python tracker <https://bugs.python.org/issue35321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35835] There is no mention of breakpoint() in the pdb documentation
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue35835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
Barry A. Warsaw added the comment: On Jan 22, 2019, at 07:16, Samuel Colvin wrote: > > Ok, if I create a PR, should it just remove MailmanProxy completely or mark > it as deprecated in the docs to be removed in 3.9? > > Personally, I think it should be ok to remove it completely since it hasn't > been working at all for the last 4 minor versions. True, but I think we should stick to the normal deprecation process, just to be safe. -- ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
Barry A. Warsaw added the comment: Yes, it should be deprecated and removed. TBH, IMHO smtpd.py should be entirely deprecated. aiosmtpd (3rd party) is a much more modern approach. -- ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35321] None _frozen_importlib.__spec__.origin attribute
Barry A. Warsaw added the comment: I am mentoring Nina so I'll review this. -- ___ Python tracker <https://bugs.python.org/issue35321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35321] None _frozen_importlib.__spec__.origin attribute
Barry A. Warsaw added the comment: Frozen module's origin isn't really documented AFAICT. Here's the link to the library reference: https://docs.python.org/3/library/importlib.html?highlight=origin#importlib.machinery.ModuleSpec.origin The language reference doesn't really have anything to say here. I think it wouldn't be difficult to add 'frozen' to the origin, but it should also be documented in the library reference (and of course, tested). -- ___ Python tracker <https://bugs.python.org/issue35321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35321] None _frozen_importlib.__spec__.origin attribute
Change by Barry A. Warsaw : -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue35321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32866] zipimport loader.get_data() requires absolute zip file path
Barry A. Warsaw added the comment: I believe this bug does not affect Python 3.8: (Using a Python 3.8 virtualenv): % python demo.pyz Reading: resource.txt Length: 19 % python `pwd`/demo.pyz Reading: resource.txt Length: 19 I think it's too risky (and too much work, given it would have to be ported to the C implementation of zipimport) to change this in earlier Pythons. So, closing. -- resolution: -> works for me stage: -> resolved status: open -> closed versions: -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue32866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Jan 14, 2019, at 17:30, STINNER Victor wrote: > > I don't think that you will like it, but I feel that a PEP will be needed > here to list use cases and explain what replace .pth files for each use > case. Maybe no replacement for some use cases is fine. The PEP doesn't have > to be long. > > I also expect that it's going to be a large backward incompatible change. A > PEP can summerize the rationale, schedule deprecation, etc. +1 > Any volunteer around? Barry, Nick, someone else? I will volunteer to co-author. I would definitely like at least Nick and/or Jason to help. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Jan 14, 2019, at 07:17, Nick Coghlan wrote: > > I'll also reiterate that I am *completely* opposed to deprecating the "append > entries to sys.path" usage model, as there is absolutely nothing wrong with > that (if distros are ending up with an overly cluttered system that's making > the standard path too long, then review the individual packages creating the > clutter, don't remove the interpreter feature). Yes, there is as Victor and others points out. They do magical things that are difficult to debug and diagnose, and have global effects on the entire Python operating environment. I’d be less opposed to a mechanism that is isolated to just those Python applications that need them. I’d like to know about use cases outside of Python applications that can’t be done any other way. > That "append to sys.path" aspect of the feature is all that's needed to make > editable installs and virtual environment chaining work. > > That means the aspect I'm in agreement with deprecating is the "arbitrary > code execution on startup" case, but even for that, I don't think we should > deprecate it until we have a comparable replacement that's more > self-evidently a way of allowing arbitrary code execution, and also more > obviously has the potential to make every interpreter startup in that Python > installation slower. I think we’re all in agreement about deprecating arbitrary code execution, so maybe this issue can concentrate on that, while we figure out what, if anything to do about the path extension use case. I don’t care about slow start up of the interactive interpreter, but I do strongly care about the start up times for Python applications in general. That’s why an opt-in mechanism is important. > 1. In site.addsitedir, check for a __sitecustomize__ subdirectory after > checking for .pth files > 2. If any Python files are found in that directory, execute them > 3. If "python -x importtime" has been specified, report the execution time of > each of those files (this would allow both easy identification of any hooks > that are being executed, as well as which ones are taking up a lot of time) > > There could then be a "-Z" option that offered a more limited form of "-S": > it would allow site.py itself to run, but disable the processing of > `sitecustomize.py` and `__sitecustomize__` entries. Is that a global __sitecustomize__ directory you’re talking about, or something specific to a Python application (or library?). -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Jan 14, 2019, at 04:14, Antoine Pitrou wrote: > > As I said: editable installs (`pip install -e`) are an important use case of > .pth files. Is that true outside of virtual environments? I care less about .pth files inside venvs, since those are typically isolated to a single development environment, and don’t affect Python applications or libraries globally. -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment: On Jan 14, 2019, at 04:02, STINNER Victor wrote: > > I really hate .pth files because the slow down Python startup time for *all* > applications whereas .pth files are usually specific to a very few > applications using one or two specific modules. > > They can also modify the behavior of Python for all applications, with no way > to opt-out. > > I would prefer to have an opt-in option, disabled by default. I completely agree. The other problem is that .pth-caused problems are very difficult to diagnose and debug. Essentially you have to hack site.py to break into the loading machinery. I have to believe that we can come up with a better mechanism that doesn’t suffer from these problems. Do we have a single place to capture a list of .pth use cases? -- ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Barry A. Warsaw added the comment:
> To make a potentially viable concrete proposal here, I think a reasonable
> first step would be to change the ".pth" file processing code in site.py to
> emit PendingDeprecationWarning for the 'if line.startswith(("import ",
> "import\t")):' branch.
PendingDeprecationWarning because you don’t think we can remove this
functionality in 3.9?
> In addition to helping to determine the scope of the compatibility break
> being discussed here, such a warning would also be usable as a debugging tool.
>
> I'd also suggest updating "python -m site" to list any pth files that it
> finds, and categorise them as simple sys.path additions (which are generally
> fine), and arbitrary code (which can be problematic).
Great idea, +1
--
___
Python tracker
<https://bugs.python.org/issue33944>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35673] Loader for namespace packages
Barry A. Warsaw added the comment: On Jan 7, 2019, at 03:16, Ronald Oussoren wrote: > > Do you know why the namespace package loader lies about the source and code? > Both .get_source() and .get_code() return a value that isn't None. > And likewise: Why is the namespace package loader a private class, other > loaders are exposed in importlib.machinery? This makes it hard to detect > PEP420 style namespace packages without relying on private APIs, esp. > combined with the behaviour of .get_source() and .get_code(). I don’t remember the history of this. I wonder if Brett or Eric have any additional insights. -- ___ Python tracker <https://bugs.python.org/issue35673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35673] Loader for namespace packages
Change by Barry A. Warsaw : -- nosy: +eric.smith ___ Python tracker <https://bugs.python.org/issue35673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35673] Loader for namespace packages
Barry A. Warsaw added the comment: On the first point, I'd categorize this as a documentation bug, and in fact, it's inconsistent with the language reference, which doesn't have the same language: https://docs.python.org/3/reference/import.html#__loader__ On the second point, it probably does make sense to register the ABC. -- ___ Python tracker <https://bugs.python.org/issue35673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35673] Loader for namespace packages
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue35673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35651] PEP 257 (active) references PEP 258 (rejected) as if it were active
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue35651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35526] __future__.barry_as_FLUFL documented as mandatory for Python 3.9
Change by Barry A. Warsaw : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35526] __future__.barry_as_FLUFL documented as mandatory for Python 3.9
Barry A. Warsaw added the comment: New changeset 55cc34500e5abbfedb89adc95e3f94d53c544933 by Barry Warsaw (Chris Rands) in branch 'master': bpo-35526: make __future__.barry_as_FLUFL mandatory for Python 4.0 (#11218) https://github.com/python/cpython/commit/55cc34500e5abbfedb89adc95e3f94d53c544933 -- ___ Python tracker <https://bugs.python.org/issue35526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35526] __future__.barry_as_FLUFL documented as mandatory for Python 3.9
Barry A. Warsaw added the comment: Let's extend the "joke" and make it mandatory in Python 4! :) -- ___ Python tracker <https://bugs.python.org/issue35526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Excessive peak memory consumption by the Python parser
A. Skrobov added the comment: I've run pyperformance (0.7.0) with my updated patch, and posted results at the PR page. They look encouraging enough. -- ___ Python tracker <https://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33725] Python crashes on macOS after fork with no exec
Barry A. Warsaw added the comment: On Dec 12, 2018, at 17:59, Ned Deily wrote: > > Ned Deily added the comment: > >> Would it be safe to run the multiprocessing tests on recent macOS with the >> OBJC_DISABLE_INITIALIZE_FORK_SAFETY environment variable set? > > See Ronald's reply above in msg331101. I believe his point is that there is > nothing you can do to make this safe. And it's not a new problem with 10.14 > or 10.13. What is new is that Apple is trying to more forcefully make you > aware of the danger by causing the runtime to try to catch and crash these > cases earlier rather than permit them to perhaps silently cause failures > later. In my experiments at least, setting the env var *does* prevent the crash, but it doesn’t avoid the undefined semantics (i.e. what happens when the ObjC runtime is called at that point?) and I fully expect that Apple will remove that bandaid at some point. The other key thing is that I don’t believe you can set the env var *in process* and have it take effect after the fork. It must be set before the parent process starts. So that probably makes it less useful for the multiprocessing tests by itself. -- ___ Python tracker <https://bugs.python.org/issue33725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
