[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.datetime(2021, 12, 9, 8, 52, 4)
>>> email.utils.parsedate_to_datetime('9 Dec 2021 08:52:04 +')
datetime.datetime(2021, 12, 9, 8, 52, 4, tzinfo=datetime.timezone.utc)
I observe the same behavior on Python 3.9.9 and 3.10.1.
--
components: email
messages: 408149
nosy: barry, fdrake, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.parsedate_to_datetime() handling of - offset
type: behavior
versions: Python 3.10, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46027>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 -- ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 -- ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 -- ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, but... there's a lot I don't remember at this point. --sigh-- Removing the reference to os.sep from the os.path.join() description would not be confusing, IMO. Clearly, the ambiguity can bite. I'd be open to a patch to remove the reference to os.sep from the os.path.join() docs. Reopening, but removing 3.6 and 3.7 since they're in security-fix-only mode. -- keywords: +easy resolution: not a bug -> stage: resolved -> needs patch status: closed -> open versions: -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 isn't a work-around. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/9bdb5802361016704fb3434369741cc6c5e08f02 -- ___ Python tracker <https://bugs.python.org/issue43353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue43353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 for it, but as a value, it's still textual. I'm referring specifically to the change here: https://github.com/python/cpython/commit/bbba28212ce0f58096a4043f32442c6e727b74fc#diff-1bf0ad6d121df3948853dafdd8e5406709fe0c3911b30e3cf2def41717455c98R121 Otherwise, I do believe this should be back-ported. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue43353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue39994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue39994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 change for cases like the MyDict example from iritkatriel. The intent of the original code was that MyDict.__repr__ would be used; only the small handful of "known" reprs would be handled specially. -- ___ Python tracker <https://bugs.python.org/issue39994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- ___ Python tracker <https://bugs.python.org/issue40065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 on xml.etree.cElementTree, I had to dig into the history to determine that it was removed intentionally. Updated documentation would have helped. I did file an issue on the dependency as well: https://github.com/boto/botocore/issues/2002 -- ___ Python tracker <https://bugs.python.org/issue40065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 priority: normal severity: normal status: open title: py39: remove deprecation note for xml.etree.cElementTree versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker <https://bugs.python.org/issue40064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 -> closed ___ Python tracker <https://bugs.python.org/issue38621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue38621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker <https://bugs.python.org/issue38619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue38621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 the argument '=?utf-8?Q?$?=201.71 credit card reward certificate by the end of the year' get_encoded_word eventually calls email._encoded_words.decode with the argument '=?utf-8?Q?$?=201.71 credit card reward certificate by the end of the year?=' This doesn't seem right, but I'm unsure of the syntactic priority of =XX and ?= in this case. The policy for this is email.policy.SMTP + email.policy.strict (not sure if that's ideal; I'm retrieving messages from mbox files and over IMAP). -- assignee: r.david.murray messages: 355564 nosy: barry, fdrake, r.david.murray priority: normal severity: normal status: open title: Bad decoding of encoded-words in unstructured email headers ___ Python tracker <https://bugs.python.org/issue38621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
