[issue13701] Remove Decimal Python 2.3 Compatibility
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +facundobatista, mark.dickinson, rhettinger, skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13701 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12364] Deadlock in test_concurrent_futures
Antoine Pitrou pit...@free.fr added the comment: Well I was sure I had added this code for a reason, but the tests seem to run without... Just a comment: the test isn't ProcessPoolExecutor-specific, so it should really be in the generic tests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12364 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13697] python RLock implementation unsafe with signals
Antoine Pitrou pit...@free.fr added the comment: Yes, using synchronization primitives or doing I/O in Python signal handlers isn't a good idea. Perhaps the signal docs should be clearer about that. Of course, this wasn't ever safe code, and we're changing it (to have the signal handler merely set a integer flag that the logging handler can consult without locking) Indeed, setting a variable (or using set_wakeup_fd()) is the right approach. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism
Erno Tukia erno.tu...@iki.fi added the comment: In Python 2.6 PLAIN authentication works, in Python 3.1 not. Lib/test/test_imaplib.py does not test IMAP4.authenticate() or IMAP4.login_cram_md5() functions, only IMAP4.login(). I would still like to go back to imaplib._Authenticator.encode() function. The function is below. # inp = authobject(response) def encode(self, inp): oup = '' while inp: if len(inp) 48: t = inp[:48] inp = inp[48:] else: t = inp inp = '' e = binascii.b2a_base64(t) if e: oup = oup + e[:-1] return oup binascii.b2a_base64() takes bytes, so inp must therefore be bytes, and returns bytes (Python 3). Then str + bytes (out + e[:-1]) fails. The fix would then be changing oup = oup + e[:-1] to oup = oup + e[:-1].decode() -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13700 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1079] decode_header does not follow RFC 2047
Ralf Schlatterbeck r...@runtux.com added the comment:
Fine, I see what you mean, this involves very careful reading of the RFC
and could have been a little more verbose ...
Right. Should have been a ')'
Adding the RFC tests would be great (patches gladly accepted). Fixes
for ones we fail would be great, too, but at the very least we can
mark them as expected failures. I don't usually like adding tests
that we expect to fail, but in the case of externally defined tests
such as the RFC examples I think it is worthwhile, so that we can
check in a complete test set.
Patch attached (against current tip, 74241:120a79b8bb11). We currently
fail *all* of the tests in the RFC due to the same problem, the closing
')', I've marked them accordingly.
I've made the 5th test (with newline in the string) two cases, one with
\r\n for the newline, one with only \n. They fail differently.
I plan to look into this a little more, my current plan is to make the
outer regex non-greedy (if possible) and remove the trailing whitespace.
That would involve parsing (and ignoring) additional whitespace
*between* encoded words but not at the boundary to a non-encoded word.
Any objections/further infos?
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: http://www.runtux.com
Reichergasse 131, A-3411 Weidling email: off...@runtux.com
osAlliance member email: r...@osalliance.com
--
Added file: http://bugs.python.org/file24130/python.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1079
___diff -r 120a79b8bb11 Lib/test/test_email/test_email.py
--- a/Lib/test/test_email/test_email.py Tue Jan 03 06:26:13 2012 +0200
+++ b/Lib/test/test_email/test_email.py Tue Jan 03 16:16:09 2012 +0100
@@ -2056,6 +2056,67 @@
self.assertEqual(decode_header(s),
[(b'andr\xe9=zz', 'iso-8659-1')])
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_1(self):
+# 1st testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a', 'iso-8859-1'), (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_2(self):
+# 2nd testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a?= b)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a', 'iso-8859-1'), (b' b)', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_3(self):
+# 3rd testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a', 'iso-8859-1'), (b'b', 'iso-8859-1'),
+ (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_4(self):
+# 4th testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a', 'iso-8859-1'), (b'b', 'iso-8859-1'),
+ (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_5a(self):
+# 5th testcase at end of rfc2047 newline is \r\n
+s = '(=?ISO-8859-1?Q?a?=\r\n=?ISO-8859-1?Q?b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a', 'iso-8859-1'), (b'b', 'iso-8859-1'),
+ (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_5b(self):
+# 5th testcase at end of rfc2047 newline is \n
+s = '(=?ISO-8859-1?Q?a?=\n=?ISO-8859-1?Q?b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a', 'iso-8859-1'), (b'b', 'iso-8859-1'),
+ (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_6(self):
+# 6th testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a_b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a b', 'iso-8859-1'), (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_7(self):
+# 7th testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a', 'iso-8859-1'), (b' b', 'iso-8859-2'),
+ (b')', None)])
+
# Test the MIMEMessage class
class TestMIMEMessage(TestEmailBase):
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: @Éric: you may also be interested in a standalone launcher which I wrote for the pythonv branch: https://bitbucket.org/vinay.sajip/simple_launcher/ This is built using Visual Studio and is not based on setuptools code, but uses the same Windows API for child process creation and synchronisation as the PEP 397 launcher (rather than execv/spawnv as the setuptools launcher does). It also links with the runtime statically rather than linking with msvcrt.dll. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13701] Remove Decimal Python 2.3 Compatibility
Mark Dickinson dicki...@gmail.com added the comment: Did you have specific changes in mind? While we're still maintaining 2.x and 3.x code in parallel, there's a benefit to not having the versions of decimal.py diverge too much. Given that the 2.3-compatible code isn't actually broken, I'm not sure that there's really that much to be gained by changing it. The ugliest part of the current code is probably the post-application of classmethod instead of using a decorator; I wouldn't object to fixing that. I do agree with the general principle that the 3.x version of decimal.py doesn't need to stay backwards compatible with Python 2.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13701 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13696] [urllib.request.HTTPRedirectHandler.http_error_302] Relative Redirect issue
Antoine Pitrou pit...@free.fr added the comment: CRicky's proposed changed looks reasonable to me - although it would be better with a unit test too :) -- nosy: +gvanrossum, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism
Erno Tukia erno.tu...@iki.fi added the comment: I tried to fix the problem and the correct fix is to change oup = '' to oup = b'' in imaplib._Authenticator.encode() function, and not what I suggested in my previous post. After changing that PLAIN authentication works. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13700 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1079] decode_header does not follow RFC 2047
Ralf Schlatterbeck r...@runtux.com added the comment:
enclosed please find a fixed patch -- decode_header consolidates
multiple encoded strings with the same encoding into a single entry in
the returned parts.
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: http://www.runtux.com
Reichergasse 131, A-3411 Weidling email: off...@runtux.com
osAlliance member email: r...@osalliance.com
--
Added file: http://bugs.python.org/file24131/python.patch.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1079
___diff -r 120a79b8bb11 Lib/test/test_email/test_email.py
--- a/Lib/test/test_email/test_email.py Tue Jan 03 06:26:13 2012 +0200
+++ b/Lib/test/test_email/test_email.py Tue Jan 03 17:09:34 2012 +0100
@@ -2056,6 +2056,63 @@
self.assertEqual(decode_header(s),
[(b'andr\xe9=zz', 'iso-8659-1')])
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_1(self):
+# 1st testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a', 'iso-8859-1'), (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_2(self):
+# 2nd testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a?= b)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a', 'iso-8859-1'), (b' b)', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_3(self):
+# 3rd testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'ab', 'iso-8859-1'), (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_4(self):
+# 4th testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'ab', 'iso-8859-1'), (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_5a(self):
+# 5th testcase at end of rfc2047 newline is \r\n
+s = '(=?ISO-8859-1?Q?a?=\r\n=?ISO-8859-1?Q?b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'ab', 'iso-8859-1'), (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_5b(self):
+# 5th testcase at end of rfc2047 newline is \n
+s = '(=?ISO-8859-1?Q?a?=\n=?ISO-8859-1?Q?b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'ab', 'iso-8859-1'), (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_6(self):
+# 6th testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a_b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a b', 'iso-8859-1'), (b')', None)])
+
+@unittest.expectedFailure
+def test_rfc2047_rfc2047_7(self):
+# 7th testcase at end of rfc2047
+s = '(=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=)'
+self.assertEqual(decode_header(s),
+[(b'(', None), (b'a', 'iso-8859-1'), (b' b', 'iso-8859-2'),
+ (b')', None)])
+
# Test the MIMEMessage class
class TestMIMEMessage(TestEmailBase):
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13598] string.Formatter doesn't support empty curly braces {}
Éric Araujo mer...@netwok.org added the comment: test_string.diff looks good, except that it should probably only test the exception type, not the message (they are not a guaranteed part of the Python language and may change arbitrarily between versions or implementations (e.g. PyPy), so better not to add tests that depend on exact words). I don’t have anything specific to say about issue13598.diff; if it makes the test pass, then it’s good. “if manual == True” should just be replaced by “if manual”. If you’d like to, you can make one patch with fix + tests that addresses my comments and remove the older diffs. -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13598 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1079] decode_header does not follow RFC 2047
R. David Murray rdmur...@bitdance.com added the comment: Well, a caution that tweaking the regex can have unexpected consequences as past issues have proven (but by all means go for it), and a note that the parsing strategy is going to change completely in email6 (see http://pypi.python.org/email and http://hg.python.org/features/email6). I think your tests should pass on that branch; I'll be interested to try it when I get some time. (Note: I'm removing 3.1 from versions since it doesn't get bug fixes any more.) Also, I'm not sure the (non-essential) change to consolidate like-charset encoded words is appropriate for a bug fix. It's hard to see how it would break anything, but why take the risk if it isn't needed to fix the bug. -- versions: -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4755] Add function to get common path prefix
Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo title: Common path prefix - Add function to get common path prefix type: behavior - enhancement versions: +Python 3.3 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4755 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1079] decode_header does not follow RFC 2047
R. David Murray rdmur...@bitdance.com added the comment: Gah, that's what I get for not reading carefully (or looking at the patch first). Your test change is fine, of course. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism
R. David Murray rdmur...@bitdance.com added the comment: Would you be interested in providing a patch that includes tests? I think Antoine set up a test framework for testing the login as part of issue 4471. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13700 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8184] multiprocessing.managers will not fail if listening ocket already in use
Charles-François Natali neolo...@free.fr added the comment: That's because SocketListener uses SO_REUSEADDR. It seems that, with SO_REUSEADDR, Windows allows binding to a port even though there's a socket already bound to the same port in the LISTEN state: this is wrong, the semantics of SO_REUSEADDR was intended for sockets in TIME-WAIT state, and Linux and BSD systems implement this properly (i.e. fail with EADDRINUSE when there's a socket in LISTEN state). The problem, if we remove this flag, is that managers binding to a specific port will get EADDRINUSE in case of rapid restart. Since I'm not convinced that this is really an issue, I'd suggest to close this as won't fix. Another option would be to complain to Microsoft :-) @Phill: I'm not sure I understand your problem: could you be more specific (or open a new issue)? -- nosy: +neologix, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13702] relative symlinks in tarfile.extract broken
New submission from Patrick von Reth patrick.vonr...@gmail.com: when extracting http://www.openssl.org/source/openssl-1.0.0d.tar.gz with python3.2 on windows 7 extraction fails with File C:\python32\lib\tarfile.py, line 2175, in extract set_attrs=set_attrs) File C:\python32\lib\tarfile.py, line 2259, in _extract_member self.makelink(tarinfo, targetpath) File C:\python32\lib\tarfile.py, line 2359, in makelink targetpath) File C:\python32\lib\tarfile.py, line 2251, in _extract_member self.makefile(tarinfo, targetpath) File C:\python32\lib\tarfile.py, line 2292, in makefile target = bltn_open(targetpath, wb) IOError: [Errno 22] Invalid argument: 'R:\\tmp\\os\\openssl-1.0.0d\\apps\\md4.c' the reason is that the symlink is broken R:\dir R:\tmp\os\openssl-1.0.0d\apps\md4.c Volume in drive R has no label. Volume Serial Number is E8F0-7223 Directory of R:\tmp\os\openssl-1.0.0d\apps 02.01.2012 20:13SYMLINK md4.c [../crypto/md4/md4.c] it must be backslashes instead of front slashes and that's why python cant access the file the symlink is pointing to. -- components: Windows messages: 150512 nosy: Patrick.von.Reth priority: normal severity: normal status: open title: relative symlinks in tarfile.extract broken type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13702] relative symlinks in tarfile.extract broken (windows)
Changes by Patrick von Reth patrick.vonr...@gmail.com: -- title: relative symlinks in tarfile.extract broken - relative symlinks in tarfile.extract broken (windows) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13685] argparse does not sanitize help strings for % signs
Jeff Yurkiw j...@cyan.com added the comment: That would probably work too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue818201] distutils: clean does not use build_base option from build
Éric Araujo mer...@netwok.org added the comment: Where was this fixed? It is still a problem in Python 2.6.6. I assumed it was fixed after looking at the code: clean does take build-* options from the build command. For example, if I do: python setup.py build_ext --compiler=mingw32 build --build-platlib=build\win64 Then follow it up with: python setup.py clean --build-base=build\win64 -a This is what it does: running clean 'build\lib.win-amd64-2.6' does not exist -- can't clean it removing 'build\bdist.win-amd64' (and everything under it) 'build\scripts-2.6' does not exist -- can't clean it As you can see, the base directory argument is ignored. I’m not sure if this is a distutils bug or if you have to use the same options (i.e. build-lib both times, not build-platlib then build-base). The original report used -b (build-base) for both commands, so I’ll turn that into a test (unless you’d like to do it?) to see if it works as intended or not. -- resolution: fixed - stage: committed/rejected - test needed status: closed - open versions: -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue818201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9975] Incorrect use of flowinfo and scope_id in IPv6 sockaddr tuple
Charles-François Natali neolo...@free.fr added the comment: Should be fixed now. Vilmos, thanks for the patch! -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9975 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8184] multiprocessing.managers will not fail if listening ocket already in use
Antoine Pitrou pit...@free.fr added the comment: There's a length MSDN article about this: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621%28v=vs.85%29.aspx Executive summary: it's a can of worms. However, let me point out the following sentence: “Ports without SO_EXCLUSIVEADDRUSE set may be reused as soon as the socket on which bind was previously called is closed.” ...which seems to suggest we shouldn't use SO_REUSEADDR under Windows, since Windows sockets appear to have the Unix SO_REUSEADDR semantics by default. -- resolution: fixed - versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13697] python RLock implementation unsafe with signals
Charles-François Natali neolo...@free.fr added the comment: The core of the problem is that we don't just want those methods to be atomic or thread-safe, but reentrant (or rather async-safe). As such, protecting by a lock isn't enough (and it's not really feasible in Python). Note that the RLock implementation already checks whether the lock is already acquire by the current thread, but there's a race: if self._owner == me: [...] self._count = self._count + 1 return 1 rc = self._block.acquire(blocking, timeout) if rc: self._owner = me If the signal handler is called after _block has been acquired, but before self._owner is set, the next call to acquire from the signal handler won't realize that the block has already been acquired by the current thread, and will deadlock. Now, the fun part: this affects not only RLock, but every Python code performing atomic actions: condition variables, barriers, etc. There are some constraints on what can be done from a signal handler, and it should probably be documented. Note that another solution would be to use a dedicated thread for signal management (like Java does), but that's another story. Also, this shouldn't be a problem for the buffered I/O code, since the code already accounts for this possibility (if the lock is already acquired by the current thread, an exception is raised). Now, there's something I don't understand: I've just had a quick look, but AFAICT, there's no reason why the C version of RLock could not be available: am I missing something? Why do we even have a Python implementation? -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13697] python RLock implementation unsafe with signals
Antoine Pitrou pit...@free.fr added the comment: Note that another solution would be to use a dedicated thread for signal management (like Java does), but that's another story. That sounds like a good solution in the middle-term. Are there any drawbacks? (apart from launching a thread) Also, this shouldn't be a problem for the buffered I/O code, since the code already accounts for this possibility (if the lock is already acquired by the current thread, an exception is raised). Yes, but raising an exception is less helpful than doing what the user asked for :) Now, there's something I don't understand: I've just had a quick look, but AFAICT, there's no reason why the C version of RLock could not be available: am I missing something? Why do we even have a Python implementation? The C version is quite recent, and there's a school of thought that we should always provide fallback Python implementations. (also, arguably a Python implementation makes things easier to prototype, although I don't think it's the case for an RLock) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8184] multiprocessing.managers will not fail if listening ocket already in use
Charles-François Natali neolo...@free.fr added the comment: OK, so just removing SO_REUSEADDR on Windows should do the trick... Seriously, why can't they simply conform to existing standards :-( If someone wants to provide a patch + test, go ahead! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9349] document argparse's help=SUPPRESS
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 572ddf2770bc by Sandro Tosi in branch '3.2': Issue #9349: add argparse.SUPPRESS to help doc http://hg.python.org/cpython/rev/572ddf2770bc New changeset 17b7b856cbe8 by Sandro Tosi in branch '2.7': Issue #9349: add argparse.SUPPRESS to help doc http://hg.python.org/cpython/rev/17b7b856cbe8 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9349 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9349] document argparse's help=SUPPRESS
Changes by Sandro Tosi sandro.t...@gmail.com: -- nosy: +sandro.tosi resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9349 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13696] [urllib.request.HTTPRedirectHandler.http_error_302] Relative Redirect issue
Guido van Rossum gu...@python.org added the comment: (This is in reference to issue 11662.) I can't think of a way that this proposed change would bring back the original vulnerability, so go ahead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13701] Remove Decimal Python 2.3 Compatibility
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13701 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
New submission from Barry A. Warsaw ba...@python.org: This is already publicly known and in deep discussion on python-dev. The proper fix is still TBD. Essentially, hash collisions can be exploited to DoS a web framework that automatically parses input forms into dictionaries. Start here: http://mail.python.org/pipermail/python-dev/2011-December/115116.html -- components: Interpreter Core messages: 150522 nosy: barry, benjamin.peterson, georg.brandl priority: release blocker severity: normal status: open title: Hash collision security issue type: security versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by Guido van Rossum gu...@python.org: -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +christian.heimes, pitrou stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13114] check -r fails with non-ASCII unicode long_description
Jason R. Coombs jar...@jaraco.com added the comment: I recently encountered this error, and in the process of troubleshooting, developed this one-line to reproduce the problem. I'm including it here for posterity (and in case anybody wants to test a given version of Python for the error): python -c from distutils.core import setup; setup(name='foo.project', version='1.0', url='http://www.example.com', author='Foo', author_email='f...@example.com', long_description = u'\xc0',) check -r -- nosy: +jason.coombs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13114 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8184] multiprocessing.managers will not fail if listening ocket already in use
Phill beer...@gmail.com added the comment: @neologix: nah its fine, if you guys are gonna re open this one I wont worry about opening a new bug. If the above gets solved on windows my problem will just go away, thanks -- versions: +Python 2.6 -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Christian Heimes li...@cheimes.de added the comment: I had a short chat with Guido yesterday. I'll try to sum up the conversation. Guido, please correct me if I got something wrong or missed a point. Guido wants the fix as simple and less intrusive as possible as he wants to provide/apply a patch for Python 2.4 to 3.3. This means any new stuff is off the table unless it's really, really necessary. Say goodbye to my experimental MurmurHash3 patch. We haven't agreed whether the randomization should be enabled by default or disabled by default. IMHO it should be disabled for all releases except for the upcoming 3.3 release. The env var PYTHONRANDOMHASH=1 would enable the randomization. It's simple to set the env var in e.g. Apache for mod_python and mod_wsgi. -- stage: needs patch - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Antoine Pitrou pit...@free.fr added the comment: We haven't agreed whether the randomization should be enabled by default or disabled by default. IMHO it should be disabled for all releases except for the upcoming 3.3 release. I think on the contrary it must be enabled by default. Leaving security holes open is wrong. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13704] Random number generator in Python core
New submission from Christian Heimes li...@cheimes.de: All proposed fixes for a randomized hashing function raise and fall with a good random number generator to feed the random seed. The seed must be created very early in the startup phase of the interpreter, preferable before the basic types are initialized. CPython already have multiple sources for random data (win32_urandom in Modules/posixmodule.c, urandom in Lib/os.py, Mersenne twister in Modules/_randommodule.c). However we can't use them because they are wrapped inside Python modules which require infrastructure like initialized base types. Discussion at http://mail.python.org/pipermail/python-dev/2012-January/115263.html My proposed changes are implemented in my feature fork but not yet well tested. Windows build files needs modification, too. -- assignee: christian.heimes hgrepos: 98 messages: 150527 nosy: barry, benjamin.peterson, christian.heimes, georg.brandl, gvanrossum, pitrou priority: release blocker severity: normal stage: patch review status: open title: Random number generator in Python core type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13704] Random number generator in Python core
Antoine Pitrou pit...@free.fr added the comment: (for the record, you can use the create patch button which creates a reviewable diff) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Christian Heimes li...@cheimes.de added the comment: I think on the contrary it must be enabled by default. Leaving security holes open is wrong. We can't foresee the implications of the randomization and only a small number of deployments is affected by the problem. But I won't start a fight on the matter. ;) -- dependencies: +Random number generator in Python core stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism
Erno Tukia erno.tu...@iki.fi added the comment: Here's a patch with test. I am not an IMAP guru, so please verify my patch. -- keywords: +patch Added file: http://bugs.python.org/file24132/issue13700.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13700 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Guido van Rossum gu...@python.org added the comment: I'm with Antoine -- turn it on by default. Maybe there should be a release candidate to test the waters. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Barry A. Warsaw ba...@python.org added the comment: On Jan 03, 2012, at 08:24 PM, Antoine Pitrou wrote: I think on the contrary it must be enabled by default. Leaving security holes open is wrong. Unless there's evidence of performance regressions or backward incompatibilities, I agree. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
STINNER Victor victor.stin...@haypocalc.com added the comment: Unless there's evidence of performance regressions or backward incompatibilities, I agree. If hash() is modified, str(dict) and str(set) will change for example. It may break doctests. Can we consider that the application should not rely (indirectly) on hash and so fix (for example) their doctests? Or is it a backward incompatibility? hash() was already modified in major Python versions. For this specific issue, I consider that security is more important than str(dict). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Benjamin Peterson benja...@python.org added the comment: Barry, when this gets fixed, shall we coordinate release times? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1079] decode_header does not follow RFC 2047
Ralf Schlatterbeck r...@runtux.com added the comment:
Attached please find a patch that
- keeps all spaces between non-encoded and encoded parts
- doesn't create spaces between non-encoded and encoded parts in case
these are already there or not needed (because they are non-ctext
characters of RFC822 like ')') in the methods encode and __str__
of class Header.
in all other cases spaces are still inserted, this keeps many tests
happy and probably won't break too much existing code.
I've re-read RFC2047 (and parts of 822) and now share your opinion that
it requires that encoded parts *must* be followed by a
'linear-white-space' if the following (or preceding) token is text or ctext.
(p.7 5. Use of encoded-words in message headers)
With the special-casing of ctext characters mentioned above,
roundtripping is now possible, so if you parse a normalized string
consisting of encoded and non-encoded parts, (even multiple) whitespace
is preserved.
I still think we should do it like everyone else and *not* automatically
insert whitespace at boundaries between encoded and non-encoded words,
even if the RFC requires it. Someone wanting to create headers
consisting of mixed encoded/non-encoded parts without whitespace must
know what to do anyway -- the previous implementation also didn't check
for all border cases.
I've *not yet* tested this against the email6 branch you mentioned.
Note that I didn't have to make the regex non-greedy, it already
was. I've just removed the whitespace at the end of the regex.
I've changed all the tests that test for removal of whitespace between
non-encoded and encoded parts. Obviously I've also changed a test that
relied on failing to parse adjacent encoded strings. But please look at
my changes of the tests.
The rfc2047 tests now all pass.
The patch also fixes issue1467619 Header.decode_header eats up spaces
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: http://www.runtux.com
Reichergasse 131, A-3411 Weidling email: off...@runtux.com
osAlliance member email: r...@osalliance.com
--
Added file: http://bugs.python.org/file24133/python.patch3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1079
___diff -r 3609d32cec46 Lib/email/header.py
--- a/Lib/email/header.py Tue Jan 03 17:48:19 2012 +0100
+++ b/Lib/email/header.py Tue Jan 03 22:19:30 2012 +0100
@@ -40,7 +40,6 @@
\?# literal ?
(?Pencoded.*?) # non-greedy up to the next ?= is the encoded string
\?= # literal ?=
- (?=[ \t]|$) # whitespace or the end of the string
''', re.VERBOSE | re.IGNORECASE | re.MULTILINE)
# Field name regexp, including trailing colon, but not separating whitespace,
@@ -86,8 +85,12 @@
words = []
for line in header.splitlines():
parts = ecre.split(line)
+first = True
while parts:
-unencoded = parts.pop(0).strip()
+unencoded = parts.pop(0)
+if first:
+unencoded = unencoded.lstrip()
+first = False
if unencoded:
words.append((unencoded, None, None))
if parts:
@@ -95,6 +98,16 @@
encoding = parts.pop(0).lower()
encoded = parts.pop(0)
words.append((encoded, encoding, charset))
+# Now loop over words and remove words that consist of whitespace
+# between two encoded strings.
+import sys
+droplist = []
+for n, w in enumerate(words):
+if n1 and w[1] and words[n-2][1] and words[n-1][0].isspace():
+droplist.append(n-1)
+for d in reversed(droplist):
+del words[d]
+
# The next step is to decode each encoded word by applying the reverse
# base64 or quopri transformation. decoded_words is now a list of the
# form (decoded_word, charset).
@@ -217,22 +230,27 @@
self._normalize()
uchunks = []
lastcs = None
+lastspace = None
for string, charset in self._chunks:
# We must preserve spaces between encoded and non-encoded word
# boundaries, which means for us we need to add a space when we go
# from a charset to None/us-ascii, or from None/us-ascii to a
# charset. Only do this for the second and subsequent chunks.
+# Don't add a space if the None/us-ascii string already has
+# a space (trailing or leading depending on transition)
nextcs = charset
if nextcs == _charset.UNKNOWN8BIT:
original_bytes = string.encode('ascii', 'surrogateescape')
string = original_bytes.decode('ascii', 'replace')
if uchunks:
+hasspace = string and self._nonctext(string[0])
if lastcs
[issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism
Erno Tukia erno.tu...@iki.fi added the comment: Here's another patch that should fix the CRAM-MD5 authentication. My previous patch is required with this one. The patch includes a test. -- Added file: http://bugs.python.org/file24134/cram_md5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13700 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by Dave Malcolm dmalc...@redhat.com: -- nosy: +dmalcolm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6031] BaseServer.shutdown documentation is incomplete
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 4fad6b811c8b by Sandro Tosi in branch '2.7': Issue #6031: improve serve_forever() description http://hg.python.org/cpython/rev/4fad6b811c8b New changeset 4a30d36a9c69 by Sandro Tosi in branch '3.2': Issue #6031: improve serve_forever() description http://hg.python.org/cpython/rev/4a30d36a9c69 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6031] BaseServer.shutdown documentation is incomplete
Sandro Tosi sandro.t...@gmail.com added the comment: yep indeed, I've removed the deadlock part and committed. -- resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 3.3 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 25c2d24e1b11 by Antoine Pitrou in branch '3.2': Issue #13636: Weak ciphers are now disabled by default in the ssl module http://hg.python.org/cpython/rev/25c2d24e1b11 New changeset ace54f5e75d7 by Antoine Pitrou in branch 'default': Issue #13636: Weak ciphers are now disabled by default in the ssl module http://hg.python.org/cpython/rev/ace54f5e75d7 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset f9122975fd80 by Antoine Pitrou in branch '2.7': Issue #13636: Weak ciphers are now disabled by default in the ssl module http://hg.python.org/cpython/rev/f9122975fd80 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Barry A. Warsaw ba...@python.org added the comment: On Jan 03, 2012, at 09:43 PM, Benjamin Peterson wrote: Barry, when this gets fixed, shall we coordinate release times? Yes! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8416] python 2.6.5 documentation can't search
Sandro Tosi sandro.t...@gmail.com added the comment: Hi Georg, I've verified doc search works with 2.6.[467], so if the fix is so easy to just add that js, could you please give it a look? TIA -- nosy: +sandro.tosi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Christian Heimes li...@cheimes.de added the comment: Randomized hashing destabilizes the unit tests of Python, too. Here are the outputs of four test runs: 11 tests failed: test_collections test_dbm test_dis test_gdb test_inspect test_packaging test_set test_symtable test_ttk_textonly test_urllib test_urlparse 9 tests failed: test_dbm test_dis test_gdb test_json test_packaging test_set test_symtable test_urllib test_urlparse 10 tests failed: test_dbm test_dis test_gdb test_inspect test_packaging test_set test_symtable test_ttk_textonly test_urllib test_urlparse 9 tests failed: test_collections test_dbm test_dict test_dis test_gdb test_packaging test_symtable test_urllib test_urlparse -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13705] Raising exceptions from finally works better than advertised in the documentation
New submission from Sinisa Segvic sinisa.seg...@fer.hr: Hi, The documentation says: If the finally clause raises another exception (...) the saved exception is lost. This does not appear to be true. In the example below the backtrace shows both exceptions. import math try: ... 1/0 ... finally: ... math.sqrt(-1) ... Traceback (most recent call last): File stdin, line 2, in module ZeroDivisionError: division by zero During handling of the above exception, another exception occurred: Traceback (most recent call last): File stdin, line 4, in module ValueError: math domain error Cheers, Siniša -- assignee: docs@python components: Documentation messages: 150544 nosy: docs@python, ssegvic priority: normal severity: normal status: open title: Raising exceptions from finally works better than advertised in the documentation type: enhancement versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13704] Random number generator in Python core
Changes by STINNER Victor victor.stin...@haypocalc.com: -- keywords: +patch Added file: http://bugs.python.org/file24135/3106cc0a2024.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13704] Random number generator in Python core
Martin v. Löwis mar...@v.loewis.de added the comment: I disagree with that approach, basically because I disagree that we need a C implementation of MT. Platforms that don't provide /dev/urandom will just have to be less secure. Using the current time (in milliseconds if available) plus the current pid ought to be good enough as a random seed. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13704] Random number generator in Python core
Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13705] Raising exceptions from finally works better than advertised in the documentation
Sinisa Segvic sinisa.seg...@fer.hr added the comment: Link to the documentation: http://docs.python.org/py3k/reference/compound_stmts.html#id2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13705] Raising exceptions from finally works better than advertised in the documentation
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset c39fbb24b3f4 by Benjamin Peterson in branch '3.2': exception support is correct now (closes #13705) http://hg.python.org/cpython/rev/c39fbb24b3f4 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13706] Unicode fill characters no longer work in numeric formatting
New submission from Stefan Krah stefan-use...@bytereef.org: It used to be possible to specify Unicode fill characters in numeric formatting: Python 3.3.0a0 (default:1dd6908df8f5, Jul 16 2011, 11:16:00) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. format(1234, \u20077) '1234\u2007\u2007\u2007' [64682 refs] Now it doesn't work: Python 3.3.0a0 (default:65ac469d30e6, Jan 3 2012, 23:23:07) [GCC 4.4.3] on linux Type help, copyright, credits or license for more information. format(1234, \u20077) Traceback (most recent call last): File stdin, line 1, in module ValueError: fill character too large -- components: Interpreter Core messages: 150548 nosy: eric.smith, haypo, loewis, mark.dickinson, skrah priority: normal severity: normal status: open title: Unicode fill characters no longer work in numeric formatting type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13704] Random number generator in Python core
Christian Heimes li...@cheimes.de added the comment: We already have a C implementation of MT in Modules/_randommodule.c. I just suggest that we move the implementation to a place, where we can use it as seed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13706] Unicode fill characters no longer work in numeric formatting
Benjamin Peterson benja...@python.org added the comment: It's still possible; it's just apparently limited to ASCII characters. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13706] Unicode fill characters no longer work in numeric formatting
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13706] Unicode fill characters no longer work in numeric formatting
Stefan Krah stefan-use...@bytereef.org added the comment: Hum, somehow I always refuse to acknowledge that ASCII is a subset of Unicode. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13706] non-ascii fill characters no longer work in numeric formatting
Changes by Stefan Krah stefan-use...@bytereef.org: -- title: Unicode fill characters no longer work in numeric formatting - non-ascii fill characters no longer work in numeric formatting ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13706] non-ascii fill characters no longer work in numeric formatting
Eric V. Smith e...@trueblade.com added the comment:
I assume this is left over from the PEP 393 changes. I think the right thing to
do is delete this code from line 277 of formatter_unicode.c:
if (format-fill_char 127 || format-align 127 ||
format-sign 127) {
PyErr_SetString(PyExc_ValueError, fill character too large);
return 0;
}
I'm not sure such a restriction needs to exist any more. But I'll admit to not
having thought it through.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13706
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13706] non-ascii fill characters no longer work in numeric formatting
STINNER Victor victor.stin...@haypocalc.com added the comment: I assume this is left over from the PEP 393 changes. Correct. I'm not sure such a restriction needs to exist any more. The restriction was introduced to simplify the implementation. maxchar has to be computed exactly in format_string_internal(), format_int_or_long_internal(), format_float_internal() and format_complex_internal(). For format_string_internal(), the following change is enough (untested): if (lpad != 0 || rpad != 0) maxchar = Py_MAX(maxchar, format-fill_char); For number formatting functions, spec-n_lpadding, spec-n_spadding and spec-n_rpadding have to be checked. Something like: if (spec-n_lpadding || spec-n_spadding || spec-n_rpadding) maxchar = Py_MAX(maxchar, format-fill_char); -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13706] non-ascii fill characters no longer work in numeric formatting
Martin v. Löwis mar...@v.loewis.de added the comment: Removing the if condition would be incorrect. The maximum char is computed at the beginning of the formatting. If, during formatting, need for a padding character is determined, the padding character must not be larger than the maximum char of the target string - which is 127 unless 'c' formatting is used. One solution would be to determine whether the padding character is used in advance. Another solution would be to widen the string when the need for non-ASCII padding is detected. I have no intention of fixing this issue myself; I don't mind if non-ASCII padding characters are not supported in 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8416] python 2.6.5 documentation can't search
Terry J. Reedy tjre...@udel.edu added the comment: Santiago, if you are still running 2.6.5 code, use the most recent 2.6 docs at http://docs.python.org/release/2.6.6/ This will have all the corrections made after the 2.6.5 release. Contrary to what you might think the header line says, there is no particular connection between the 2.6.5 code release and the obsolete 2.6.5 doc release. George, since the continuously updated x.y docs released with x.y.z really document x.y and not each x.y.z bugfix release, I am a bit surprised that they are labelled x.y.z docs with the claim This is the documentation for Python x.y.z, especially since they are updated after the x.y.z code release. The current '2.7.2' docs, last updated today, would more truthfully be called either '2.7' docs or '2.7.3a0' docs, as they are are a preview of what will be released with 2.7.3 and are not what was released with 2.7.2. If there *were* (unusally) any new features in 2.7.3a0, they would already be listed in the so-called '2.7.2' docs. (There *was* such a bugfix addition for difflib.SequenceMatcher in 2.7.1, and I presume it did appear in the updated '2.7.0' online docs.) I am not sure we should have obsolete snapshot versions online. They only serve to be an attractive nuisance as illustrated by this issue. With the initial 3.3 release being called 3.3.0, there would be no ambiguity in calling the 3.3 docs just that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8416] python 2.6.5 documentation can't search
Terry J. Reedy tjre...@udel.edu added the comment: Sorry, /George/Georg/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13706] non-ascii fill characters no longer work in formatting
Stefan Krah stefan-use...@bytereef.org added the comment: Actually the issue is not restricted to numeric formatting. It's not possible to pad a Unicode string with a non-ascii whitespace: format(abcd, \u20077) Traceback (most recent call last): File stdin, line 1, in module ValueError: fill character too large I'd be more than happy to restrict all numerical I/O operations to ASCII. This includes input strings for int(), float(), Decimal(). It does break backwards compatibility though and the situation for string formatting above seems odd to me. It is worse when the rejected fill character is already present in the string: format(\u2007abcd, \u20077) Traceback (most recent call last): File stdin, line 1, in module ValueError: fill character too large -- title: non-ascii fill characters no longer work in numeric formatting - non-ascii fill characters no longer work in formatting ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Paul McMillan p...@mcmillan.ws added the comment: I agree that we should enable randomness by default, and provide an easy way for users to disable it if necessary (unit test suites that explicitly depend on order being an obvious candidate). I'll link my proposed algorithm change here, for the record: https://gist.github.com/0a91e52efa74f61858b5 I've gotten confirmation from several other sources that the fix recommended by the presenters (just a random initialization seed) only prevents the most basic form of the attack. -- nosy: +PaulMcMillan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8416] python 2.6.5 documentation can't search
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
STINNER Victor victor.stin...@haypocalc.com added the comment: Christian Heimes proposes the following change in its randomhash branch (see issue #13704): -x = (Py_uhash_t) *p 7; +x = Py_RndHashSeed + ((Py_uhash_t) *p 7); for (i = 0; i len; i++) x = (103U * x) ^ (Py_uhash_t) *p++; x ^= (Py_uhash_t) len; This change doesn't add any security if the attacker can inject any string and retreive the hash value. You can retreive directly Py_RndHashSeed using: Py_RndHashSeed = intmask((hash(a) ^ len(a) ^ ord(a)) * DIVIDE) - (ord(a) 7) where intmask() truncates to a long (x mod 2^(long bits)) and DIVIDE = 1/103 mod 2^(long bits). For example, DIVIDE=2021759595 for 32 bits long. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13704] Random number generator in Python core
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever, ezio.melotti, michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Christian Heimes li...@cheimes.de added the comment: Victor, please ignore my code related to hash randomization for now. I've deliberately not linked my branch to this bug report. I'm well aware that it's not secure and that it's pretty easy to reverse engineer the seed from a hash of a short string. The code is a proof of concept to detect failing tests and other issues. I'm in private contact with Paul and we are working together. He has done extended research and I'll gladly follow his expertise. I've already discussed the issue with small strings, but I can't recall if it was a private mail to Paul or a public one to the dev list. Paul: I still think that you should special case short strings (five or few chars sound good). An attacker can't do much harm with one to five char strings but such short strings may make it too easy to calculate the seed. 16kb of seed is still a lot. Most CPUs have about 16 to 32, maybe 64kb L1 cache for data. 1024 to 4096 bytes should increase cache locality and reduce speed impacts. PS: I'm going to reply to your last mail tomorrow. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13707] Clarify hash() lifetime
New submission from Terry J. Reedy tjre...@udel.edu: Current 3.2.2 docs: id(object) Return the “identity” of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. [model] hash(object) Return the hash value of the object (if it has one). Hash values are integers. They are used to quickly compare dictionary keys Suggestion: change Hash values are integers. They ... to This should be an integer which is constant for this object during its lifetime. Hash values ... Rationale: For builtin class instances, hash values are guaranteed to be constant that long, and only that long, as the default hash(ob) for object() instances is currently, for my win7, 64 bit, 3.2.2 CPython, id(ob) // 16 (the minimum object size). User class instance hashes (with custom __hash__) *should* have the same lifetime. But since Python cannot enforce that, I did not say 'guaranteed'. User code should *not* depend on a longer lifetime, just as for id() output. It seems worth implying that, as for id(), because (based on recent pydev discussion) people seems to be prone to over-generalize the current longer-term stability of number and string hashes, which itself may disappear in future releases. (see #13703) -- assignee: docs@python components: Documentation messages: 150561 nosy: docs@python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Clarify hash() lifetime type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13704] Random number generator in Python core
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: -ezio.melotti, michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Terry J. Reedy tjre...@udel.edu added the comment: In #13707 I suggest a change to the current hash() entry which is needed independently of this issue, because the default hash (for object()), being tied to id() is already limited to an object's lifetime. But this change will become more imperative if hash() is made run-dependent for numbers and strings. There does not seems to presently *be* a security hole for 64 bit builds, so if there is any noticeable slowdown on 64 bit builds and it is sensibly easy to tie the default to the bitness, I would think it should be off for such builds. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13707] Clarify hash() lifetime
Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
STINNER Victor victor.stin...@haypocalc.com added the comment: Paul first proposition (on python-dev) was to replace: ... x = (ord(s[0]) 7) while i length: x = intmask((103*x) ^ ord(s[i])) ... by: ... x = (ord(s[0]) 7) while i length: x = intmask((103*x) ^ ord(s[i])) ^ r[x % len_r] ... This change has a vulnerability similar than the one of Christian's suggested changed. The r array can be retreived directly with: r2 = [] for i in xrange(len(r)): s = chr(intmask(i * UNSHIFT7) % len(r)) h = intmask(hash(s) ^ len(s) ^ ord(s) ^ ((ord(s) 7) * MOD)) r2.append(chr(h)) r2 = ''.join(r2) where UNSHIFT7 = 1/2**7 mod 2^(long bits). By the way, this change always use r[0] to hash all string of one ASCII character (U+-U+007F). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13707] Clarify hash() lifetime
Martin v. Löwis mar...@v.loewis.de added the comment: -1. The hash has nothing to do with the lifetime, but with the value of an object. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Antoine Pitrou pit...@free.fr added the comment: I'm in private contact with Paul and we are working together. He has done extended research and I'll gladly follow his expertise. I've already discussed the issue with small strings, but I can't recall if it was a private mail to Paul or a public one to the dev list. Can all this be discussed on this issue now that it's the official point of reference? It will avoid the repetition of arguments we see here and there. (I don't think special-casing small strings makes sense, because then you have two algorithms to audit rather than one) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers
Antoine Pitrou pit...@free.fr added the comment: I've committed a conservative version of the patch, plus a test. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8416] python 2.6.5 documentation can't search
Santiago Gala sg...@apache.org added the comment: Still http://docs.python.org/release/2.6.6/search.html?q=regular+expression works, while http://docs.python.org/release/2.6.5/search.html?q=regular+expression fails, and http://docs.python.org/release/2.6.5/searchindex.js gives a 404, while http://docs.python.org/release/2.6.6/searchindex.js works so the bug report stands as it was reported... Regards Santiago On Wed, Jan 4, 2012 at 12:55 AM, Ezio Melotti rep...@bugs.python.org wrote: Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8416 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
STINNER Victor victor.stin...@haypocalc.com added the comment:
https://gist.github.com/0a91e52efa74f61858b5
Please, attach directly a file to the issue, or copy/paste the code in your
comment. Interesting part the code:
---
#Proposed replacement
#--
import os, array
size_exponent = 14 #adjust as a memory/security tradeoff
r = array.array('l', os.urandom(2**size_exponent))
len_r = len(r)
def _hash_string2(s):
The algorithm behind compute_hash() for a string or a unicode.
length = len(s)
#print s
if length == 0:
return -1
x = (ord(s[0]) 7) ^ r[length % len_r]
i = 0
while i length:
x = intmask((103*x) ^ ord(s[i]))
x ^= r[x % len_r]
i += 1
x ^= length
return intmask(x)
---
r = array.array('l', os.urandom(2**size_exponent))
len_r = len(r)
r size should not depend on the size of a long. You should write something like:
sizeof_long = ctypes.sizeof(ctypes.c_long)
r_bits = 8
r = array.array('l', os.urandom((2**r_bits) * sizeof_long))
r_mask = 2**r_bits-1
and then replace % len_r by r_mask.
What is the minimum value of r_bits? For example, would it be safe to use a
single long integer? (r_bits=1)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13703
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Antoine Pitrou pit...@free.fr added the comment:
r = array.array('l', os.urandom(2**size_exponent))
len_r = len(r)
r size should not depend on the size of a long. You should write something
like:
sizeof_long = ctypes.sizeof(ctypes.c_long)
r_bits = 8
r = array.array('l', os.urandom((2**r_bits) * sizeof_long))
r_mask = 2**r_bits-1
The final code will be in C and will use neither ctypes nor array.array.
Arguing about this looks quite pointless IMO.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13703
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Antoine Pitrou pit...@free.fr added the comment: For the record, here is what man urandom says about random seed size: “[...] no cryptographic primitive available today can hope to promise more than 256 bits of security, so if any program reads more than 256 bits (32 bytes) from the kernel random pool per invocation, or per reasonable reseed interval (not less than one minute), that should be taken as a sign that its cryptography is not skilfully implemented.” In that light, reading a 64 bytes seed from /dev/urandom is already a lot, and 4096 bytes is simply insane. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by Zhiping Deng kofreesty...@gmail.com: -- nosy: +Zhiping.Deng ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13704] Random number generator in Python core
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: christian.heimes - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13708] Document ctypes.wintypes
Changes by Ramchandra Apte maniandra...@gmail.com: -- nosy: ramchandra.apte priority: normal severity: normal status: open title: Document ctypes.wintypes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13708] Document ctypes.wintypes
New submission from Ramchandra Apte maniandra...@gmail.com: Document ctypes.wintypes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13708] Document ctypes.wintypes
Changes by Ramchandra Apte maniandra...@gmail.com: -- assignee: - docs@python components: +Documentation nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13707] Clarify hash() constancy period
Terry J. Reedy tjre...@udel.edu added the comment: Martin, I do not understand. The default hash is based on id (as is default equality comparison), not value. Are you OK with hash values changing if the 'value' changes? My understanding is that changing hash values for objects in sets and dicts is bad, which is why mutable builtins with value-based equality do not have hash values. -- title: Clarify hash() lifetime - Clarify hash() constancy period ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13707] Clarify hash() constancy period
Antoine Pitrou pit...@free.fr added the comment: You can define a __hash__ that changes if the object changes. It is not recommended, but it's possible. So I agree with Martin that your proposed clarification is wrong. (I also think that it wouldn't bring anything, either) Suggest closing as invalid/rajected. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13709] Capitalization mistakes in the documentation for ctypes
New submission from Ramchandra Apte maniandra...@gmail.com: In section 15.17.1.17 in the ctypes documentation, the documentation says It is funny to see that on linux the sort function seems to work much more efficiently, it is doing less comparisons It is quite interesting to see that the Windows qsort() function needs more comparisons than the linux version! linux should be capitalized in both these sentences. -- assignee: docs@python components: Documentation messages: 150574 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: Capitalization mistakes in the documentation for ctypes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
