Change by Dmitry Shachnev :
--
nosy: +mitya57
___
Python tracker
<https://bugs.python.org/issue5>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issu
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/issu
Change by Dmitry Shachnev :
--
nosy: +mitya57
___
Python tracker
<https://bugs.python.org/issue37504>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Dmitry Shachnev :
--
nosy: +mitya57
___
Python tracker
<https://bugs.python.org/issue22543>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/ob
Changes by Dmitry Shachnev <mity...@gmail.com>:
--
nosy: +mitya57
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28401>
___
__
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
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
Dmitry Shachnev added the comment:
The patch fixes the issue, thanks Serhiy!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24125
___
___
Python
Dmitry Shachnev added the comment:
This broke docutils, see issue #24125.
--
nosy: +mitya57
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23865
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
Changes by Dmitry Shachnev mity...@gmail.com:
--
nosy: +larry
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24125
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
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
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
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
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
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
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
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
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
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
Dmitry Shachnev added the comment:
Thank you for committing this!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14983
___
___
Python-bugs-list
Changes by Dmitry Shachnev mity...@gmail.com:
--
nosy: +mitya57
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20208
___
___
Python-bugs-list
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
Changes by Dmitry Shachnev mity...@gmail.com:
--
nosy: +mitya57
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17761
___
___
Python-bugs-list
Changes by Dmitry Shachnev mity...@gmail.com:
--
nosy: +mitya57
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11245
___
___
Python-bugs-list
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
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
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
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
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
Changes by Dmitry Shachnev mity...@gmail.com:
--
nosy: +mitya57
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7304
___
___
Python-bugs-list
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
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
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
Changes by Dmitry Shachnev mity...@gmail.com:
--
hgrepos: -135
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15016
___
___
Python-bugs-list
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
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
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
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
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
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
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
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
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
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
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
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
Changes by Dmitry Shachnev mity...@gmail.com:
--
type: crash - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14360
___
___
Python-bugs
51 matches
Mail list logo
