[issue44445] Add `site-include` install scheme path in sysconfig
Change by Dmitry Shachnev : -- nosy: +mitya57 ___ Python tracker <https://bugs.python.org/issue5> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37504] Documentation fails to build when using Sphinx' texinfo builder
Change by Dmitry Shachnev : -- title: 3.8 b2 now requires sphinx2, but only has documented 1.8 -> Documentation fails to build when using Sphinx' texinfo builder ___ Python tracker <https://bugs.python.org/issue37504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37504] 3.8 b2 now requires sphinx2, but only has documented 1.8
Change by Dmitry Shachnev : -- keywords: +patch pull_requests: +14421 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14606 ___ Python tracker <https://bugs.python.org/issue37504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37504] 3.8 b2 now requires sphinx2, but only has documented 1.8
Change by Dmitry Shachnev : -- nosy: +mitya57 ___ Python tracker <https://bugs.python.org/issue37504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22543] -W option cannot use non-standard categories
Change by Dmitry Shachnev : -- nosy: +mitya57 ___ Python tracker <https://bugs.python.org/issue22543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28401] Don't support the PEP384 stable ABI in pydebug builds
Dmitry Shachnev added the comment: [Matthias Klose (doko) 2016-10-27 15:45] > I'm not sure that you really want this, because it would make it impossible > to build an extension for the stable ABI for a debug build. It looks like that is already impossible: /usr/include/python3.5dm/object.h:65:2: error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG ^ So in my opinion Stefano's patch makes sense. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28401] Don't support the PEP384 stable ABI in pydebug builds
Changes by Dmitry Shachnev <mity...@gmail.com>: -- nosy: +mitya57 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28314] ElementTree: Element.getiterator(tag) broken in 3.6
New submission from Dmitry Shachnev:
The documentation says that getiterator() still accepts a tag argument, but it
does not:
>>> from xml.etree.ElementTree import Element
>>> el = Element('foo')
>>> el.getiterator('bar')
Traceback (most recent call last):
File "", line 1, in
SystemError: ../Python/getargs.c:1508: bad argument to internal function
>>> el.getiterator(tag='bar')
Traceback (most recent call last):
File "", line 1, in
TypeError: iter() takes at most 1 argument (140172072006928 given)
This is with Python 3.6.0 beta 1 on Debian GNU/Linux amd64.
--
components: Library (Lib)
messages: 277717
nosy: mitya57
priority: normal
severity: normal
status: open
title: ElementTree: Element.getiterator(tag) broken in 3.6
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28314>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26542] Wrongly formatted doctest block in difflib documentation
New submission from Dmitry Shachnev: Look at the documentation of difflib.SequenceMatcher.get_opcodes: https://docs.python.org/dev/library/difflib.html#difflib.SequenceMatcher.get_opcodes There, the result part of the example is rendered as plain reStructuredText, separately from the code block itself. The attached patch fixes it. -- assignee: docs@python components: Documentation files: doctest.diff keywords: patch messages: 261591 nosy: docs@python, mitya57 priority: normal severity: normal status: open title: Wrongly formatted doctest block in difflib documentation type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file42137/doctest.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24125] Fix for #23865 breaks docutils
Dmitry Shachnev added the comment: The patch fixes the issue, thanks Serhiy! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24125 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23865] Fix possible leaks in close methods
Dmitry Shachnev added the comment: This broke docutils, see issue #24125. -- nosy: +mitya57 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23865 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24125] Fix for #23865 breaks docutils
New submission from Dmitry Shachnev: Fix for issue #23865 (i.e. https://hg.python.org/cpython/rev/f7ddec2e9e93 in 2.7 branch) introduced a change for xml.sax.expatreader.ExpatParser class that makes its close() method delete _parser object. This breaks docutils, which handles exceptions in parse() and tries to use getColumnNumber() after it fails. The log is available here: http://mitya57.me/builds/python-docutils_0.12+dfsg-1_amd64.build. I believe that particular chunk should be reverted. -- components: Library (Lib) messages: 242579 nosy: doko, goodger, mitya57, serhiy.storchaka priority: normal severity: normal status: open title: Fix for #23865 breaks docutils versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24125 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24125] Fix for #23865 breaks docutils
Changes by Dmitry Shachnev mity...@gmail.com: -- nosy: +larry versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24125 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Dmitry Shachnev added the comment: Now the patch works with tzdata = 2011k, which is quite old. @David: yes, with the unpatched version only one of the tests should fail. -- Added file: http://bugs.python.org/file37721/issue22932_combined_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Dmitry Shachnev added the comment: Can it be that you have outdated tzdata? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Changes by Dmitry Shachnev mity...@gmail.com: Added file: http://bugs.python.org/file37683/issue22932_combined.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Dmitry Shachnev added the comment: This patch adds a test case for formatdate() function. Before applying issue22932_v3.patch it fails, after applying that patch it succeeds. Sorry for the delay caused by holidays. -- Added file: http://bugs.python.org/file37675/issue22932_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Dmitry Shachnev added the comment: Thanks, I did not know that. Here is version 3. -- Added file: http://bugs.python.org/file37402/issue22932_v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Dmitry Shachnev added the comment: Here is the updated patch based on Alexander’s suggestion. Works fine, the only difference with previous behavior is that the zero time zone is now + instead of -. -- Added file: http://bugs.python.org/file37394/issue22932_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22930] Value of time.timezone is sometimes wrong
New submission from Dmitry Shachnev: Here, on Linux, I get: $ python3 -c import time; print(time.timezone) -14400 … which means I am in UTC+4. However, Russia recently (in October) switched time, and moved from UTC+4 to UTC+3 timezone (my tzdata is up-to-date), so this reported value is wrong. The relevant code in timemodule.c looks like (simplified): #define YEAR ((time_t)((365 * 24 + 6) * 3600)) time_t t = (time((time_t *)0) / YEAR) * YEAR; struct tm *p = localtime(t); janzone = -p-tm_gmtoff; PyModule_AddIntConstant(m, timezone, janzone); The value of t is the *January 1st* of current year, i.e. 2014-01-01 currently. But the timezone of a country in the year beginning may be different from its timezone in the year end, which is the case for me. This bug will be relevant for Russia until the end of 2014, but may be still relevant for other countries that wish to change their timezone. -- components: Extension Modules messages: 231597 nosy: mitya57 priority: normal severity: normal status: open title: Value of time.timezone is sometimes wrong type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22930 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22752] incorrect time.timezone value
Dmitry Shachnev added the comment: Is it possible to set timezone based on localtime(current_time) where current_time is the result of time() call? This bug is not just about returning the wrong timezone. Because of it, the full time string produced with Python may be wrong. For example, my mail sending program uses `email.utils.formatdate(localtime=True)', and that is returning a time one hour in the past currently. -- nosy: +mitya57 status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22752 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
New submission from Dmitry Shachnev: The value of time.timezone may be wrong sometimes (see http://bugs.python.org/issue22752), so I think the email library should not use it: $ python3 -c from email.utils import formatdate; print(formatdate(localtime=True)) Mon, 24 Nov 2014 19:16:32 +0400 $ date -R Mon, 24 Nov 2014 19:16:32 +0300 Using something from datetime module may be a better solution. -- components: Library (Lib) messages: 231608 nosy: belopolsky, mitya57 priority: normal severity: normal status: open title: email.utils.formatdate uses unreliable time.timezone constant versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22932] email.utils.formatdate uses unreliable time.timezone constant
Dmitry Shachnev added the comment: This patch fixes the issue for me. -- keywords: +patch Added file: http://bugs.python.org/file37266/issue22932.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14983] email.generator should always add newlines after closing boundaries
Dmitry Shachnev added the comment: Thank you for committing this! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20208] Clarify some things in porting HOWTO
Changes by Dmitry Shachnev mity...@gmail.com: -- nosy: +mitya57 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20208 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20093] Wrong OSError message from os.rename() when dst is a non-empty directory
Dmitry Shachnev added the comment: This is a result of http://hg.python.org/cpython/rev/6903f5214e99. Looks like we should check the error code and conditionally set the file name to either src or dst. -- nosy: +haypo, mitya57 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20093 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17761] platform._parse_release_file doesn't close the /etc/lsb-release file, doesn't know about 'Ubuntu'
Changes by Dmitry Shachnev mity...@gmail.com: -- nosy: +mitya57 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17761 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11245] Implementation of IMAP IDLE in imaplib?
Changes by Dmitry Shachnev mity...@gmail.com: -- nosy: +mitya57 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17354] TypeError when running setup.py upload --show-response
New submission from Dmitry Shachnev:
When running `python3 setup.py sdist upload --show-response`, one may get this
exception:
Traceback (most recent call last):
File setup.py, line 47, in module
requires=['dbus']
File /usr/lib/python3.2/distutils/core.py, line 148, in setup
dist.run_commands()
File /usr/lib/python3.2/distutils/dist.py, line 917, in run_commands
self.run_command(cmd)
File /usr/lib/python3.2/distutils/dist.py, line 936, in run_command
cmd_obj.run()
File /usr/lib/python3.2/distutils/command/upload.py, line 66, in run
self.upload_file(command, pyversion, filename)
File /usr/lib/python3.2/distutils/command/upload.py, line 201, in
upload_file
msg = '\n'.join(('-' * 75, r.read(), '-' * 75))
TypeError: sequence item 1: expected str instance, bytes found
This happens because r is binary stream, so r.read() returns bytes. A trivial
patch that fixes the problem is attached.
--
components: Library (Lib)
files: distutils-decode-server-response.patch
keywords: patch
messages: 183517
nosy: mitya57
priority: normal
severity: normal
status: open
title: TypeError when running setup.py upload --show-response
versions: Python 3.3
Added file:
http://bugs.python.org/file29312/distutils-decode-server-response.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17354
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16089] _elementtree.TreeBuilder broken with a non-C-deriving element_factory
Dmitry Shachnev added the comment: There are still some false-positive warnings caused by C code that affect docutils (see http://sourceforge.net/tracker/?func=detailatid=422030aid=3555164group_id=38414). Look at this traceback for exmaple: http://paste.ubuntu.com/1345164/ There, _ElementInterfaceWrapper is a subclass of etree._ElementInterface (http://repo.or.cz/w/docutils.git/blob/HEAD:/docutils/docutils/writers/odf_odt/__init__.py#l91). -- nosy: +larry, mitya57 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16089 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16089] _elementtree.TreeBuilder broken with a non-C-deriving element_factory
Changes by Dmitry Shachnev mity...@gmail.com: ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16089 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16089] _elementtree.TreeBuilder broken with a non-C-deriving element_factory
Changes by Dmitry Shachnev mity...@gmail.com: ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16089 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15016] Add special case for latin messages in email.mime.text
Dmitry Shachnev mity...@gmail.com added the comment: This seems to be an enhancement sort of request rather than a bug... so I wonder why Python 3.2 is listed? Fixed. ... although I see nothing in the PEP about how to access that information from Python. You are right, it seems there is no Python API for that (yet?), so I don't see any better solutions for determining the maximum character for now. Also, note that this algorithm had already been used before my patch. -- type: behavior - enhancement versions: -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7304] email.message.Message.set_payload and as_string given charset 'us-ascii' plus 8bit data produces invalid message
Changes by Dmitry Shachnev mity...@gmail.com: -- nosy: +mitya57 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7304 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15016] [patch] add special case for latin messages in email.mime.text
New submission from Dmitry Shachnev mity...@gmail.com: (Follow-up to issue 14380) The attached patch makes the email.mime.text.MIMEText constructor use the iso-8859-1 (aka latin-1) encoding for messages where all characters are in range(256). This also makes them use quoted-printable transfer encoding instead of base64. So, the current algorithm of guessing encoding is as follows: - all characters are in range(128) - encoding is us-ascii - all characters are in range(256) - encoding is iso-8859-1 (aka latin-1) - else - encoding is utf-8 -- components: email messages: 162399 nosy: barry, mitya57, r.david.murray priority: normal severity: normal status: open title: [patch] add special case for latin messages in email.mime.text type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15016] [patch] add special case for latin messages in email.mime.text
Changes by Dmitry Shachnev mity...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file25845/issue_15016.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15016] [patch] add special case for latin messages in email.mime.text
Dmitry Shachnev mity...@gmail.com added the comment: Updated the patch: - Avoid using letter Ш in test, it's better to use chr(256) as the test case; - Updated the comment in MIMEText constructor to reflect the new behaviour. -- hgrepos: +135 Added file: http://bugs.python.org/file25846/issue_15016_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15016] [patch] add special case for latin messages in email.mime.text
Changes by Dmitry Shachnev mity...@gmail.com: -- hgrepos: -135 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15016] [patch] add special case for latin messages in email.mime.text
Changes by Dmitry Shachnev mity...@gmail.com: Removed file: http://bugs.python.org/file25845/issue_15016.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15016] Add special case for latin messages in email.mime.text
Dmitry Shachnev mity...@gmail.com added the comment: Done, sent an e-mail to contribut...@python.org. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14983] email.generator should always add newlines after closing boundaries
Dmitry Shachnev mity...@gmail.com added the comment: Hmm. So that means the verifiers are not paying attention to the MIME RFC? That's unfortunate. It seems that's true... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14983 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14983] [patch] email.generator should always add newlines after closing boundaries
New submission from Dmitry Shachnev mity...@gmail.com: Trying to write a email-sending script with PGP-signing functionality, I stumbled upon a problem (see [1]): it was impossible to sign mutlipart emails (actually the signing was performed, but the verifying programs thought that the signature is bad). After comparing messages produced by email.generator and popular mail clients (Evolution, KMail), I've found out that the mail clients always add line breaks after ending boundaries. The attached patch makes email.generator behave like all email clients. After applying it, it's possible to sign even complicated mails like multipart/alternate with attachments. An illustration: --1== # Part 1 (base message) begin ... --2== # Part 1.1 begin ... --2== # Part 1.2 begin ... --2==-- # Part 1 end # There should be empty line here --1== # Part 2 (signature) begin ... --1==-- # End of the message [1]: http://stackoverflow.com/questions/10496902/pgp-signing-multipart-e-mails-with-python -- components: email files: always_add_newlines.patch keywords: patch messages: 162126 nosy: barry, mitya57, r.david.murray priority: normal severity: normal status: open title: [patch] email.generator should always add newlines after closing boundaries type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file25798/always_add_newlines.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14983 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14380] MIMEText should default to utf8 charset if input text contains non-ASCII
Dmitry Shachnev mity...@gmail.com added the comment:
Maybe it'll be better to use 'latin-1' charset for latin-1 texts?
Something like this:
if _charset == 'us-ascii':
try:
_text.encode(_charset)
except UnicodeEncodeError:
try:
_text.encode('latin-1')
except UnicodeEncodeError:
_charset = 'utf-8'
else:
_charset = 'latin-1'
This will make messages in most latin languages use quoted-printable encoding.
--
components: +email -Library (Lib)
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14380
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14983] email.generator should always add newlines after closing boundaries
Dmitry Shachnev mity...@gmail.com added the comment: Looking at your stackoverflow post, you might be able to fix this by doing an rstrip on the string body before signing it. My body doesn't end with \n, so that doesn't help. If you suggest me any (easy) way to fix this on the level of my script, I will be happy. Probably adding the CRLF is the way to go, but I wonder, what are the controlling RFCs for signing/verifying and what do they say? The standard is RFC 1847, it doesn't say anything about multipart emails. I've just looked at what other mail clients do, it works, but I can't say anything about its correctness. Also, looking at some multipart signed emails in my inbox, they *all* have the blank line before the signature part. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14983 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14983] email.generator should always add newlines after closing boundaries
Dmitry Shachnev mity...@gmail.com added the comment: By 'body' I actually meant the multipart part you are signing. Yes, I've understood you, and I mean the same :) The signature is created against the not-ending-with-newline string, in any case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14983 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14360] email.encoders.encode_quopri doesn't work with python 3.2
Dmitry Shachnev mity...@gmail.com added the comment: Then, which types of argument should encode_* functions take (I think str should be supported, and it's not a case here as encode_quopri will only accept bytes)? I meant which types of *payload* should they accept. Here's an illustration of what I mean: http://paste.ubuntu.com/894731/. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14360] email.encoders.encode_quopri doesn't work with python 3.2
Dmitry Shachnev mity...@gmail.com added the comment: (Sorry for not replying earlier). I think the main priority here is getting things working, not the tests (so I have little interest in that). First of all, should quopri.encodestring() really return bytes? Everything it returns is ascii text, obviously. Then, which types of argument should encode_* functions take (I think str should be supported, and it's not a case here as encode_quopri will only accept bytes)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14360] email.encoders.encode_quopri doesn't work with python 3.2
Dmitry Shachnev mity...@gmail.com added the comment:
In fact, there's really no reason to call an encode_ method at all, since if
you pass a string to MIMEText when giving it a non-ascii unicode string, it
will default to utf-8 and do the appropriate CTE encoding.
No, it doesn't:
Python 3.2.3rc1 (default, Mar 9 2012, 23:02:43)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more information.
from email.mime.text import MIMEText
print(MIMEText('йцукен'))
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
йцукен
As you can see, it leaves russian text in unmodified state and sets the charset
to us-ascii. Should it be considered as a bug?
What is your use case, by the way?
I'm writing a send via e-mail plugin for my ReText editor
(http://retext.sourceforge.net/).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14360
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14360] email.encoders.encode_quopri doesn't work with python 3.2
Dmitry Shachnev mity...@gmail.com added the comment: You can get it to work by explicitly passing the charset Thanks, I didn't know about that. Given the above, do you need it anymore? No. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14360] email.encoders.encode_quopri doesn't work with python 3.2
New submission from Dmitry Shachnev mity...@gmail.com:
Currently my /usr/lib/python3.2/email/encoders.py has this code:
def _qencode(s):
enc = _encodestring(s, quotetabs=True)
# Must encode spaces, which quopri.encodestring() doesn't do
return enc.replace(' ', '=20')
The problem is that _encodestring (which is just quopri.encodestring) always
returns bytes, trying to run replace() on bytes raises TypeError: expected an
object with the buffer interface.
This leads to email.encoders.encode_quopri never working.
So, I think this should be changed to something like this:
...
return enc.decode().replace(' ', '=20')
Example log:
Python 3.2.3rc1 (default, Mar 9 2012, 23:02:43)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more information.
import email.encoders
from email.mime.text import MIMEText
msg = MIMEText(b'some text here')
email.encoders.encode_quopri(msg)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.2/email/encoders.py, line 44, in encode_quopri
encdata = _qencode(orig)
File /usr/lib/python3.2/email/encoders.py, line 23, in _qencode
return enc.replace(' ', '=20')
TypeError: expected an object with the buffer interface
Reproduced on Ubuntu precise with Python 3.2.3rc1. Replacing encode_quopri with
encode_base64 works fine.
--
components: Library (Lib)
messages: 156238
nosy: barry, mitya57
priority: normal
severity: normal
status: open
title: email.encoders.encode_quopri doesn't work with python 3.2
type: crash
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14360
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14360] email.encoders.encode_quopri doesn't work with python 3.2
Changes by Dmitry Shachnev mity...@gmail.com: -- type: crash - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
