[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:

[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:

[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:

[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:

[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 extrac

[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

[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

[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/issue46

[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:

[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.o

[issue46328] add sys.exception()

Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker <https://bugs.python.org/issue46328> ___ ___ Python-bugs-list mailing list Unsubscribe:

[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/i

[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

[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

[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 > t

[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

[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:

[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:

[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:

[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

[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

[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

[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 <ht

[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:

[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 tha

[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? > >

[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

[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

[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

[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/issue45

[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

[issue35673] Loader for namespace packages

Change by Barry A. Warsaw : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[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:

[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

[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 Unsub

[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

[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/issue42

[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

[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/issu

[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/issue35

[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.

[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

[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/issue35

[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/issu

[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/issue35

[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/issu

[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

[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/issue21

[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:

[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/issue45

[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:

[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:

[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

[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.or

[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

[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 mailin

[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

[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 th

[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? -- ___ Pytho

[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.

[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 defa

[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/issue45

[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_byte

[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

[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

[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-

[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

[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

[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/issue45

[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.or

[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 ->

[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

[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

[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 <ht

[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.or

[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

[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

[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:

[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/issu

[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

[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:

[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:

[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:

[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

[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/issue44

[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 mailin

[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:

[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:

[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.or

[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/issue37

[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/i

[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:

[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

[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.or

[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

[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 superse

[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

[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:

[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: -P

[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:

  1   2   3   4   5   6   7   8   9   10   >