[issue47153] __doc__ should generally be writable
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue47153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47061] Deprecate modules listed in PEP 594
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue47061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47022] PEP 594: Document removal of asynchat, asyncore and smtpd
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue47022> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46896] add support for watching writes to selected dictionaries
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46543] Add sys._getfunc
Barry A. Warsaw added the comment: > Usually the calling function object should be enough. I want to at least provide some historical context on why sys._getframe() exists. I originally wrote that to support PEP 292 and internationalization in Mailman. This has since been extracted into the flufl.i18n package. Here is the use of sys._getframe() in that library: https://gitlab.com/warsaw/flufl.i18n/-/blob/main/src/flufl/i18n/_translator.py#L65 You can see that the reason this exists is to dig out the local and globals of the context in which the _() function is invoked. This greatly reduces the need to repeat yourself in i18n call sites. https://flufli18n.readthedocs.io/en/stable/using.html#substitutions-and-placeholders I'm not saying sys._getfunc() is or isn't useful, but it won't change original need for sys._getframe(). -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46528] Simplify the VM's stack manipulations
Barry A. Warsaw added the comment: IIRC, Carl got a lot of benefit out of reordering the opcodes in the main loop to put the most common ones at the top. I don't know if that is still relevant or whether computed gotos, when enabled, change that calculus. -- ___ Python tracker <https://bugs.python.org/issue46528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46528] Simplify the VM's stack manipulations
Barry A. Warsaw added the comment: Very interesting. Do we have any current (or even cutting edge, i.e. 3.11) timings for individual instructions? Or a breakdown of how frequently different instructions are invoked? I remember Carl Shapiro presenting his findings here several years ago (I think in the penultimate in-person Language Summit). -- ___ Python tracker <https://bugs.python.org/issue46528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46528] Simplify the VM's stack manipulations
Barry A. Warsaw added the comment: What are the (unoptimized) performance implications of replacing one instruction with multiple instructions? -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46330] Simplify the signature of __exit__
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46330> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46328] add sys.exception()
Barry A. Warsaw added the comment: sys.exception() seems like a decent enough trade-off. I've always disliked the abbreviations in "exc_info". It doesn't feel big enough for a PEP to me. -- ___ Python tracker <https://bugs.python.org/issue46328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46328] add sys.exception()
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46321] Don't need delineators on lists
Barry A. Warsaw added the comment: As Dennis points out, this is not a bug, it's already valid Python syntax. -- nosy: +barry resolution: -> not a bug status: pending -> open ___ Python tracker <https://bugs.python.org/issue46321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
Barry A. Warsaw added the comment: I think you’re right that the iterator API isn’t very helpful. I also agree that you probably really want to answer the “why identifiers are in this template?” question. As for repeats, there’s two ways to think about it. You could return all the identifiers in the order in which they’re found in the template (and you can unique-ify them if you want by passing that list to set()). But maybe you don’t really need that either. get_identifiers() works for me! On Jan 8, 2022, at 18:51, Ben Kehoe wrote: > > Ben Kehoe added the comment: > > Happy to make a PR! In my mind I had been thinking it would be the > get_identifiers() method with the implementation above, returning a list. > > As for __iter__, I'm less clear on what that would look like: > > t = string.Template(...) > for identifier in t: > # what would I do here? > # would it include repeats if they appear more than once in the template? > > I guess there are two ways to think about it: one is "what identifiers are in > this template?" which I think should return a list with no repeats, which I > can then iterate over or check if a value is in it. The other is, "what are > the contents of the template?" in the style of string.Formatter.parse(). > > Given that string.Template is supposed to be the "simple, no-frills" thing in > comparison to string.Formatter, I see less use for the latter option. -- ___ Python tracker <https://bugs.python.org/issue46307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
Barry A. Warsaw added the comment: I've never personally needed this, but I could see where it could come in handy. I wonder if __iter__() would be the right API for that? I wonder then if we should also implement __contains__()? Would you be interested in creating a PR for the feature? -- ___ Python tracker <https://bugs.python.org/issue46307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
Barry A. Warsaw added the comment: > Barry: The PEP 8 'return None' recommendation could be added to the Reference > entry for 'return'. But I think this should be a separate issue as 1) it is > about coding rather than documentation and 2) there is the possible objection > that choosing completely explicit 'return None' versus half explicit, half > implicit 'return' and the latter versus completely implicit > should be left to the style PEP. I do think it's a question of style. Section 7.6 of the language reference says: > If an expression list is present, it is evaluated, else None is substituted. which is the important concept that beginners should learn. I agree that the admonition in PEP 8 is really trying to say "don't mix implicit and explicit return styles". Implicit None return is fine if all exit paths are implicit. But once you add an explicit value to a return path, all return paths should use explicit values, including those that return None. IME, while I do occasionally encounter push back on this when doing reviews, most folks come around to this p.o.v. -- ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
Barry A. Warsaw added the comment: I think it does a better service to users to explain how Python returns None implicitly if a function doesn't have any other explicit return value. If the print() docs had this note, it would be confusing why other similar functions don't. It's also worth explaining that when a function is designed to *explicitly* return None in certain cases (e.g. dict.get()) that it shouldn't do so implicitly, but should include an explicit `return None` for readability. -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46090] C extensions can't swap out live frames anymore
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46142] python --help output is too long
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22789] Compress the marshalled data in PYC files
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue22789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45545] chdir __exit__ is not safe
Barry A. Warsaw added the comment: > A LBYL won't always raise errors early as you point out. It will give earlier > warnings for a lot of cases, but makes contextlib.chdir usable in less places > than os.chdir. > Some return paths will always be errors, and some will be technically > recoverable but too difficult to detect and or fragile. That's why I think > any solution should incorporate the `ignore_errors` flag. Its pretty ugly to > wrap a context manager in a try: except: just because you were trying to > clean up after whatever you were doing but the cwd changed in unexpected > ways, maybe out of your control. How common do you expect such errors to be though? Do you expect them to be more or less common than with os.chdir()? Do you expect the mitigations to be any different than with a failing os.chdir()? I’ve certainly written a chdir context manager several times and for the use cases I care about, I’ve never had such a failure, at least not one that wasn’t caused by some other underlying bug, which I was glad wasn’t silenced. -- ___ Python tracker <https://bugs.python.org/issue45545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45545] chdir __exit__ is not safe
Barry A. Warsaw added the comment: Does a LBYL strategy actually fix the problem? E.g. what if the directory gets rm'd between __enter__ and __exit__? Maybe we shouldn't try to be clever at all and just leave it to the user to decide what to do, and how to handle any chdir-back failures? Keep it simple? -- ___ Python tracker <https://bugs.python.org/issue45545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45540] module.__package__ and module.__spec__.parent have different semantics
Barry A. Warsaw added the comment: Thanks for your comprehensive comments Eric! While I digest them, my TL;DR is that we probably need a PEP to describe everything from the current situation, to the the desired end state and migration path. I'm willing to put that together with you and Brett as co-authors if you're amenable. -- ___ Python tracker <https://bugs.python.org/issue45540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45552] Close asyncore/asynchat/smtpd issues and list them here
Barry A. Warsaw added the comment: Thank you for doing this work Irit! Just to point out that anybody who wants a modern replacement for smtpd should look at aiosmtpd: https://aiosmtpd.readthedocs.io/en/latest/ -- ___ Python tracker <https://bugs.python.org/issue45552> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45552] Close asyncore/asynchat/smtpd issues and list them here
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue45552> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45545] chdir __exit__ is not safe
Barry A. Warsaw added the comment: > Yes, precisely. Besides being an unreachable long abs path, it might have > been deleted since last visited. I’m working on a few more odd test cases. Ah, the deleted case. Sounds like LBYL wouldn’t work in that case then. :( -- ___ Python tracker <https://bugs.python.org/issue45545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33277] Deprecate __loader__, __package__, and __cached__ on modules
Barry A. Warsaw added the comment: On Oct 20, 2021, at 08:28, Eric Snow wrote: > > The only catch I see is where the module's code sets one of the attrs. Would > the proxy (or import machinery) pick those up, or maybe for some of them emit > a warning or fail? > > We could also skip the proxy and add the properties to ModuleType directly, > no? My initial idea was to proxy from the ModuleType to the ModuleSpec and I started down that path, but hacking in C is much more painful than experimenting in Python, so that’s why I did my WIP branch (i.e. just to play with the feasibility of it). Thus I had planned to keep the actual attribute values in the ModuleSpec and essentially implement a getattro and setattro in the ModuleType that proxied sets and gets to the ModuleSpec. -- ___ Python tracker <https://bugs.python.org/issue33277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33277] Deprecate __loader__, __package__, and __cached__ on modules
Barry A. Warsaw added the comment: On Oct 20, 2021, at 08:18, Eric Snow wrote: > The spec identifies how a module should be loaded (or how it was loaded and > should be reloaded). We should be careful to preserve that identify and not > invite uses to modify the spec after (or while) the module is loaded. PEP > 451 talks about the difference a little, but I'm pretty sure it came up in > more detail in discussions about the PEP at that time. It’s frankly not good enough to capture the *intent* of these attributes in a PEP. We need to be clear in the documentation about their purpose and we need to be clear about when to use or set either the module attribute or the spec attribute. The current situation is ambiguous and possibly misleading. But maybe it’s “just” a documentation issue? -- ___ Python tracker <https://bugs.python.org/issue33277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33277] Deprecate __loader__, __package__, and __cached__ on modules
Barry A. Warsaw added the comment: On Oct 20, 2021, at 11:31, Brett Cannon wrote: > >> +1 on a proxy (with read-only attrs) for everything but __name__, __file__, >> and __path__ (which can all be different than the spec). > > I'm -1 on a proxy as that doesn't simplify the situation. Having (nearly) > duplicate attributes is confusing and I have yet to see it benefit anyone. If we don’t implement a proxy to enforce equivalence, then we shouldn’t say as such in the documentation. And we should be much clearer about what the purpose of the spec is versus the module attributes. -- ___ Python tracker <https://bugs.python.org/issue33277> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45540] module.__package__ and module.__spec__.parent have different semantics
Barry A. Warsaw added the comment: On Oct 20, 2021, at 11:38, Eric Snow wrote: > > Regardless, I expect the primary reason __package__ is writable is > because modules have never had any read-only attrs. So historical accident mostly. > The more important question now is, when is __package__ ever modified? > I can think of 2 cases: > > 1. legacy (pre-451) importers set it when they load the module > 2. someone wants to customize the import system without writing an importer > > With the latter, specifically they are trying to change how the module > is reloaded or submodules are imported. In that case there should > probably be an explicit way to do so without having to hack the import > machinery. > > My only concern with any support/encouragement for modifying the spec > after import is it results in less confidence about how the module was > imported originally. I guess a question to answer then is whether we philosophically want the module attributes to be equivalent to the spec attributes. And by equivalent, I mean enforced to be exactly so, and thus a proxy. To me, the duplication is a wart that we should migrate away from so there’s only one place for these attributes, and that should be the spec. Here is the mapping we currently describe in the docs: mod.__name__ === __spec__.name mod.__package__ === __spec__.parent mod.__loader__ === __spec__.loader mod.__file__ === __spec__.origin mod.__path__ === __spec__.submodule_search_locations mod.__cached__ === __spec__.cached But right now, they don’t have to stay in sync, and I don’t think it’s reasonable to put the onus on the user to keep them in sync, because it’s unclear what code uses which attribute. Okay, so you can just set them both to be safe, but then you can’t do that with __spec__.parent/__package__ This is what leads me to think that having a proxy to keep them in sync and relaxing the read-only restriction is the path forward, even if writing __package__ doesn’t make sense. It also seems like the easier way to keep backward compatibility, rather than enforcing read-only on __package__ to match __spec__.parent. So the question is less about whether this is useful than whether it will break things if they write to it. -- ___ Python tracker <https://bugs.python.org/issue45540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45545] chdir __exit__ is not safe
Barry A. Warsaw added the comment: Does this mean that CWD could be in a directory that you couldn't chdir() back into? -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue45545> ___ ___ 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 Oct 20, 2021, at 11:27, Brett Cannon wrote: > >> That should probably be a separate issue/PR in either case. > > https://bugs.python.org/issue38782 and I was trying to rope you into doing > the work. Ha! You should have nosied me then :D - but anyway I’m following that ticket now so we’ll see. -- ___ 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 : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ 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
[issue38782] Convert importlib.abc to use typing.Protocol
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue38782> ___ ___ 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: New changeset 876fc7fcec9a79a11546b7588d3683a5ccb4d31c by Barry Warsaw in branch 'main': bpo-35673: Add a public alias for namespace package __loader__ attribute (#29049) https://github.com/python/cpython/commit/876fc7fcec9a79a11546b7588d3683a5ccb4d31c -- ___ 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
[issue45540] module.__package__ and module.__spec__.parent have different semantics
Change by Barry A. Warsaw : -- nosy: +brett.cannon, eric.snow ___ Python tracker <https://bugs.python.org/issue45540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45540] module.__package__ and module.__spec__.parent have different semantics
New submission from Barry A. Warsaw : TL;DR module.__spec__.parent is read-only but module.__package__ is r/w despite documentation that implies that these two attributes should be identical, and various issues that focus on migrating from direct module attributes to ModuleSpec attributes. bpo-33277 and bpo-21762 Maybe we should relax the restriction on module.__spec__.parent so that it's writeable just like module.__package__. See also: https://docs.python.org/3/reference/import.html?highlight=__loader__#package__ https://docs.python.org/3/library/types.html?highlight=__loader__#types.ModuleType.__package__ -- components: Interpreter Core messages: 404500 nosy: barry priority: normal severity: normal status: open title: module.__package__ and module.__spec__.parent have different semantics versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45540> ___ ___ 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
Change by Barry A. Warsaw : -- pull_requests: +27351 pull_request: https://github.com/python/cpython/pull/29085 ___ 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
[issue42092] test_host_resolution_bad_address does not always fail as expected
Barry A. Warsaw added the comment: Woot! I finally figured out the problem and how to fix it. It has nothing to do with Python and everything to do with AT They run a service called DNS Error Assist, quoting: "Sometimes we enter a wrong search word, or a wrong web address, or maybe the website we want is no longer in service. If this happens, the DNS Error Assist service automatically searches for similar or related terms and presents you some results that may be useful for you. Otherwise, you’ll get a “No results found” error message." Turning this off is buried in AT's site. I found some outdated recommendations on the web, but here's what worked for me (as of the date of this comment). Log in to your AT portal, search for "Privacy" and click on the link that says "Privacy in Support". This takes you to a page that describes AT's privacy policies, and gives you a link to "Go" to your privacy settings. >From there you should see two sections, one that says "Control how we >communicate with you" and one that says "Control how we use your data". >Select DNS Error Assist and disable that. You'll need to wait a few minutes >for it to take effect, but then you'll get none of those bogus resolutions. While you're at it, you might want to review your other privacy settings. -- resolution: -> not a bug stage: -> resolved status: open -> closed 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
[issue33277] Deprecate __loader__, __package__, and __cached__ on modules
Change by Barry A. Warsaw : -- keywords: +patch pull_requests: +27347 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/29078 ___ Python tracker <https://bugs.python.org/issue33277> ___ ___ 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: I don't know. What benefit would be gained? That should probably be a separate issue/PR in either case. -- ___ 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
[issue45493] str() and repr() of enum different in Python 3.11 from Python <= 3.10
Barry A. Warsaw added the comment: I can see why Ethan might be overwhelmed by reverting this change. I tried to merge in his branch but failed, so I'm chucking that work and will try again. -- ___ Python tracker <https://bugs.python.org/issue45493> ___ ___ 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: Since the documentation problem reported here has since been fixed, and really all that's left is to expose NamespaceLoader publicly and register it with the abc, this is technically a new feature so it can't be backported. Thus, targeting only 3.11. -- versions: -Python 3.10, Python 3.9 ___ 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: First crack at a PR for this issue. -- keywords: +needs review -patch ___ 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 : -- keywords: +patch pull_requests: +27320 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29049 ___ 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 : -- versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.6, Python 3.7, Python 3.8 ___ 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: I'm going to take a look at this during the Python core sprint. -- assignee: -> 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
[issue45493] str() and repr() of enum different in Python 3.11 from Python <= 3.10
Barry A. Warsaw added the comment: This doesn't seem right, given that PEP 663 has not been approved by the SC yet: 3.9.7 (default, Oct 13 2021, 06:45:31) [Clang 13.0.0 (clang-1300.0.29.3)] ABC.a ABC.b ABC.c ABC.a |main=|@presto[~/projects/python/cpython:1058]% python3.10 /tmp/foo.py 3.10.0 (default, Oct 13 2021, 06:45:00) [Clang 13.0.0 (clang-1300.0.29.3)] ABC.a ABC.b ABC.c ABC.a |main=|@presto[~/projects/python/cpython:1059]% ./python.exe /tmp/foo.py 3.11.0a1+ (heads/main:6a533a4238, Oct 18 2021, 15:30:20) [Clang 13.0.0 (clang-1300.0.29.3)] a b c a ABC.a In 3.10, the behavior was reverted back to 3.9, so it makes sense that those two have the same output. Python 3.11 should as well, for now at least, until the SC approves PEP 663 -- nosy: +barry, ethan.furman ___ Python tracker <https://bugs.python.org/issue45493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21736] Add __file__ attribute to frozen modules
Barry A. Warsaw added the comment: Weird. PR 28655 is merged on GH, but still shows open on this bpo ticket. -- ___ Python tracker <https://bugs.python.org/issue21736> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37722] imaplib crashes when trying to read a letter from an imap server imaps.почта.рус
Change by Barry A. Warsaw : -- nosy: -barry ___ Python tracker <https://bugs.python.org/issue37722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45506] Out of source tree builds failing on main - test_importlib others unreliable
Barry A. Warsaw added the comment: FWIW, Greg's test case does not fail for me with 6a533a4238 -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue45506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45324] The frozen importer should capture info in find_spec().
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue45324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45020] Freeze all modules imported during startup.
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue45020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: On Sep 16, 2021, at 00:36, STINNER Victor wrote: > > The commit title is wrong, the default "big" not sys.byteorder: > >int.to_bytes(length=1, byteorder='big', *, signed=False) >int.from_bytes(bytes, byteorder='big', *, signed=False) Oops -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Change by Barry A. Warsaw : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: New changeset 07e737d002cdbf0bfee53248a652a86c9f93f02b by Barry Warsaw in branch 'main': bpo-45155 : Default arguments for int.to_bytes(length=1, byteorder=sys.byteorder) (#28265) https://github.com/python/cpython/commit/07e737d002cdbf0bfee53248a652a86c9f93f02b -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45202] Add 'remove_barry_from_BDFL' future to revert effects of 'from __future__ import barry_as_FLUFL'
Barry A. Warsaw added the comment: This bug made my day! :-D -- ___ Python tracker <https://bugs.python.org/issue45202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: "big" by default -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: On Sep 13, 2021, at 22:12, Vedran Čačić wrote: > > > Vedran Čačić added the comment: > > I'd say yes. Of course, one way to ascertain that would be to conduct a valid > pool. ;-) People can always comment otherwise in the Discourse thread. -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: On Sep 13, 2021, at 13:39, Vedran Čačić wrote: > > The poll is invalid, since the option that most people want is deliberately > not offered. *Is* there an option that most people want? -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: On Sep 13, 2021, at 13:38, STINNER Victor wrote: > It seems like your proposal is mostly guided by: convert an int to a byte > (bytes string of length 1). IMO this case is special enough to justify the > usage of a different function. Like bchr() ? > What if people expect int.to_bytes() always return a single byte, but then > get two bytes by mistake? > > ch = 256 > byte = ch.to_bytes() The OverflowError you’ll get seems reasonable. -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: > I'd probably say "In the face of ambiguity, refuse the temptation to guess". > > As there's disagreement about the 'correct' default, make it None and require > either "big" or "little" if length > 1 (the default). Jelle suggested that over in Discourse, and I’m not opposed, but it does mean that there’s no natural default for byteorder in int.from_bytes(). -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: I created a Discourse poll: https://discuss.python.org/t/what-should-be-the-default-value-for-int-to-bytes-byteorder/10616 -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: That’s okay, Brandt’s improved sys.byteorder is fastest . % ./python.exe -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "little")' 200 loops, best of 11: 94.6 nsec per loop % ./python.exe -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "big")' 200 loops, best of 11: 97.8 nsec per loop % ./python.exe -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10)' 500 loops, best of 11: 79.1 nsec per loop On Sep 12, 2021, at 04:20, Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > Interestingly, "little" is faster than "big". > > $ python3.10 -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "little")' > 500 loops, best of 11: 82.7 nsec per loop > $ python3.10 -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "big")' > 500 loops, best of 11: 90.6 nsec per loop > > -- > > ___ > Python tracker > <https://bugs.python.org/issue45155> > ___ -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: Petr Viktorin added the comment: > > Exactly, a platform-dependent default is a bad idea. A default allows using > the function without the code author & reviewer even being *aware* that there > is a choice, and that is dangerous. I’m not convinced. I’m more concerned with the obscurity of the API. If I saw its use in some code I was reviewing, I’d look it up, and then I’d know exactly what it was doing. -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: On Sep 10, 2021, at 04:06, STINNER Victor wrote: > > If the intent is to create a bytes string of length 1, I'm not sure that > "re-using" this existing API for that is a good idea. Why not? It seems an obvious and simple convenience. -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: Just to point out, struct module also uses “native” (i.e. system) byte order by default. Any choice other than that for to_bytes() seems both arbitrary and inconsistent. > On Sep 10, 2021, at 00:48, Petr Viktorin wrote: > > Exactly, a platform-dependent default is a bad idea. A default allows using > the function without the code author & reviewer even being *aware* that there > is a choice, and that is dangerous. -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: For the common case where you’re using all defaults, it won’t matter. byteorder doesn’t matter when length=1. > On Sep 9, 2021, at 18:12, Raymond Hettinger wrote: > > > Raymond Hettinger added the comment: > > Perhaps instead of the system byte ordering, choose one for the default so > that default encoding/decoding will work cross platform. I think "little" is > the most common (intel and arm). -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Barry A. Warsaw added the comment: > Ah, signed=False by default, so (128).to_bytes() will work. But I still worry > that it can provoke writing more errorprone code. Can you elaborate on that? Obviously no existing code will change behavior. I really don’t expect people to write `(128).to_bytes(signed=True)` by accident. -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Change by Barry A. Warsaw : -- keywords: +patch pull_requests: +26685 pull_request: https://github.com/python/cpython/pull/28265 ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
New submission from Barry A. Warsaw : In the PEP 467 discussion, I proposed being able to use >>> (65).to_bytes() b'A' IOW, adding default arguments for the `length` and `byteorder` arguments to `int.to_bytes()` https://mail.python.org/archives/list/python-...@python.org/message/PUR7UCOITMMH6TZVVJA5LKRCBYS4RBMR/ It occurs to me that this is (1) useful on its own merits; (2) easy to do. So I've done it. Creating this bug so I can link a PR against it. -- components: Interpreter Core messages: 401524 nosy: barry priority: normal severity: normal stage: patch review status: open title: Add default arguments for int.to_bytes() versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44616] Incorrect tracing for "except" with variable
Barry A. Warsaw added the comment: Thanks Ned. Seems you might be right. I thought I'd done a clean test, but in any event, I just pulled 3.10 head and verified that it's producing 100% coverage. Thanks all for the fix! -- resolution: -> fixed status: open -> closed ___ Python tracker <https://bugs.python.org/issue44616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44616] Incorrect tracing for "except" with variable
Barry A. Warsaw added the comment: I just retested my test case (see the coveragepy link below) with Python 3.10 git head and coveragepy git head, and I'm still seeing the misses only in Python 3.10: -- coverage: platform darwin, python 3.10.0-beta-4 --- Name Stmts Miss Branch BrPart Cover Missing - flufl/lock/__init__.py5 0 0 0 100% flufl/lock/_lockfile.py 253 0 80 399% 412->415, 418->420, 535->exit - The lines in question: if is_locked: try: os.unlink(self._lockfile) except OSError as error: if error.errno not in ERRORS: raise # Remove our claim file. try: os.unlink(self._claimfile) except OSError as error: if error.errno not in ERRORS: raise I'm not sure whether coveragepy needs to be updated or whether there are other lurking bugs in Python 3.10. I'm reopening this issue until this is resolved. -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue44616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44616] Incorrect tracing for "except" with variable
Barry A. Warsaw added the comment: Pablo, this is triggered by my bug report here: https://github.com/nedbat/coveragepy/issues/1187 I tested this again today with the 3.10 git head and still got the coverage misses. Happy to try any other combinations. -- ___ Python tracker <https://bugs.python.org/issue44616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44613] Make importlib.metadata non-provisional in Python 3.10
Barry A. Warsaw added the comment: Jason, I think the question you raise re: accelerated deprecation, is probably a RM or SC question. I'll nosy in Pablo and see if he has a strong opinion. -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue44613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44613] Make importlib.metadata non-provisional in Python 3.10
Change by Barry A. Warsaw : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44613] Make importlib.metadata non-provisional in Python 3.10
Barry A. Warsaw added the comment: New changeset 7223ce3b3f50ec8a825e317437ea0359b6ad6856 by Miss Islington (bot) in branch '3.10': bpo-44613: Make importlib.metadata non-provisional (GH-27101) (#27106) https://github.com/python/cpython/commit/7223ce3b3f50ec8a825e317437ea0359b6ad6856 -- ___ Python tracker <https://bugs.python.org/issue44613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44613] Make importlib.metadata non-provisional in Python 3.10
Barry A. Warsaw added the comment: New changeset f6954cdfc50060a54318fb2aea4d80408381243a by Barry Warsaw in branch 'main': bpo-44613: Make importlib.metadata non-provisional (#27101) https://github.com/python/cpython/commit/f6954cdfc50060a54318fb2aea4d80408381243a -- ___ Python tracker <https://bugs.python.org/issue44613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44616] Incorrect tracing for "except" with variable
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue44616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44613] Make importlib.metadata non-provisional in Python 3.10
Change by Barry A. Warsaw : -- keywords: +patch pull_requests: +25649 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27101 ___ Python tracker <https://bugs.python.org/issue44613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44613] Make importlib.metadata non-provisional in Python 3.10
New submission from Barry A. Warsaw : As discussed with Jason, importlib.metadata will be made non-provisional in 3.10. I have a PR in the works for this. -- assignee: barry components: Documentation messages: 397344 nosy: barry, jaraco priority: normal severity: normal status: open title: Make importlib.metadata non-provisional in Python 3.10 versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue44613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33025] urlencode produces bad output from ssl.CERT_NONE and friends that chokes decoders
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue33025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43945] [Enum] standardize format() behavior
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue43945> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue44246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44498] add deprecation warnings for asynchat, asyncore and smtpd
Barry A. Warsaw added the comment: New changeset 8488b85c6397fe58f17fc00e047044c959ac0b04 by Barry Warsaw in branch 'main': bpo-44498: Issue a deprecation warning on asynchat, asyncore and smtpd import (#26882) https://github.com/python/cpython/commit/8488b85c6397fe58f17fc00e047044c959ac0b04 -- ___ Python tracker <https://bugs.python.org/issue44498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44498] move deprecated asynchat, asyncore and smtpd from the stdlib to test.support
Change by Barry A. Warsaw : -- pull_requests: +25459 pull_request: https://github.com/python/cpython/pull/26882 ___ Python tracker <https://bugs.python.org/issue44498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44498] move deprecated asynchat, asyncore and smtpd from the stdlib to test.support
Barry A. Warsaw added the comment: +1 for removal -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue44498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40280] Consider supporting emscripten/webassembly as a build target
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue40280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43817] Add typing.get_annotations()
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue43817> ___ ___ 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 beat me to it. PRs approved! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ 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'd still like to. I'm also happy to review any PRs if someone beats me to it. -- ___ 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
[issue42728] Typo in documentation: importlib.metadata
Barry A. Warsaw added the comment: Thanks for the report and fix! -- stage: patch review -> resolved status: open -> closed versions: +Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42728] Typo in documentation: importlib.metadata
Change by Barry A. Warsaw : -- nosy: +barry, jaraco ___ Python tracker <https://bugs.python.org/issue42728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28468] Add platform.freedesktop_os_release()
Barry A. Warsaw added the comment: This issue was brought to the Python Steering Council, and we deliberated it at today's SC meeting. With a vote of 4 approvals and one abstention, we have approved the addition of this API. -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue28468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed
Change by Barry A. Warsaw : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.8, Python 3.9 ___ 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
[issue42155] email.utils.parsedate_to_datetime() should return None when date cannot be parsed
Change by Barry A. Warsaw : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42155] email.utils.parsedate_to_datetime() should return None when date cannot be parsed
Barry A. Warsaw added the comment: Hi Serhiy. I believe this is a duplicate of bpo-30681 which is active and has a good PR IMHO. The only hold up is whether to backport that PR to 3.9 and 3.8. See the bug and PR for details. -- resolution: -> duplicate superseder: -> email.utils.parsedate_to_datetime() should return None when date cannot be parsed ___ Python tracker <https://bugs.python.org/issue42155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed
Barry A. Warsaw added the comment: Aside: I noticed that on _parseaddr.py:68, there's a bare `return`. That should really be `return None` (EIBTI). Can you fix that in your PR? I think it's confusing to raise both TypeError and ValueError. I suggest we check the `None` return from _parsedate_tz() and raise ValueError explicitly in that case, avoiding the implicit TypeError on the failing tuple unpack. +1 on removing the mention of returning None from the documentation. Then with the above, it would document raising ValueError on invalid date input. As for backporting, I'm nosing Ned and Łukasz to weigh in. Given that the patch is adding a new defect class (which it should), this won't break existing code, but it does mean that existing code would have different semantics depending on the patch version release of 3.9, 3.8, and 3.7. I'm not completely comfortable with that, but let's see what the RMs say. I guess I'm currently -0 on backporting. -- nosy: +lukasz.langa, ned.deily ___ 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
[issue42129] Support resources in namespace packages
Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue42129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38486] Dead links in mailbox doc
Barry A. Warsaw added the comment: Thanks for the PR @ZackerySpytz - this has landed in git head and is currently being backported to 3.9 and 3.8 (3.7 is in security-fix only mode). -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.7 ___ Python tracker <https://bugs.python.org/issue38486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38486] Dead links in mailbox doc
Change by Barry A. Warsaw : -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue38486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
