[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed
Barry A. Warsaw added the comment: @sim0n - I added a comment to your open PR. My main question for the rest of the group is whether we can and should backport this. Given the new defect class being introduced, it seems like this should only land in 3.10. Thoughts? -- ___ Python tracker <https://bugs.python.org/issue30681> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31522] _mboxMMDF.get_string() fails to pass param to get_bytes()
Barry A. Warsaw added the comment: Actually, it looks to me like the PR *does* include unittests, and I see them in the repo, so I'm closing this bug. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue42115> ___ ___ 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: @maggyero - I haven't merged PR 10016, but I left some additional comments. Are you still interested in shepherding this PR? -- ___ 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
[issue35181] Doc: Namespace Packages: Inconsistent documentation of __loader__ being None
Barry A. Warsaw added the comment: Apologies for the long delay in reviewing this bug. I'm looking at it now, however since Python 3.7 is in security-only mode, this will only apply to 3.10, 3.9, and 3.8. -- versions: +Python 3.10, Python 3.9 -Python 3.7 ___ 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
[issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart
Barry A. Warsaw added the comment:
Actually, I think I am going to close this as won't fix, for two reasons.
First, this only potentially affects the legacy API, and second, in Python 3,
the error you get when you do it like the original repro example seems obvious
to me.
```
>>> mp = MIMEMultipart()
>>> t = MIMEText('sample text')
>>> mp.attach(t)
>>> mp.set_charset('utf-8')
Traceback (most recent call last):
File "/Users/barry/projects/python/cpython/Lib/email/message.py", line 356,
in set_charset
cte(self)
TypeError: 'str' object is not callable
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "/Users/barry/projects/python/cpython/Lib/email/message.py", line 364,
in set_charset
payload = payload.encode('ascii', 'surrogateescape')
AttributeError: 'list' object has no attribute 'encode'
```
--
resolution: -> wont fix
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue1823>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart
Barry A. Warsaw added the comment: The other question is what to do about `EmailMessage` objects, which don't have a `set_charset()` method. For now, I'll ignore that. -- ___ Python tracker <https://bugs.python.org/issue1823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41988] No hyphen in broken up word in documentation
Barry A. Warsaw added the comment: I am seeing this in Brave (a Chrome derivative). Many examples in https://docs.python.org/3/library/email.html See the words "in\nterface" and "ob\nject' in the attached screenshot. -- nosy: +barry Added file: https://bugs.python.org/file49530/Screen Shot 2020-10-19 at 16.46.44.png ___ Python tracker <https://bugs.python.org/issue41988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart
Barry A. Warsaw added the comment: Updating the Python versions to the only active ones on which this bug could conceivably be fixed. I haven't validated that it's still a problem, and I haven't decided whether it's appropriate to backport to 3.9 and 3.8. I'll work on a patch and see how it goes. -- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.3 ___ Python tracker <https://bugs.python.org/issue1823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart
Change by Barry A. Warsaw : -- assignee: -> barry ___ Python tracker <https://bugs.python.org/issue1823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11414] Add import fix for email.Message
Barry A. Warsaw added the comment: Thanks for the PR @iritkatriel but I'm inclined to close this as won't fix. There are plenty of other changes someone would need to migrate to Python 3 for the email package, so I think this is of limited benefit. -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue11414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27321] Email parser creates a message object that can't be flattened
Change by Barry A. Warsaw : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.10, Python 3.9 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue27321> ___ ___ 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: Thank you all for the fix. Closing. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ 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
[issue37461] email.parser.Parser hang
Barry A. Warsaw added the comment: Thanks everyone for the fixes; I think this bug is now resolved. Closing. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ 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
[issue31818] [macOS] _scproxy.get_proxies() crash -- get_proxies() is not fork-safe?
Barry A. Warsaw added the comment: My understanding is that this is specifically a problem with the Objective-C runtime that _scproxy.c accesses. The runtime is not thread safe and whereas in earlier versions of macOS, it silently failed, now macOS is explicitly aborting the process. -- ___ Python tracker <https://bugs.python.org/issue31818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42092] test_host_resolution_bad_address does not always fail as expected
New submission from Barry A. Warsaw : This is very likely caused by something janky my ISP (AT) is doing with IPv6, but the above named test fails for me because IPv6 addresses like `::1q` do not fail to resolve as the test expects. I'm not sure what can or should be done about it, but as this is an annoying local failure, and I couldn't find another mention of it by searching bpo, I wanted to at least get it on record. The test function's comment says: " # These are all malformed IP addresses and expected not to resolve to # any result. But some ISPs, e.g. AWS, may successfully resolve these # IPs. " So apparently, put AT in that bucket of ISPs that resolve those IPv6 addresses. -- messages: 379020 nosy: barry priority: normal severity: normal status: open title: test_host_resolution_bad_address does not always fail as expected versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42089] Better message in PackageNotFoundError
Change by Barry A. Warsaw : -- keywords: +patch nosy: +barry nosy_count: 1.0 -> 2.0 pull_requests: +21740 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22775 ___ Python tracker <https://bugs.python.org/issue42089> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37741] importlib.metadata docs not showing up in the module index
Change by Barry A. Warsaw : -- versions: +Python 3.10 ___ 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
[issue31818] [macOS] _scproxy.get_proxies() crash -- get_proxies() is not fork-safe?
Barry A. Warsaw added the comment: I agree that we should close this issue, possibly with a documentation fix. I wrote a blog posting about my investigations: https://wefearchange.org/2018/11/forkmacos.rst.html I don't think there's really much Python itself can do, and developers will just have to know that fork-without-exec is pretty much unsafe on macOS. -- ___ Python tracker <https://bugs.python.org/issue31818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41251] __future__.barry_as_FLUFL.getMandatoryRelease() is wrong
Barry A. Warsaw added the comment: Thanks for keeping the first 'F' in FLUFL! :D -- ___ Python tracker <https://bugs.python.org/issue41251> ___ ___ 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: I don't think there's really anything more to do here. I'm closing the issue. Let's open a new one if needed at some future point. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ 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
[issue40453] Add PyConfig._isolated_interpreter: isolated subinterpreters
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue40453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39791] New `files()` api from importlib_resources.
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue39791> ___ ___ 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: One simple restriction would be to disallow relative paths outside of the resource anchor location. -- ___ 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
[issue38743] configure: on macOS (darwin) add CoreFoundation to flags before checking for gettext
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue38743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default before Python 4.0
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue38605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38249] Optimize out Py_UNREACHABLE in the release mode
Barry A. Warsaw added the comment: +1 Serhiy. -- ___ Python tracker <https://bugs.python.org/issue38249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38295] macOS Catalina test failures
New submission from Barry A. Warsaw : test_py_compile fails on macOS Catalina beta (19A573a) == ERROR: test_relative_path (test.test_py_compile.PyCompileTestsWithSourceEpoch) -- Traceback (most recent call last): File "/Users/bwarsaw/projects/python/3.8/Lib/test/test_py_compile.py", line 30, in wrapper return fxn(*args, **kwargs) File "/Users/bwarsaw/projects/python/3.8/Lib/test/test_py_compile.py", line 111, in test_relative_path py_compile.compile(os.path.relpath(self.source_path), File "/Users/bwarsaw/projects/python/3.8/Lib/py_compile.py", line 157, in compile os.makedirs(dirname) File "/Users/bwarsaw/projects/python/3.8/Lib/os.py", line 221, in makedirs mkdir(name, mode) FileNotFoundError: [Errno 2] No such file or directory: '../../../../../../../var/folders/w6/w_2zrjgj7bgdgkhdjm4_r9s4000slb/T/tmpq3p6aoly' == ERROR: test_relative_path (test.test_py_compile.PyCompileTestsWithoutSourceEpoch) -- Traceback (most recent call last): File "/Users/bwarsaw/projects/python/3.8/Lib/test/test_py_compile.py", line 20, in wrapper return fxn(*args, **kwargs) File "/Users/bwarsaw/projects/python/3.8/Lib/test/test_py_compile.py", line 111, in test_relative_path py_compile.compile(os.path.relpath(self.source_path), File "/Users/bwarsaw/projects/python/3.8/Lib/py_compile.py", line 157, in compile os.makedirs(dirname) File "/Users/bwarsaw/projects/python/3.8/Lib/os.py", line 221, in makedirs mkdir(name, mode) FileNotFoundError: [Errno 2] No such file or directory: '../../../../../../../var/folders/w6/w_2zrjgj7bgdgkhdjm4_r9s4000slb/T/tmpquor0q8r' -- -- components: Tests messages: 353381 nosy: barry, ned.deily priority: normal severity: normal status: open title: macOS Catalina test failures versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38289] Add an option to point to an additional "site" directory
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue38289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38208] Simplify string.Template by using __init_subclass__()
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue38208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37683] Use importlib.resources in venv
Barry A. Warsaw added the comment: See also this ticket: https://gitlab.com/python-devs/importlib_resources/issues/58 We've basically agreed that you should be able to load resources from subdirectories that aren't packages. It turns out to be not a simple change in importlib.resources, but contributions are welcome! -- ___ Python tracker <https://bugs.python.org/issue37683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38014] Python 3.7 does not compile
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue38014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38010] Synchronize importlib.metadata with importlib_metadata 0.20
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue38010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34690] Store startup modules as C structures for 20%+ startup speed improvement
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue34690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule
Barry A. Warsaw added the comment: I personally don't think we need to change this. C and Python are different, and the PEP 7 rules have been in place for ages. +Guido -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue37813> ___ ___ 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: @jaraco will be able to answer that better than me. I actually thought those did return concrete lists. I also thought that the APIs accepted either a module or a package name, but maybe I'm thinking about importlib.resources. Again, @jaraco can clarify, but I think the problem is that there's no unambiguous mapping between packages and package names for metadata the way there is for resources. -- ___ 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
[issue37757] TargetScopeError not raised for comprehension scope conflict
Barry A. Warsaw added the comment: > OTOH This would require a PEP change, formal review, etc. It would be trivial though. There are only two references to TargetScopeError in the PEP. One talks about adding the exception and the other just mentions it almost in passing as a subclass of SyntaxError. I think it would be better to just use SyntaxError. -- ___ 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
[issue37741] importlib.metadata docs not showing up in the module index
Change by Barry A. Warsaw : -- keywords: +patch pull_requests: +14887 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15153 ___ 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
[issue37741] importlib.metadata docs not showing up in the module index
Barry A. Warsaw added the comment: I’ll do a PR for that too. > On Aug 6, 2019, at 14:07, Brett Cannon wrote: > > > Brett Cannon added the comment: > > If there's no porting benefit then let's move it to a single module instead > of a package. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue37741> > ___ -- ___ 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
[issue37741] importlib.metadata docs not showing up in the module index
Barry A. Warsaw added the comment: @jaraco - Why is the code in `Lib/importlib/metadata/__init__.py` instead of `Lib/importlib/metadata.py`? Is that to make it easier to port between CPython stdlib and the standalone version? -- ___ 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
[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
[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
[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
[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
