[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

[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

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

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

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

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

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

[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

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

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

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

[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

[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

[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

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

[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