[issue24669] inspect.getsource() returns the wrong lines for coroutine functions
Changes by Kai Groner : -- components: Library (Lib) nosy: groner priority: normal severity: normal status: open title: inspect.getsource() returns the wrong lines for coroutine functions type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue24669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24669] inspect.getsource() returns the wrong lines for coroutine functions
New submission from Kai Groner: inspect.findsource() looks for lines that start with `def`. This patch adds a clause to the regex so lines starting with `async def` will also be recognized. -- keywords: +patch Added file: http://bugs.python.org/file39950/inspect-getsource-asyncdef.patch ___ Python tracker <http://bugs.python.org/issue24669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25235] EmailMessage.add_attachment() creates parts with spurious MIME-Version header.
New submission from Kai Groner: Because MIMEPart.add_attachment() creates parts using type(self), EmailMessage.add_attachment() creates parts of type EmailMessage. This results in a MIME-Version header being added to parts where it isn't needed. https://tools.ietf.org/html/rfc2045#section-4 -- components: email files: test_add_attachment_does_not_add_MIME_Version_in_attachment.patch keywords: patch messages: 251600 nosy: barry, groner, r.david.murray priority: normal severity: normal status: open title: EmailMessage.add_attachment() creates parts with spurious MIME-Version header. type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file40576/test_add_attachment_does_not_add_MIME_Version_in_attachment.patch ___ Python tracker <http://bugs.python.org/issue25235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25235] EmailMessage.add_attachment() creates parts with spurious MIME-Version header.
Kai Groner added the comment: Relatedly EmailMessage.make_mixed(), etc don't set MIME-Version on the multipart (it is only set on the part). Additional tests attached. -- Added file: http://bugs.python.org/file40577/test_add_attachment_does_not_add_MIME_Version_in_attachment.patch ___ Python tracker <http://bugs.python.org/issue25235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25235] EmailMessage.add_attachment() creates parts with spurious MIME-Version header.
Changes by Kai Groner : Added file: http://bugs.python.org/file40578/test_MIME_Version.patch ___ Python tracker <http://bugs.python.org/issue25235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25235] EmailMessage.add_attachment() creates parts with spurious MIME-Version header.
Kai Groner added the comment: >From https://tools.ietf.org/html/rfc2045#section-4 > Note that the MIME-Version header field is required at the top level > of a message. It is not required for each body part of a multipart > entity. It is required for the embedded headers of a body of type > "message/rfc822" or "message/partial" if and only if the embedded > message is itself claimed to be MIME-conformant. This patch looks like it avoids adding a MIME-Version header to parts with no mime metadata, but it can actually be omitted from most parts. -- ___ Python tracker <http://bugs.python.org/issue25235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25235] EmailMessage.add_attachment() creates parts with spurious MIME-Version header.
Kai Groner added the comment: I agree that there isn't a way to know if a header should be added implicitly, until Generator is called. A possible change to the Generator behavior is to generate the header in the serialized output, without modifying the original. I don't know that it makes debugging easier, but it would keep the Generator from having this side effect. Maybe being explicit is better, a utility factory could be used to keep the common case simple. I don't know if such a change is reasonable at this point. -- ___ Python tracker <http://bugs.python.org/issue25235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
