[issue46027] email.utils.parsedate_to_datetime() handling of -0000 offset

New submission from Fred Drake : A local time offset of '-' is not handled the same way as an offset of '+', but I'd expect it would be: >>> import email.utils >>> >>> email.utils.parsedate_to_datetime('9 Dec 2021 08:52:04 -') datetime.dat

[issue43620] os.path.join does not use os.sep as documentation claims

Fred Drake added the comment: PR applied and backported; closing this. Thanks, Jared! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue43620] os.path.join does not use os.sep as documentation claims

Fred Drake added the comment: New changeset 455583b54aaec9a4266ff37dd438cbbd8ec6068a by Miss Islington (bot) in branch '3.8': bpo-43620: Remove reference to os.sep from os.path.join() doc (GH-25025, GH-5030) https://github.com/python/cpython/commit/455583b54aaec9a4266ff37dd438cbbd8ec6068a

[issue43620] os.path.join does not use os.sep as documentation claims

Fred Drake added the comment: New changeset f311290f091957653bba5ebfda28ad981bb78363 by Miss Islington (bot) in branch '3.9': bpo-43620: Remove reference to os.sep from os.path.join() doc (GH-25025) (#25027) https://github.com/python/cpython/commit/f311290f091957653bba5ebfda28ad981bb78363

[issue43620] os.path.join does not use os.sep as documentation claims

Fred Drake added the comment: New changeset 21a2cabb3795f5170c746ab8f29e9d25c7442550 by Jared Sutton in branch 'master': bpo-43620: Remove reference to os.sep from os.path.join() doc (#25025) https://github.com/python/cpython/commit/21a2cabb3795f5170c746ab8f29e9d25c7442550

[issue43620] os.path.join does not use os.sep as documentation claims

Fred Drake added the comment: Just reviewed the documentation for both os.sep and os.path.join(). The os.sep docs do not suggest it can be set, and the reference in the os.path.join() description is silent regarding that, so can be read as Jared did. I don't recall this coming up before

[issue43620] os.path.join does not use os.sep as documentation claims

Fred Drake added the comment: Perhaps Jared was expecting that modifying os.sep would affect the functions in os.path? os.sep was never intended to be updated. Using the specific *path modules to work with "foreign" paths has long been advocated as the way to do this. It is

[issue43353] Document that logging.getLevelName() can return a numeric value.

Fred Drake added the comment: New changeset 9bdb5802361016704fb3434369741cc6c5e08f02 by Mariusz Felisiak in branch '3.8': bpo-43353: Document that logging.getLevelName() accepts string representation of logging level. (GH-24693) (#24825) https://github.com/python/cpython/commit

[issue43353] Document that logging.getLevelName() can return a numeric value.

Fred Drake added the comment: Mariusz: Good point. IMO, an insane API behavior, but a legacy we must live with. No further objections from me. -- ___ Python tracker <https://bugs.python.org/issue43

[issue43353] Document that logging.getLevelName() can return a numeric value.

Fred Drake added the comment: Just noticed this fly by in the stream of emails... sorry for not commenting earlier. The patch seems to describe "Level #" as "numeric", which I would not be inclined to do. It includes the numeric value since there's no available name fo

[issue41111] [C API] Convert a few stdlib extensions to the limited C API (PEP 384)

Change by Fred Drake : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39994] pprint handling of dict subclasses that override __repr__

Fred Drake added the comment: And that is why the original code was checking not only for the type, but the actual __repr__ method itself. I think the current behavior is broken. -- ___ Python tracker <https://bugs.python.org/issue39

[issue39994] Redundant code in pprint module.

Fred Drake added the comment: Ah, good find! It's been so long since the first version of that code, but the implementation was surprisingly nuanced. -- ___ Python tracker <https://bugs.python.org/issue39

[issue39994] Redundant code in pprint module.

Fred Drake added the comment: Adding serhiy.storchaka to nosy list since it looks like he introduced the isinstance check on purpose (see bpo-23741). Though bpo-23741 asserts that no behavior was changed with the patch applied then, reading through the change leads me to think this did

[issue40065] py39: remove deprecation note for xml.etree.cElementTree

Fred Drake added the comment: The Python 2.7 documentation was not clear that xml.etree.cElementTree was optional, so users who didn't dive into the implementation or build process could easily not have known unless someone with a more limited installation used their code

[issue40065] py39: remove deprecation note for xml.etree.cElementTree

Fred Drake added the comment: Same core problem (module removed with insufficient document update), but a different action is needed for 3.8 and 3.9. When I started testing an application with 3.9 and found one of the dependencies broken because it was relying directly

[issue40065] py39: remove deprecation note for xml.etree.cElementTree

New submission from Fred Drake : Since xml.etree.cElementTree does not exist in Python 3.9, the statement that it's deprecated should be removed from the documentation. -- assignee: docs@python components: Documentation keywords: easy messages: 365016 nosy: docs@python, fdrake

[issue40064] py38: document xml.etree.cElementTree will be removed in 3.9

Change by Fred Drake : -- keywords: +easy ___ Python tracker <https://bugs.python.org/issue40064> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40064] py38: document xml.etree.cElementTree will be removed in 3.9

Change by Fred Drake : -- assignee: docs@python components: Documentation nosy: docs@python, fdrake priority: normal severity: normal status: open title: py38: document xml.etree.cElementTree will be removed in 3.9 versions: Python 3.8 ___ Python

[issue39480] referendum reference is needlessly annoying

Change by Fred Drake : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue39480> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38351] Modernize email example from %-formatting to f-string

Fred Drake added the comment: Thanks, Julien! Sounds good to me; no reason for a PR addressing this specific issue to be held up once one becomes available. -- ___ Python tracker <https://bugs.python.org/issue38

[issue38621] Bad decoding of encoded-words in unstructured email headers

Change by Fred Drake : -- resolution: fixed -> rejected stage: resolved -> ___ Python tracker <https://bugs.python.org/issue38621> ___ ___ Python-bugs-

[issue38621] Bad decoding of encoded-words in unstructured email headers

Fred Drake added the comment: It turns out this was a problem in 3.7.4; Python 3.7.5 seems to have fixed this. Sorry for the noise. Guess it's time to update my application to use 3.7.5! -- resolution: -> fixed stage: -> resolved status: open -&g

[issue38621] Bad decoding of encoded-words in unstructured email headers

Fred Drake added the comment: This problem does not exist in Python 3.6 or Python 3.8; it appears to only exist in Python 3.7. -- versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue38

[issue38619] [Doc] UUID.hex is lowercase

Fred Drake added the comment: While I don't know Felipe's use case, I would expect the documentation to be clear that the representation won't change in the future so users will know that this can be relied on to generate keys into some other persistent structure. -- nosy: +fdrake

[issue38621] Bad decoding of encoded-words in unstructured email headers

Fred Drake added the comment: It's worth noting that dealing with this header eventually causes the header parser to enter an infinite loop. -- ___ Python tracker <https://bugs.python.org/issue38

[issue38621] Bad decoding of encoded-words in unstructured email headers

New submission from Fred Drake : I've encountered a problem parsing an email with this Subject: header: Subject: Be sure to redeem your =?utf-8?Q?$?=201.71 credit card reward certificate by the end of the year email._header_value_parser.get_unstructured defers to get_encoded_word, passing

Re: [Python-Dev] [ANN] Python 2.3.7 and 2.4.5, release candidate 1

’ make: *** [Modules/posixmodule.o] Error 1 I can only presume I'm doing something wrong at this point, since I don't consider myself a Mac OS X developer. -Fred -- Fred Drake fdrake at acm.org -- http://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] [ANN] Python 2.3.7 and 2.4.5, release candidate 1

On Mar 2, 2008, at 7:43 PM, Fred Drake wrote: 2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2: Neither does 2.3.7 now that I've tried that: gcc -u __dummy -u _PyMac_Error -framework System -framework CoreServices -framework Foundation -o python.exe

Re: [Python-Dev] [ANN] Python 2.3.7 and 2.4.5, release candidate 1

-- Fred Drake fdrake at acm.org -- http://mail.python.org/mailman/listinfo/python-list