[issue11777] Executor.map does not submit futures until iter.next() is called
Brian Quinlan br...@sweetapp.com added the comment: I think that it surprising behavior, especially considering that asking for the *first* element in the iterator causes *all* of the futures to be created. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10762] strftime('%f') segfault
Roundup Robot devnull@devnull added the comment: New changeset 2ca1bc677a60 by Senthil Kumaran in branch '3.1': Issue #10762: Guard against invalid/non-supported format string '%f' on Windows. Patch Santoso Wijaya. http://hg.python.org/cpython/rev/2ca1bc677a60 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10762 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11778] __subclasscheck__ : class P(M): __metaclass__=M causes maximum recursion depth exceeded.
New submission from xBrawny and...@newthot.com: I wonder if this is the desired behavior. According to docs, __instancecheck__ should be called, but it never gets to it. If return True is replaced with raise Exception the result is the same. = class M(type): def __instancecheck__(cls,obj): return True class P(M): __metaclass__=M isinstance(object,P) isinstance(object,P) RuntimeError: maximum recursion depth exceeded while calling a Python object -- components: Interpreter Core messages: 133110 nosy: xBrawny priority: normal severity: normal status: open title: __subclasscheck__ : class P(M): __metaclass__=M causes maximum recursion depth exceeded. type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11597] Can't get ConfigParser.write to write unicode strings
the_isz the_...@gmx.de added the comment: Well, the only thing I can add to this is that the json module (which I ended up using) supports unicode with no problem. So I think the argument that most of the standard library in 2.x assumes bytestrings is a bit... shaky. Other than that, I can follow your reasoning and will just hope that all my needed external libraries will soon make it to python 3 so I don't have to fight such inconsistencies anymore :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10762] strftime('%f') segfault
Roundup Robot devnull@devnull added the comment: New changeset 1320f29bcf98 by Senthil Kumaran in branch '2.7': Issue #10762: Guard against invalid/non-supported format string '%f' on Windows. Patch Santoso Wijaya. http://hg.python.org/cpython/rev/1320f29bcf98 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10762 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10762] strftime('%f') segfault
Senthil Kumaran orsent...@gmail.com added the comment: Fixed it in relevant branches. I had to add condition around the test to verify that platform was win because this is unique to windows only. Thanks. -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10762 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10762] strftime('%f') segfault
Changes by Senthil Kumaran orsent...@gmail.com: -- assignee: - orsenthil resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10762 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
anatoly techtonik techto...@gmail.com added the comment: 2011/4/6 Jesús Cea Avión rep...@bugs.python.org: Jesús Cea Avión j...@jcea.es added the comment: Some more references: Read the notes under the slides: https://dgl.cx/2011/01/dtrace-and-perl https://dgl.cx/dtrace http://dtrace.org/blogs/ What do we need to unblock this? Summarize 30+ page discussion in a new issue. Blog about it on http://blog.python.org/ -- anatoly t. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11779] test_mmap timeout (30 min) on AMD64 Snow Leopard 3.x buildbot
New submission from STINNER Victor victor.stin...@haypocalc.com: The creation of a file of 5.25 GB took more than 30 min on AMD64 Snow Leopard 3.x buildbot, and so regrtest exited: - [ 27/354] test_mmap Thread 0x7fff70439ca0: File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_mmap.py, line 685 in test_large_offset File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py, line 387 in _executeTestPart File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py, line 442 in run File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/case.py, line 494 in __call__ File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py, line 105 in run File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py, line 67 in __call__ File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py, line 105 in run File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/unittest/suite.py, line 67 in __call__ File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py, line 1078 in run File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py, line 1166 in _run_suite File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/support.py, line 1192 in run_unittest File /Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_mmap.py, line 706 in test_main File ./Lib/test/regrtest.py, line 1032 in runtest_inner File ./Lib/test/regrtest.py, line 826 in runtest File ./Lib/test/regrtest.py, line 650 in main File ./Lib/test/regrtest.py, line 1607 in module make: *** [buildbottest] Error 1 program finished with exit code 2 elapsedTime=1909.71 - http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/46/steps/test/logs/stdio -- components: Tests messages: 133115 nosy: haypo priority: normal severity: normal status: open title: test_mmap timeout (30 min) on AMD64 Snow Leopard 3.x buildbot versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11779] test_mmap timeout (30 min) on AMD64 Snow Leopard 3.x buildbot
STINNER Victor victor.stin...@haypocalc.com added the comment: The test step was interrupted after 38 mins, 45 secs (including 30 min of timeout) at the test 27, whereas the previous (success) test step took 46 mins, 55 secs to execute all (354) tests. -- nosy: +ixokai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11597] Can't get ConfigParser.write to write unicode strings
Łukasz Langa luk...@langa.pl added the comment: As another core dev aptly said, most standard library Unicode support is probably accidental. As for `json`, this is one of the newest additions to stdlib, introduced in Python 2.6 (released at the same time as Python 3.0). Not the best example if you compare it to libraries that were added in 1.5 or so. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11597] Can't get ConfigParser.write to write unicode strings
STINNER Victor victor.stin...@haypocalc.com added the comment: I think it is more a question of is this an easy fix? or would it require extensive changes to support unicode properly. First of all, the question is: who would like to develop it. You can vote for an issue, but it doesn't change anything if you don't find a developer to implement your idea :-) Anyway, try to use Python everywhere in Python 2 is a waste of time. The work has already been done in Python 3, and it's much easier to use Unicode in Python 3, just because everything uses Unicode (exceptions, filenames, file content, modules, etc.). -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11605] EMail generator.flatten() disintegrates over non-ascii multipart/alternative
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment: On Tue, Apr 05, 2011 at 08:35:22PM +, R. David Murray wrote: Simple fix, but it took me a while to track down the critical piece of code. I've really tried to break it, but i can't. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11605 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11780] email.encoders are broken
New submission from Steffen Daode Nurpmeso sdao...@googlemail.com: This is what one gets if using a BytesParser() generated message: encoders.encode_7or8bit(msg) AttributeError: 'list' object has no attribute 'decode' encoders.encode_base64(msg) TypeError: expected bytes, not list encoders.encode_quopri(msg) TypeError: 'list' does not support the buffer interface I'll attach a diff against 3.3 test_email.py which adds stupid tests (there is really no assertNoRaises()). Maybe they should also be extended so that it is actually tested wether the generated content is also correct. -- components: Library (Lib) files: test_email.1.diff keywords: patch messages: 133120 nosy: sdaoden priority: normal severity: normal status: open title: email.encoders are broken versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file21548/test_email.1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11780] email.encoders are broken
Changes by R. David Murray rdmur...@bitdance.com: -- assignee: - r.david.murray nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11781] test/test_email directory does not get installed by 'make install'
Changes by Steffen Daode Nurpmeso sdao...@googlemail.com: -- components: Installation nosy: r.david.murray, sdaoden priority: normal severity: normal status: open title: test/test_email directory does not get installed by 'make install' versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11605] EMail generator.flatten() disintegrates over non-ascii multipart/alternative
Roundup Robot devnull@devnull added the comment: New changeset b807cf929e26 by R David Murray in branch '3.2': #11605: don't use set/get_payload in feedparser; they do conversions. http://hg.python.org/cpython/rev/b807cf929e26 New changeset 642c0d6799c5 by R David Murray in branch 'default': Merge #11605: don't use set/get_payload in feedparser; they do conversions. http://hg.python.org/cpython/rev/642c0d6799c5 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11605 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11605] EMail generator.flatten() disintegrates over non-ascii multipart/alternative
R. David Murray rdmur...@bitdance.com added the comment: Thanks for the testing. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11605 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11597] Can't get ConfigParser.write to write unicode strings
STINNER Victor victor.stin...@haypocalc.com added the comment: Anyway, try to use Python everywhere in Python 2 is a waste of time. Oh... I mean use Unicode in Python 2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11280] urllib2 http_error_302 calls undefined getheaders method
Senthil Kumaran sent...@uthcode.com added the comment: Just for the explaination (as the report already closed), getheaders of HTTPMessage object is available by subclassing all the way from rfc822.py module. If you trace it through the debugger, you will come to know. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment: There seems to be also a problem with src/sparc/v9.S. https://bugs.gentoo.org/show_bug.cgi?id=362065 FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks) -- Traceback (most recent call last): File /var/tmp/portage/dev-lang/python-2.7.2_pre20110403/work/python-2.7.2_pre20110403/Lib/ctypes/test/test_callbacks.py, line 72, in test_ulonglong self.check_type(c_ulonglong, 10955412242170339782) File /var/tmp/portage/dev-lang/python-2.7.2_pre20110403/work/python-2.7.2_pre20110403/Lib/ctypes/test/test_callbacks.py, line 31, in check_type self.assertEqual(result, arg) AssertionError: 10955412241121898851L != 10955412242170339782L -- nosy: +Arfrever versions: +3rd party -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8314] test_ctypes fails in test_ulonglong on sparc buildbots
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- versions: +Python 2.7 -3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
Nick Coghlan ncogh...@gmail.com added the comment: should is a wonderful word when it comes to external APIs. We currently have a couple of problems: 1. The concrete APIs will fail noisily if given an instance of something that isn't a list, but may fail *silently* if given a subclass that adds additional state that needs to be kept in sync. 2. We don't have a standard fast path with fallback idiom for containers, so any code that wants to support arbitrary sequences has to either accept the performance penalty, or code the fast path at every point it gets used. Changing the concrete APIs to be more defensive and fall back to the abstract APIs if their assumptions are violated would be a win on both of those fronts. I also retract my performance concern from above - all of the affected code paths already include a PyX_Check() that triggers PyErr_BadInternalCall() if it fails. All we would be doing is moving that check further down in the function and dealing with a negative result differently. Some code paths would become slightly slower when used with subclasses of builtin types, but a lot of currently broken code would automatically start supporting subclasses of builtins correctly (and be well on its way to being duck-typed, instead of only working with the builtin types). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11684] Add email.parser.BytesHeaderParser
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment: This is a complete thing including tests. Note that the tests fail due to another error in generator.py (or wherever the real source is): TypeError: 'str' does not support the buffer interface Please do forget this mortifying first diff. -- nosy: -r.david.murray title: (Maybe) Add email.parser.BytesHeaderParser - Add email.parser.BytesHeaderParser versions: +Python 3.2 Added file: http://bugs.python.org/file21549/11684.1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11684 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11684] Add email.parser.BytesHeaderParser
Changes by Steffen Daode Nurpmeso sdao...@googlemail.com: Removed file: http://bugs.python.org/file21409/bytes-header-parser.1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11684 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11782] email.generator.Generator.flatten() fails
New submission from Steffen Daode Nurpmeso sdao...@googlemail.com:
This snippet (for #11684, but it's simply BytesParser with
headersonly=True in the end)
with openfile('msg_46.txt', 'rb') as fp:
msgdata = fp.read()
parser = email.parser.BytesHeaderParser()
msg = parser.parsebytes(msgdata)
out = BytesIO()
gen = email.generator.BytesGenerator(out)
gen.flatten(msg)
self.assertEqual(out.getvalue(), msgdata)
causes this error:
ERROR: test_byte_message_rfc822_only (test_email.TestMessageAPI)
--
Traceback (most recent call last):
File
/Users/steffen/usr/opt/py3k/lib/python3.3/test/test_email/test_email.py, line
200, in test_byte_message_rfc822_only
gen.flatten(msg)
File /Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py, line 91,
in flatten
self._write(msg)
File /Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py, line
137, in _write
self._dispatch(msg)
File /Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py, line
163, in _dispatch
meth(msg)
File /Users/steffen/usr/opt/py3k/lib/python3.3/email/generator.py, line
304, in _handle_message
self._fp.write(payload)
TypeError: 'str' does not support the buffer interface
--
components: Library (Lib)
messages: 133128
nosy: sdaoden
priority: normal
severity: normal
status: open
title: email.generator.Generator.flatten() fails
versions: Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11782
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1690608] email.utils.formataddr() should be rfc2047 aware
Roundup Robot devnull@devnull added the comment: New changeset 184ddd9acd5a by R David Murray in branch 'default': #1690608: make formataddr RFC2047 aware. http://hg.python.org/cpython/rev/184ddd9acd5a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1690608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11684] Add email.parser.BytesHeaderParser
Changes by R. David Murray rdmur...@bitdance.com: -- assignee: - r.david.murray nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11684 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11782] email.generator.Generator.flatten() fails
Changes by R. David Murray rdmur...@bitdance.com: -- assignee: - r.david.murray nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
Benjamin Peterson benja...@python.org added the comment: 2011/4/6 Nick Coghlan rep...@bugs.python.org: Nick Coghlan ncogh...@gmail.com added the comment: should is a wonderful word when it comes to external APIs. We currently have a couple of problems: 1. The concrete APIs will fail noisily if given an instance of something that isn't a list, but may fail *silently* if given a subclass that adds additional state that needs to be kept in sync. 2. We don't have a standard fast path with fallback idiom for containers, so any code that wants to support arbitrary sequences has to either accept the performance penalty, or code the fast path at every point it gets used. Changing the concrete APIs to be more defensive and fall back to the abstract APIs if their assumptions are violated would be a win on both of those fronts. Why not add fast paths to the generic functions if that's what you're concerned about? It's unexpected for the user of the functions and breaks years of tradition. What if someone calls PyList_Append on a custom type that doesn't do as they expect and then PyList_GET_ITEM? It seems like asking for subtle bugs to me. The only correct way to is change code that uses these type specific apis to use the generic ones. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1690608] email.utils.formataddr() should be rfc2047 aware
R. David Murray rdmur...@bitdance.com added the comment: Finally got around to committing this; thanks, Torsten. As a reward, I'm going to make you nosy on a new, related issue I'm about to create. It is, of course, your option whether you want to work on it :) By the way, have you submitted a contributor agreement? This patch isn't really big enough to require one, but having one on file is always a good idea, especially if you are going to keep contributing (and I hope you do). -- resolution: - accepted stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1690608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
Antoine Pitrou pit...@free.fr added the comment: Why not add fast paths to the generic functions if that's what you're concerned about? It's unexpected for the user of the functions and breaks years of tradition. What if someone calls PyList_Append on a custom type that doesn't do as they expect and then PyList_GET_ITEM? It seems like asking for subtle bugs to me. The only correct way to is change code that uses these type specific apis to use the generic ones. I agree with Benjamin. IIRC we already have a bunch of fast paths in abstract.c. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11783] email parseaddr and formataddr should be IDNA aware
New submission from R. David Murray rdmur...@bitdance.com: The patch for issue 1690608 adds support for unicode in the realname field to formataddr. To complete the currently-workable internationalization of address specs, both parseaddr and formataddr should be made IDNA aware. It is probably a good idea to do some research on this to double check, but it seems as though recognizing IDNA during parsing and generating it during formatting when the domain contains non-ASCII characters should be both safe and useful. See also issue 963906, which contains some test cases that could be adapted. -- assignee: r.david.murray components: Library (Lib) keywords: easy messages: 133133 nosy: r.david.murray, torsten.becker priority: normal severity: normal stage: needs patch status: open title: email parseaddr and formataddr should be IDNA aware type: feature request versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue963906] Unicode email address helper
R. David Murray rdmur...@bitdance.com added the comment: Issue 1690608 addresses part of this issue, and issue 11783 will address the IDNA part. From my point of view those two issues solve this problem from the perspective the email package infrastructure and *current* API. In the email6 API I do plan to have an address helper class that will make managing addresses more conveniently OO, but that is part of the whole email6 process and I don't feel a need any longer to keep this issue open. There's no good value for 'resolution' to express the resolution here (I've accepted the idea but not the code), so I used 'remind', since I will be coming back to the idea in a little while. -- resolution: - remind stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue963906 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11781] test/test_email directory does not get installed by 'make install'
New submission from R. David Murray rdmur...@bitdance.com: Attached is a patch. I'm not sure that I've done everything that needs to be done on the Windows side, though. Martin? -- keywords: +patch nosy: +loewis Added file: http://bugs.python.org/file21550/build_update_for_test_email.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7311] Bug on regexp of HTMLParser
Éric Araujo mer...@netwok.org added the comment: I think the stdlib should comply with HTML 4.01, and in the future HTML 5. (FTR, I don’t think XHTML is useful, and deny that XHTML-compatible HTML exists. See http://bugs.python.org/issue11567#msg131509 :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11781] test/test_email directory does not get installed by 'make install'
Changes by R. David Murray rdmur...@bitdance.com: -- assignee: - r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
Nick Coghlan ncogh...@gmail.com added the comment: 1. It's an external API. We *don't control* most of the potentially broken code, so saying just fix the call sites effectively solves nothing and leaves classes like OrderedDict at risk of subtle silent corruption whenever they are passed to a 3rd party C extension. 2. The alternate fix is to tighten up the PyX_Check calls to PyX_CheckExact in order to reject subclasses. That would be a huge pain from a backwards compatibility point of view, so it isn't a realistic option. 3. Another alternate fix would be to exclude the concrete API from the stable ABI. That was already done for the macro interfaces, but it's too late for the functions - they were included in the stable interface for the 3.2 release. 4. The fact that the macros are irredeemably broken when used without ensuring that the supplied object is exactly the expected type is a very poor excuse for not fixing the function calls. It sounds like The taillight is busted too, so let's not bother fixing the brakes. 5. There's a reason I put the fast path point second - that benefit is just an added bonus that comes from fixing the real design flaw that Raymond pointed out. All that said, there really is one specific case where fixing this problem could cause a serious backwards compatibility issue: subclasses of builtin types that are *themselves* written in C. In such cases, the method implementations would quite likely use the concrete API to handle the base class state, then do their own thing to handle the rest of the update. Adding an implicit fallback to the concrete API implementations would cause such cases to trigger infinite recursion at the C level. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
Nick Coghlan ncogh...@gmail.com added the comment: Having convinced myself that Raymond's original suggestion can't be implemented safely, I have an alternative (arguably even more radical) proposal: Deprecate the public concrete API functions that modify object state. Put an underscore in front of them for internal use, have the public versions trigger a deprecation warning (not to be removed until 3.6 or so), provide a C level mechanism to easily make the equivalent of a super() call and advise that everyone switch to the abstract API in order to handle subclasses properly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
Antoine Pitrou pit...@free.fr added the comment: 1. It's an external API. We *don't control* most of the potentially broken code, so saying just fix the call sites effectively solves nothing and leaves classes like OrderedDict at risk of subtle silent corruption whenever they are passed to a 3rd party C extension. But since that problem has been existing for ages, we're not in a rush to fix it either, are we? After all, people do have to fix their code from time to time (or port it to Python 3). Using the right APIs for the job is part of that. Pointing to the abstract alternatives in the documentation for concrete APIs may help people do so. In the long term, having a clean CPython API with a proper separation of concerns is a major benefit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11732] Skip decorator for tests requiring manual intervention on Windows
Brian Curtin br...@python.org added the comment: Disabling and re-enabling is another possibility, and it's probably more likely to help in the long run. Most (all?) Windows machines have error reporting enabled unless you mess with the registry manually, so the only place tests would be run with my first patch would be on build slaves. I don't currently have a Ubuntu or Fedora machine, but I could look into it. I'll write up a patch that disables/re-enables for Windows and see how it works. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
Nick Coghlan ncogh...@gmail.com added the comment: Changing the affected components. Antoine and Benjamin are right, this needs to be handled as a documentation and education problem. Raymond's suggestion can too easily trigger infinite recursion and mine would block legitimate use cases in 3rd party code. For heapq, we can just fix it to include the fallbacks to the abstract versions if PyList_CheckExact() fails. -- assignee: - docs@python components: +Documentation -Interpreter Core nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11784] multiprocessing.Process.join: timeout argument doesn't specify time unit.
New submission from Patrick Sabin patricksa...@gmx.at: The documentation of multiprocessing.Process.join doesn't tell the user of which time unit the timeout argument is. It seems to be seconds. -- assignee: docs@python components: Documentation files: join-timeout-doc-improvement.patch keywords: patch messages: 133142 nosy: docs@python, pyfex priority: normal severity: normal status: open title: multiprocessing.Process.join: timeout argument doesn't specify time unit. type: behavior Added file: http://bugs.python.org/file21551/join-timeout-doc-improvement.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11785] email subpackages documentation problems
New submission from ysj.ray ysj@gmail.com: All the module name in the first line of email subpackages' documentation files(Doc/library/email.xxx.rst) are incorrect: all of them are email but not email.xxx Besides, the Doc/library/email-examples.rst is not a module and it uses :mod:`email`: xxx -- assignee: docs@python components: Documentation files: email_subpackages_document_problems.diff keywords: patch messages: 133143 nosy: docs@python, ysj.ray priority: normal severity: normal status: open title: email subpackages documentation problems versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file21552/email_subpackages_document_problems.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11785] email subpackages documentation problems
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11785] email subpackages documentation problems
ysj.ray ysj@gmail.com added the comment: And this causes the toctree in email doc(http://docs.python.org/dev/library/email.html) in correct. All of the tree elements' names are displayed as email. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7311] Bug on regexp of HTMLParser
Ezio Melotti ezio.melo...@gmail.com added the comment: I would agree if the HTMLParser was compliant with the HTML 4.01 specs, but since it's more permissive and uses its own heuristic to determine what should be parsed and what shouldn't, I think it's better to use already existing heuristics (either the HTML5 ones or the ones used by the browsers). I.e., I'm not trying to make it HTML5 compliant, just to make it work with what works on the browsers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7311] Bug on regexp of HTMLParser
Éric Araujo mer...@netwok.org added the comment: Okay, sounds good. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
Dave Malcolm dmalc...@redhat.com added the comment: jcea: I notice that on 2011-02-22 you made these changes: assignee: dmalcolm - dino.viehland nosy: +dino.viehland versions: +Python 3.3 -Python 3.2 Did you mean to change the assignee, or was this an accident? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11786] ConfigParser.[Raw]ConfigParser optionxform()
New submission from Adam Groszer agros...@gmail.com: The documentation http://docs.python.org/library/configparser.html states that optionxform() is used only beginning ConfigParser.ConfigParser, whereas it is ALSO in effect for ConfigParser.RawConfigParser. (As I checked in the source) -- assignee: docs@python components: Documentation messages: 133148 nosy: Adam.Groszer, docs@python priority: normal severity: normal status: open title: ConfigParser.[Raw]ConfigParser optionxform() type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11786] ConfigParser.[Raw]ConfigParser optionxform()
Changes by Łukasz Langa luk...@langa.pl: -- assignee: docs@python - lukasz.langa nosy: +lukasz.langa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7311] Bug on regexp of HTMLParser
Senthil Kumaran sent...@uthcode.com added the comment: We need not base changes to html/parser.py on html5 spec, but rather make changes based on the requirements on parsers which may rely on this library. Like the tolerant mode was brought in issue1486713 for some practical reasons and it was seen useful tor parsers. I don't know, how common is leaving out quotes for attributes is, but I think it can become really confusing to parsers (custom parsers). If we had not supported non-quote attributes I think, it is still okay still to not-to-support unless presented with case as very concrete bug. (like spec html 4.1 allows, which I see it does not). The patch which added support for non-ascii characters is fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11786] ConfigParser.[Raw]ConfigParser optionxform()
Łukasz Langa luk...@langa.pl added the comment: The documentation may be poorly worded but `optionxform()` has always been used also by RawConfigParser. It has been that way since the introduction of this class in Python 2.3 (previously there was only one ConfigParser class which used `optionxform()` since at least Python 1.6). Both the documentation and the code have seen significant updates in Python 3.2 and there the situation is more explicit. I'll rephrase the docs for 2.7. -- resolution: - accepted ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
Jesús Cea Avión j...@jcea.es added the comment: Malcolm, it was a mistake. I only wanted to change the TARGET. I assign the issue to you again. Dino, I delete you from the nosy list now. Sorry for the inconvenience. My excuses to both. -- assignee: dino.viehland - dmalcolm nosy: -dino.viehland ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11779] test_mmap timeout (30 min) on AMD64 Snow Leopard 3.x buildbot
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment: I can't confirm that. On my cheap MacBook it takes some five minutes: 20:20 ~ $ time python3 -E -Wd -m test -r -w -uall test_mmap Using random seed 1490092 [1/1] test_mmap 1 test OK. [91067 refs] real4m50.301s user0m0.301s sys 0m13.232s ... 20:21 ~ $ ll tmp/test_python_478/ total 6291456 6291456 -rw-r- 1 steffen staff 6442450944 6 Apr 20:21 @test_478_tmp ... Processes: 63 total, 2 running, 2 stuck, 59 sleeping, 251 threads 20:23:00 Load Avg: 0.85, 0.51, 0.24 CPU usage: 9.13% user, 15.38% sys, 75.48% idle SharedLibs: 8260K resident, 9972K data, 0B linkedit. MemRegions: 5563 total, 184M resident, 12M private, 391M shared. PhysMem: 437M wired, 267M active, 113M inactive, 818M used, 1230M free. VM: 140G vsize, 1042M framework vsize, 24419(0) pageins, 0(0) pageouts. Networks: packets: 91/17K in, 101/17K out. Disks: 11128/551M read, 11089/8215M written. PID COMMAND %CPU TIME #TH #WQ #POR #MRE RPRVT RSHRD RSIZE VPRVT VSIZE 478 python3 4.0 00:07.22 2037 137 13M244K 15M30M 2402M ... 20:24 ~ $ ll tmp/test_python_478/ total 5505024 5505024 -rw-r- 1 steffen staff 5637144576 6 Apr 20:24 @test_478_tmp ... Processes: 60 total, 2 running, 1 stuck, 57 sleeping, 246 threads 20:24:00 Load Avg: 1.28, 0.69, 0.33 CPU usage: 8.29% user, 16.9% sys, 75.60% idle SharedLibs: 8260K resident, 9972K data, 0B linkedit. MemRegions: 5444 total, 181M resident, 11M private, 535M shared. PhysMem: 437M wired, 259M active, 124M inactive, 820M used, 1228M free. VM: 133G vsize, 1042M framework vsize, 24421(0) pageins, 0(0) pageouts. Networks: packets: 91/17K in, 101/17K out. Disks: 11128/551M read, 14697/11G written. PID COMMAND %CPU TIME #TH #WQ #POR #MRE RPRVT RSHRD RSIZE VPRVT VSIZE 478 python3 4.4 00:10.04 2037 137 13M244K 15M30M 2402M Is this the bot for which you've tracked those random failures? Maybe this is a hardware failure, then? (In the past i have had problems with my old PC and it's Elitegroup K7S5A motherboard, running on FreeBSD 5.3. That thing randomly produced Stray IRQ 11 (about ~handful a day), and it's ATA controller (i think) randomly caused complete hard disk regions to become unreadable until after a restart.) -- nosy: +sdaoden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Changes by Barry A. Warsaw ba...@python.org: -- assignee: - barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11787] File handle leak in TarFile lib
New submission from Pulin Shah sha...@gmail.com: I ran into a problem the other day while trying to extract a slightly corrupted tar file. I suspect this problem is really only an issue on Windows systems. I am running Python 2.7.1 r271:86832 win32. The following code (simplified) snipet try: tar = tarfile.open(args.file) tar.extractall(basefolder) tar.close() except tarfile.ReadError: shutil.rmtree(basefolder) except IOError: shutil.rmtree(basefolder) was throwing a WindowsError on the rmtree calls. This is due to the tarfile library not closing file handles in the case of an exception in the copyfileobj function, and Windows inability to delete open files. I was able to patch the issue locally by modifying tarfile's makefile function as follows: def makefile(self, tarinfo, targetpath): Make a file called targetpath. source = self.extractfile(tarinfo) target = bltn_open(targetpath, wb) try: copyfileobj(source, target) except: source.close() target.close() raise source.close() target.close() There is probably a cleaner way of implementing it. I'm hoping you can integrate this patch into later versions of the lib. Thanks. -- components: Library (Lib) messages: 133153 nosy: shahpr priority: normal severity: normal status: open title: File handle leak in TarFile lib type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11277] test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD)
Steffen Daode Nurpmeso sdao...@googlemail.com added the comment: I can't confirm this for my MacBook: 20:39 ~ $ time python3 -E -Wd -m test -r -w -uall test_zlib Using random seed 1960084 [1/1] test_zlib 1 test OK. [91618 refs] real4m1.051s user0m15.031s sys 0m26.908s ... 20:40 ~ $ ll tmp/test_python_6778/ 4194308 -rw-r- 1 steffen staff 4294967300 6 Apr 20:40 @test_6778_tmp ... Processes: 63 total, 2 running, 3 stuck, 58 sleeping, 246 threads 20:40:30 Load Avg: 0.59, 0.65, 0.56 CPU usage: 6.79% user, 13.10% sys, 80.9% idle SharedLibs: 8260K resident, 9972K data, 0B linkedit. MemRegions: 6043 total, 218M resident, 13M private, 185M shared. PhysMem: 446M wired, 328M active, 138M inactive, 912M used, 1135M free. VM: 143G vsize, 1042M framework vsize, 29610(0) pageins, 0(0) pageouts. Networks: packets: 807/440K in, 933/129K out. Disks: 13881/581M read, 26057/16G written. PID COMMAND %CPU TIME #TH #WQ #PORT #MRE RPRVT RSHRD RSIZE VPRVT VSIZE 6778 python3 4.5 00:00.94 2037139 13M320K 15M38M 2403M ... Processes: 63 total, 3 running, 60 sleeping, 253 threads 20:41:30 Load Avg: 0.54, 0.62, 0.55 CPU usage: 12.98% user, 14.90% sys, 72.11% idle SharedLibs: 8260K resident, 9972K data, 0B linkedit. MemRegions: 6062 total, 269M resident, 13M private, 274M shared. PhysMem: 443M wired, 329M active, 184M inactive, 955M used, 1091M free. VM: 147G vsize, 1042M framework vsize, 41530(11520) pageins, 0(0) pageouts. Networks: packets: 807/440K in, 933/129K out. Disks: 13950/627M read, 29598/19G written. PID COMMAND %CPU TIME #TH #WQ #PORT #MRE RPRVT RSHRD RSIZE VPRVT VSIZE 6778 python3 11.6 00:03.74 2037140 60M+ 320K 62M+ 4134M 6499M ... 20:43 ~ $ ll tmp/test_python_6778/ 4194308 -rw-r- 1 steffen staff 4294967300 6 Apr 20:40 @test_6778_tmp As i've stated for #11779, maybe these random errors of the bot are caused by some strange hardware based error? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11277 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Stefan Krah stefan-use...@bytereef.org added the comment: Since I do automated module testing against all Python versions, my vote would be: 2.5: +1 2.6: +1 3.1: +1 This with the caveat that of course Martin has to decide for 2.5. I'm just indicating my preference. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4735] An error occurred during the installation of assembly
Shereef Marzouk shee...@gmail.com added the comment: here is the log. P.S. i have VS Studio 2005 installed -- nosy: +Shereef Added file: http://bugs.python.org/file21553/python.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4735] An error occurred during the installation of assembly
Shereef Marzouk shee...@gmail.com added the comment: in my last message i forgot to give more details sorry i first installed python 2.7.1 for amd64 but it made problems iwht pywin and buildbot-slave packeges so i wanted to install python the i386 one and i got this error i tried amd64 again now and it installed fine -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4735] An error occurred during the installation of assembly
Shereef Marzouk shee...@gmail.com added the comment: uhm, i restarted my pc and everything went through fine -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4735 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11767] Maildir iterator leaks file descriptors by default
Filip Gruszczyński grusz...@gmail.com added the comment: Shouldn't this be your responsibility to close this descriptor in the object used as self._factory? When self._factory is called it should read from the file like object and then simply close it, just as get_message (when self._factory is not provided) does. -- nosy: +gruszczy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11767] Maildir iterator leaks file descriptors by default
Brendan Dolan-Gavitt brenda...@gatech.edu added the comment: The _factory object didn't open the file, so why should it close it? It's also worth noting that things one would naturally consider using as factories (like email.message_from_file) don't close the fd when they're done. I will grant that you could easily create a wrapper factory that does close the descriptor in this case, but that's not the obvious thing to do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
Charles-Francois Natali neolo...@free.fr added the comment: Does this only happen on Cygwin buildbots ? If yes, then it might simply be an issue with Cygwin's fork implementation, which is much slower than natively. Right now, the test waits 0.5s before checking that the processes are started, after repopulating the pool. While 0.5s is normally way enough for forking a couple processes, it seems that under Cygwin this can take a surprising amount of time, see http://old.nabble.com/Slow-fork-issue---Win-x64-td19538601.html and also http://superuser.com/questions/133313/can-i-speed-up-cygwins-fork Unless I misunderstand their benchmarks, the fork (+exec) rate of date from a shell can be as low as 5/sec, so I can only guess what forking cpython would take. Maybe we could try to increase the timeout before checking the PIDs: +countdown = 10 -countdown = 10 while countdown and not all(w.is_alive() for w in p._pool): countdown -= 1 time.sleep(DELTA) -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11767] Maildir iterator leaks file descriptors by default
R. David Murray rdmur...@bitdance.com added the comment: It is not clear from the docs what the expected behavior of factory is. It is certainly the case that the custom classes used by mailbox by default do not close the file they are passed. So either those classes should close the input file and factory should be so documented, or all the methods that create a message object should close the input file when they create one. Since the existing get_message methods take care to close any opened input files, I favor the latter (ie: the OP's suggestion). Anyone care to propose a patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
Antoine Pitrou pit...@free.fr added the comment: There is no Cygwin buildbot, this is a regular Windows buildbot (despite the path in the traceback). That said, spawning processes is quite slow under Windows anyway (much slower than under Linux). So we could up the countdown. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Roundup Robot devnull@devnull added the comment: New changeset 7582a78f573b by Barry Warsaw in branch '3.1': Issue 11715: Build extension modules on multiarch Debian and Ubuntu by http://hg.python.org/cpython/rev/7582a78f573b New changeset 867937dd2279 by Barry Warsaw in branch '3.2': Issue 11715: Merge multiarch fix from 3.1 branch. http://hg.python.org/cpython/rev/867937dd2279 New changeset 3f00611c3daf by Barry Warsaw in branch 'default': Issue 11715: Merge multiarch fix from 3.1 branch. http://hg.python.org/cpython/rev/3f00611c3daf -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
Roundup Robot devnull@devnull added the comment: New changeset c4a514199dba by Antoine Pitrou in branch '3.2': Issue #11766: increase countdown waiting for a pool of processes to start http://hg.python.org/cpython/rev/c4a514199dba New changeset 3eac8302a448 by Antoine Pitrou in branch 'default': Issue #11766: increase countdown waiting for a pool of processes to start http://hg.python.org/cpython/rev/3eac8302a448 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11785] email subpackages documentation problems
Changes by R. David Murray rdmur...@bitdance.com: -- assignee: docs@python - r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
Roundup Robot devnull@devnull added the comment: New changeset 2e4cdaffe493 by Antoine Pitrou in branch '2.7': Issue #11766: increase countdown waiting for a pool of processes to start http://hg.python.org/cpython/rev/2e4cdaffe493 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11766] test_multiprocessing failure (test_pool_worker_lifetime)
Antoine Pitrou pit...@free.fr added the comment: Hopefully fixed now, thanks for your diagnosis! -- resolution: - fixed stage: - committed/rejected status: open - closed versions: -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11766 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11787] File handle leak in TarFile lib
Changes by Ned Deily n...@acm.org: -- nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11492] email.header.Header doesn't fold headers
Scott Kitterman skl...@kitterman.com added the comment: Not so fast ... I may have done this wrong, but I get: print(Header(hdrin,maxlinelen=78)) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for b...@kitterman.com; Sun, 13 Mar 2011 23:46:05 -0400 (EDT) all in one line with python3.2, so maxlinelen doesn't appear to do anything. With python2.7 it seems to when invoked that way: Python 2.7.1+ (r271:86832, Mar 24 2011, 00:39:14) [GCC 4.5.2] on linux2 Type help, copyright, credits or license for more information. from email.header import Header hdrin = 'Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for b...@kitterman.com; Sun, 13 Mar 2011 23:46:05 -0400 (EDT)' print(Header(hdrin)) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for b...@kitterman.com; Sun, 13 Mar 2011 23:46:05 -0400 (EDT) print(Header(hdrin, maxlinelen=30)) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by mailwash7.pair.com (Postfix) with ESMTP id 16BB5BAD5 for b...@kitterman.com; Sun, 13 Mar 2011 23:46:05 -0400 (EDT) -- resolution: invalid - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11492 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11492] email.header.Header doesn't fold headers at spaces
R. David Murray rdmur...@bitdance.com added the comment: You have to do an 'encode' to get the wrapped header. __str__ uses maxlinelen=None. However, there does seem to be a problem with the line wrapping algorithm revealed by your example: it is only doing a line break at the ';', not at any spaces. I will look in to this. -- title: email.header.Header doesn't fold headers - email.header.Header doesn't fold headers at spaces ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11492 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
New submission from Carsten Klein carsten.kl...@axn-software.de: Scenario: class deco(object): def __init__(self, optional = False): self._optional = optional def __call__(self, decorated): decorated.optional = self._optional return decorated @deco class y(object): pass will fail decorating the class since y is passed in as the first parameter to deco.__init__, and deco.__call__ will never be called. @deco(optional = True) class y(object): pass will succeed. I wonder why there is a distinction between decorator class w/ arguments and decorator class w/o arguments? Guessing that one would like to have a decorator class decorating another class and also acting as a kind of proxy by implementing a __call__ method, this could also be achieved by further indirection, provided that it will not break existing code. A working alternative would be a decorator function like this: def deco(_decorated = None, optional = False): def _wrapped(decorated): decorated.optional = optional return decorated if _decorated is not None: return _wrapped(decorated) return _wrapped Is there a chance that the behavior of the decorator class will be fixed in a future release? Expected behavior for the decorator class would be: if formal parameter list has optional parameters and actual parameter list is empty and there are no formal mandatory parameters: if decorator class is callable: deco = decorator class () decor.__call__(decorated) else: fall back to old behaviour, requiring the decorator class __init__ method to have one mandatory parameter else: deco = decorator class(actual parameters...) deco.__call__(decorated) TIA -- components: Interpreter Core messages: 133171 nosy: carsten.klein priority: normal severity: normal status: open title: Decorator class with optional arguments and a __call__ method gets not called when there are no arguments type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Carsten Klein carsten.kl...@axn-software.de added the comment: will fail decorating the class since y... actually means that instead of an instance of class y, an instance of the decorator class will be returned, with y being lost along the way... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11789] Extend upon metaclass/type class documentation, here: zope.interface and usage of instances of classes as base classes
New submission from Carsten Klein carsten.kl...@axn-software.de: In zope.interface, you have something the following construct: class InterfaceBase: pass Interface = InterfaceBase() Using the above Interface as a derivation base for your own classes, will make that instance a type derived class: class IFoo(Interface): pass type(IFoo) - Interface type(Interface) - type I wonder why this behavior is not documented in the official documentation, or at least, I was unable to find it there... -- assignee: docs@python components: Documentation messages: 133173 nosy: carsten.klein, docs@python priority: normal severity: normal status: open title: Extend upon metaclass/type class documentation, here: zope.interface and usage of instances of classes as base classes type: feature request versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11789 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7311] Bug on regexp of HTMLParser
Ezio Melotti ezio.melo...@gmail.com added the comment: So is the issue7311-3.diff patch fine? It changes the strict regex to match the 2.7 one, and leave the tolerant one unchanged (even if now the two regexs are really close). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Santoso Wijaya santoso.wij...@gmail.com added the comment: I wonder if this is a valid use-case to begin with. The semantic of a decorator, as I understand it, is very straightforward in that this: @foo @bar class A: pass is equivalent to this: class A: pass A = foo(bar(A)) In your example, the equivalent statement is: y = deco(y) Which gives you the somewhat surprising result, but it is as the language is designed. -- nosy: +santa4nt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
Raymond Hettinger raymond.hettin...@gmail.com added the comment: One thing that could be done is to have an optional warning in the mutating concrete C API functions that gets triggered whenever the input doesn't have an exact type match. That will let people discover incorrect uses. We could also scour our own stdlib code to see if there are any cases where there needs to be an alternate code patch for subclasses of builtin types. I did a scan for PyList_SetItem and found that we were already pretty good about only using it when the target was known to be an exact list. Though those results were good, I'm not hopeful for a similar result with PyDict_SetItem. In the mean time this bug will preclude a C version of OrderedDict from being a dict subclass. That's unfortunate because it means that the C version can't be a drop-in replacement for the existing pure python OrderedDict. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Carsten Klein carsten.kl...@axn-software.de added the comment: I think it is, actually, considering @foo @bar class A: pass with foo and bar being both decorator classes, the chained call foo(bar(A)) will return and instance of foo instead of A With decorator classes you need to actually do this: foo()(bar()(A)) which will give you the required result, an instance of class A. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Benjamin Peterson benja...@python.org added the comment: This is expected; it's the same with functions. Just do @deco(). -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Carsten Klein carsten.kl...@axn-software.de added the comment: Ok, looks like a valid work around to me. However, IMO it is not the same as with decorator functions. These will be called and will return the correct result, whereas the decorator class will instead return an instance of self instead of being called when no parameters are given. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Raymond Hettinger raymond.hettin...@gmail.com added the comment: I concur with Benjamin. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11788] Decorator class with optional arguments and a __call__ method gets not called when there are no arguments
Benjamin Peterson benja...@python.org added the comment: 2011/4/6 Carsten Klein rep...@bugs.python.org: Carsten Klein carsten.kl...@axn-software.de added the comment: Ok, looks like a valid work around to me. It's not a workaround. It's the way decorators work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11790] transient failure in test_multiprocessing.WithProcessesTestCondition
New submission from Antoine Pitrou pit...@free.fr: http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%202.7/builds/519/steps/test/logs/stdio == FAIL: test_notify_all (test.test_multiprocessing.WithProcessesTestCondition) -- Traceback (most recent call last): File /usr/home/db3l/buildarea/2.7.bolen-freebsd7/build/Lib/test/test_multiprocessing.py, line 757, in test_notify_all self.assertReturnsIfImplemented(6, get_value, woken) File /usr/home/db3l/buildarea/2.7.bolen-freebsd7/build/Lib/test/test_multiprocessing.py, line 116, in assertReturnsIfImplemented return self.assertEqual(value, res) AssertionError: 6 != 5 -- components: Library (Lib), Tests messages: 133182 nosy: pitrou priority: normal severity: normal status: open title: transient failure in test_multiprocessing.WithProcessesTestCondition type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11790 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11703] Bug in python = 2.7 with urllib2 fragment
Santoso Wijaya santoso.wij...@gmail.com added the comment:
It already does. ;-)
Python 2.7.1+ (default, Apr 6 2011, 16:25:38) [MSC v.1500 32 bit (Intel)] on wi
n32
Type help, copyright, credits or license for more information.
import urllib2
[74578 refs]
fp = urllib2.urlopen('http://16.foobnix-cms.appspot.com/test_base')
[75643 refs]
fp.geturl()
http://16.foobnix-cms.appspot.com/test_redirect#json={value:'OK'}
[75645 refs]
I'm attaching patches with the appropriate unittest for the redirected case,
though.
--
Added file: http://bugs.python.org/file21555/issue11703_py27_with_redirect.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11703
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11703] Bug in python = 2.7 with urllib2 fragment
Changes by Santoso Wijaya santoso.wij...@gmail.com: Added file: http://bugs.python.org/file21556/issue11703_py31_with_redirect.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8428] buildbot: test_multiprocessing timeout (test_notify_all? test_pool_worker_lifetime?)
STINNER Victor victor.stin...@haypocalc.com added the comment: Another test_multiprocessing failure (30 min timeout) on x86 XP-4 3.x: -- [125/354] test_multiprocessing Thread 0x0e5c: File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 235 in wait File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py, line 185 in get File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py, line 372 in _handle_results File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 688 in run File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 735 in _bootstrap_inner File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 708 in _bootstrap Thread 0x0c14: File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 235 in wait File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py, line 185 in get File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py, line 331 in _handle_tasks File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 688 in run File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 735 in _bootstrap_inner File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 708 in _bootstrap Thread 0x0d78: File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py, line 324 in _handle_workers File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 688 in run File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 735 in _bootstrap_inner File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 708 in _bootstrap Thread 0x03b8: File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 235 in wait File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py, line 185 in get File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py, line 102 in worker File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 688 in run File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 735 in _bootstrap_inner File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 708 in _bootstrap Thread 0x01e8: File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 235 in wait File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py, line 185 in get File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py, line 102 in worker File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 688 in run File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 735 in _bootstrap_inner File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 708 in _bootstrap Thread 0x02ac: File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 235 in wait File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py, line 185 in get File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py, line 102 in worker File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 688 in run File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 735 in _bootstrap_inner File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 708 in _bootstrap Thread 0x05a4: File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 235 in wait File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\queue.py, line 185 in get File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py, line 102 in worker File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 688 in run File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 735 in _bootstrap_inner File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py, line 708 in _bootstrap Thread 0x0c84: File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\forking.py, line 287 in wait File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\process.py, line 149 in join File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\pool.py, line 458 in join File D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_multiprocessing.py, line 1143 in test_async_error_callback File
[issue7311] Bug on regexp of HTMLParser
R. David Murray rdmur...@bitdance.com added the comment: Sounds fine to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11767] Maildir iterator leaks file descriptors by default
Changes by R. David Murray rdmur...@bitdance.com: Removed file: http://bugs.python.org/file21554/11767.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11767] Maildir iterator leaks file descriptors by default
R. David Murray rdmur...@bitdance.com added the comment: get_file's promise is that what is returned is a file like object, so it not having a close() method would be an error. So I don't think you need the try/except. What I would suggest is to use the 'closing' context manager around the return statement. As for tests, you could create a subclass with a custom get_file method that returns a mock object you can test to make sure the close method gets called, since Mailbox is the only place __getitem__ is defined. Gah, I hit the wrong key an deleted your patch. Reattaching. -- Added file: http://bugs.python.org/file21557/11767.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11700] mailbox.py proxy updates
R. David Murray rdmur...@bitdance.com added the comment: Given your problem report wouldn't the simplest solution be to change the close method to be: if hasattr(self, '_file'): if hasattr(self._file, 'close'): self._file.close() del self._file As for a test, it seems to me that adding a test to the appropriate existing cases that calls get_file and then closes the returned object twice should be sufficient. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11700 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7311] Bug on regexp of HTMLParser
Senthil Kumaran sent...@uthcode.com added the comment: So is the issue7311-3.diff patch fine? Just that it allows unquoted attrs for unicode too. My previous suggestion was not to allow unquoted attribute values, but as the change is already made in 2.7 and discussion pointed out a portion in 4.1 spec which allows unquoted attrs for ASCII, it seems fine. html/parse.py will be bit more permissive than what the spec says. It changes the strict regex to match the 2.7 one, and leave the tolerant one unchanged. That is fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7311] Bug on regexp of HTMLParser
Ezio Melotti ezio.melo...@gmail.com added the comment: On 3.2 the patch changes only the range of chars matched by the regex when the attribute value doesn't have quotes and strict=True. The parser already allowed unquotes attribute values even before the patch (in both strict and tolerant mode), but used an explicit list of allowed chars that was limited to the ASCII range. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6059] ctypes/uuid-related segmentation fault
atppp wuxi...@gmail.com added the comment: crash with python/2.6.5, imagemagick/6.5.7.8, uuid/2.17.2, ubuntu/10.04: import magickwand.image import uuid uuid.uuid4() -- nosy: +atppp ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API needs abstract path for subclasses of builtin types
Nick Coghlan ncogh...@gmail.com added the comment: I thought about a warning, but the problem is that a subclass using the concrete API as part of its *implementation* of the associated slot or method is actually perfectly correct usage. I'm not sure this is enough to give up on the idea of OrderedDict being a dict subclass implemented in C, though. It seems to me that some defensive internal checks (to pick up state corruption due to this problem) would be a lesser evil than giving up on being a dict subclass. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
