[issue1673409] datetime module missing some important methods
Jon Ribbens added the comment: Almost everything you just said about time_t is wrong. time_t is signed, and always has been (otherwise the 'end of time' for 32-bit time_t would be 2106, not 2038). Also, time_t does not end at 2038 because nothing says it must be 32 bits. Also, Python has 'long integers' which do not overflow. Also, I don't understand what you mean about use cases. The "use case" is "dealing with anything which expects standard Unix time_t, for example the Python standard library". The use case I have personally is the program I was working on when I encountered the problem described in this bug report. Also I think symmetry is a darn good argument. Why does fromtimestamp exist if, as you claim, nobody uses time_t? _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Jon Ribbens added the comment: > No fractions of a second... If we're expecting floating-point, then everything you said earlier about the limitations of ints was a bit redundant ;-) _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Jon Ribbens added the comment: Well, I still think that a convert-to-time_t function is essential, and I don't buy any of the counter-arguments so far. The only argument I can see is "should it return float or integer?" - floats are inaccurate and integers can't represent partial seconds. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Jon Ribbens added the comment: Skip has already provided what amounts to a patch. It just needs to be decided whether to (a) not include it, (b) include it with the floating point part, or (c) include it without the floating point part. I couldn't comment as to how many people need it. I can say that I need it, and anyone else who's used to manipulating dates and times either "in a unixy sort of way" or with libraries that are expecting time_t's will need it. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Jon Ribbens added the comment: > A timedelta.toseconds method (or equivalent) makes no sense. > The number of seconds in a day is not fixed (due to leap seconds) and > relying on such a method would introduce subtle bugs. You are misunderstanding what timedelta is. It is a fixed-length period of time. It is stored as a number of (24x3600-second) days, seconds and microseconds. There is no "start date" or "end date", so the concept of leap seconds just does not apply. ___ Python tracker <http://bugs.python.org/issue1673409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35863] email.headers wraps headers badly
New submission from Jon Ribbens :
email.headers can wrap headers by putting a FWS as the very first thing in the
output:
>>> from email.header import Header
>>> Header("a" * 67, header_name="Content-ID").encode()
'\n aaa'
i.e. it produces headers that look like this:
Content-ID:
blah
It is unclear to me whether this is compliant with the spec, but there seems to
be little reason to do this, and good reason not to in that at the very least
Outlook does not understand such headers. (e.g. if you have an HTML email with
an inline image referenced by Content-ID then Outlook will not find it if the
Content-ID header is wrapped as above.)
--
components: Library (Lib)
messages: 334594
nosy: jribbens
priority: normal
severity: normal
status: open
title: email.headers wraps headers badly
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue35863>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35863] email.headers wraps headers badly
Jon Ribbens added the comment: It is not correct folding. It might not be explicitly forbidden, but it is clearly unwise, and is breaking 'conservative in what you send'. Outlook will not be the only program that fails to parse Python's output. -- ___ Python tracker <https://bugs.python.org/issue35863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35863] email.headers wraps headers badly
Jon Ribbens added the comment: I did read the RFCs. I suspect the [CFWS] in the msg-id is for the benefit of the references production which contains a list of msg-ids. The 78-character suggested line length limit is explicitly noted as being for display purposes, and therefore is of little application to headers which are not displayed in user interfaces. Also consider that the Python wrapping code produces "\n ..." when given a header that is 80 indivisible characters long, when there is no possibility of avoiding a line over 78 characters. Outlook seems to cope alright with other headers (I tried From and Subject) being wrapped like this; I shudder to think what their code must be like in order to produce this bug. -- ___ Python tracker <https://bugs.python.org/issue35863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30032] email module creates base64 output with incorrect line breaks
New submission from Jon Ribbens:
The email module, when creating base64-encoded text parts, does not process
line breaks correctly - RFC 2045 s6.8 says that line breaks must be converted
to CRLF before base64-encoding, and the email module is not doing this.
>>> from email.mime.text import MIMEText
>>> import base64
>>> m = MIMEText("hello\nthere", _charset="utf-8")
>>> m.as_string()
'Content-Type: text/plain; charset="utf-8"\nMIME-Version:
1.0\nContent-Transfer-Encoding: base64\n\naGVsbG8KdGhlcmU=\n'
>>> base64.b64decode("aGVsbG8KdGhlcmU=")
b'hello\nthere'
You might say that it is the application's job to convert the line endings
before calling MIMEText(), but I think all application authors would be
surprised by this. Certainly the MailMan authors would be, as they say this is
a Python bug not a MailMan bug ;-)
--
components: Library (Lib)
messages: 291434
nosy: jribbens
priority: normal
severity: normal
status: open
title: email module creates base64 output with incorrect line breaks
type: behavior
versions: Python 2.7, Python 3.5
___
Python tracker
<http://bugs.python.org/issue30032>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30033] email module base64-encodes utf-8 text
New submission from Jon Ribbens:
The email module, when creating text parts using character encoding utf-8,
base64-encodes the output even though this is often inappropriate (e.g. if it
is a Western language it is almost never appropriate).
>>> from email.mime.text import MIMEText
>>> m = MIMEText("hello", _charset="utf-8")
>>> m.as_string()
'Content-Type: text/plain; charset="utf-8"\nMIME-Version:
1.0\nContent-Transfer-Encoding: base64\n\naGVsbG8=\n'
--
components: Library (Lib)
messages: 291435
nosy: jribbens
priority: normal
severity: normal
status: open
title: email module base64-encodes utf-8 text
type: behavior
versions: Python 2.7, Python 3.5
___
Python tracker
<http://bugs.python.org/issue30033>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30033] email module base64-encodes utf-8 text
Jon Ribbens added the comment: Just a note for anyone finding this in searching results: it appears that what David means by "python3 API" is actually a new API in Python 3.6 (email.message.EmailMessage). -- ___ Python tracker <http://bugs.python.org/issue30033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30032] email module creates base64 output with incorrect line breaks
Jon Ribbens added the comment: OK cool, but please note that this is a MIME issue not an SMTP issue - if the message has text that is being base64-encoded then it must use CRLF line breaks regardless of whether SMTP is involved or not. -- ___ Python tracker <http://bugs.python.org/issue30032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30032] email module creates base64 output with incorrect line breaks
Jon Ribbens added the comment:
So on further investigation, with the new API and policy=SMTP, it does generate
correct base64 output. So I guess on the basis that the new version can
generate the right output, and it appears to be a deliberate choice that the
default policy breaks the RFCs, you can close this issue ;-)
>>> from email.message import EmailMessage
>>> from email.policy import SMTP
>>> import base64
>>> msg = EmailMessage(policy=SMTP)
>>> msg.set_content("hello\nthere", cte="base64")
>>> msg.as_string()
'Content-Type: text/plain; charset="utf-8"\r\nContent-Transfer-Encoding:
base64\r\nMIME-Version: 1.0\r\n\r\naGVsbG8NCnRoZXJlDQo=\r\n'
>>> base64.b64decode("aGVsbG8NCnRoZXJlDQo=")
b'hello\r\nthere\r\n'
--
___
Python tracker
<http://bugs.python.org/issue30032>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34124] email.message_from_binary_file documentation is broken
New submission from Jon Ribbens : The documentation for email.message_from_binary_file is missing a line-continuation backslash at the end of the `.. function::` line which means the output formatting is mangled and it has no permalink. -- assignee: docs@python components: Documentation messages: 321733 nosy: docs@python, jribbens priority: normal severity: normal status: open title: email.message_from_binary_file documentation is broken type: compile error versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34124] email.message_from_binary_file documentation is broken
Change by Jon Ribbens : -- keywords: +patch pull_requests: +7831 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24807] compileall can cause Python installation to fail
New submission from Jon Ribbens: If you are installing Python 2.7.10 and a previous version of 2.7 was already installed, the installation processs can fail when compileall.py finds badly-written third-party modules in the site-packages or dist-packages directories. The installation process should either ignore errors from compileall.py, or compileall.py should be told to ignore the site-packages and dist-packages directories. -- components: Installation messages: 248121 nosy: Jon Ribbens priority: normal severity: normal status: open title: compileall can cause Python installation to fail type: compile error versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue24807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
