[issue19414] iter(ordered_dict) yields keys not in dict in some circumstances

Nikolaus Rath added the comment: Raymond, I think your patch does not really address the issue reported here. The dict documentation still guarantees that mutating a dict during iteration will raise a RuntimeError or may skip elements. The OrderedDict documentation still does not point out tha

[issue21435] Segfault with cyclic reference and asyncio.Future

Tim Peters added the comment: xxx.py provokes a closely related death on my box, in a debug build (where 0xdbdbdbdb happened to be an invalid memory address). There are no imports so asyncio is definitely off the hook ;-) The code is senseless, and changing just about anything makes the probl

[issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument

Andreas van Cranenburgh added the comment: Here's a version with tests. Detecting an execption in the initializer works with ProcessPoolExecutor, but not with ThreadPoolExecutor. -- Added file: http://bugs.python.org/file35181/pool_initializer_tests.patch __

[issue21422] int << 0: return the number unmodified

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue21083] Add get_content_disposition() to email.message.Message

R. David Murray added the comment: Looks good, thanks. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https

[issue21435] Segfault with cyclic reference and asyncio.Future

Tim Peters added the comment: finalize4.patch repairs the comment typos, adds a new comment, and removes the unused `old` argument. I think the code is ready to ship with this. I still don't have a reasonably simple fails-before-works-after test case. But that doesn't bother me much, sin

[issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument

Andreas van Cranenburgh added the comment: Here's a patch. I have added initializer and initargs keywords to both ThreadPoolExecutor and ProcessPoolExecutor, with the same semantics as multiprocessing.Pool. I couldn't figure out what to do if the initializer fails with a ProcessPoolExecutor:

[issue21435] Segfault with cyclic reference and asyncio.Future

Tim Peters added the comment: OK! This has nothing to do with the trashcan mechanism. The list object whose gc_next gets stomped on is not itself in a cycle. It's an empty list, and just happens to be a value in a dict, which in turn is a value in another dict. Its refcount falls to 0 as an

[issue21083] Add get_content_disposition() to email.message.Message

Abhilash Raj added the comment: I have updated the patch. The header with mime parameter 'filename' in addition to header value is already added, will that not be enough? -- Added file: http://bugs.python.org/file35178/c_d-revised.patch ___ Python tr

[issue21083] Add get_content_disposition() to email.message.Message

R. David Murray added the comment: Looks pretty good. The docs should say that the value of header is returned, and should also mentioned that the value is lower cased. You should also add a 'versionadded' directive, and for bonus points an entry in the whatsnew document for 3.5. Also, all

[issue17756] test_syntax_error fails when run in the installed location

Matthias Klose added the comment: adding unittest developers -- nosy: +ezio.melotti, michael.foord ___ Python tracker ___ ___ Python-b

[issue21264] test_compileall fails to build in the installed location

Matthias Klose added the comment: adding unittest developers -- nosy: +ezio.melotti, michael.foord ___ Python tracker ___ ___ Python-b

[issue21083] Add get_content_disposition() to email.message.Message

Abhilash Raj added the comment: I have attached my patch. Reviews? -- keywords: +patch Added file: http://bugs.python.org/file35177/c_d.patch ___ Python tracker ___ _

[issue17752] many distutils tests fail when run from the installed location

Matthias Klose added the comment: yes, noted myself (too late), and informed Georg about it. Closing for now. -- resolution: -> fixed status: open -> closed ___ Python tracker _

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Kristján Valur Jónsson added the comment: fix patch, was using git format -- Added file: http://bugs.python.org/file35176/condwait.patch ___ Python tracker ___ __

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Kristján Valur Jónsson added the comment: Here is a proposed alternative patch. No additional checks, just a wider "Py_LONG_LONG us" wide enough to accommodate 32 bits of milliseconds as before. -- Added file: http://bugs.python.org/file35175/condwait.patch

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Kristján Valur Jónsson added the comment: Ah, I saw this code here in thread_nt.h: if ((DWORD) milliseconds != milliseconds) Py_FatalError("Timeout too large for a DWORD, " "please check PY_TIMEOUT_MAX"); the PyCOND_TIMEDWAIT is currently only used by the

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Kristján Valur Jónsson added the comment: (cont.) so, I suggest that we modify the API to use "Py_LONG_LONG usec" Does that sound reasonable? -- ___ Python tracker ___ _

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

R. David Murray added the comment: I'm adding Mark Dickinson to nosy to see if our math expert has a comment on the arithmetic :) -- nosy: +mark.dickinson ___ Python tracker ___

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Kristján Valur Jónsson added the comment: Hi there. When I said "4000", that was because of the conversion to microseconds which happens early on. I'm not trying to be difficult here Tim, it's just that you've pointed out a problem and I'd like us to have a comprehensive fix. "unsigned long

[issue21083] Add get_content_disposition() to email.message.Message

R. David Murray added the comment: Yes, that would be great. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18854] is_multipart and walk should document their treatment of 'message' parts.

R. David Murray added the comment: Using _structure is a great idea. I'm not so fond of the full example, but I'll have to contemplate the text to decide what I'd rather do. Probably I'll take this patch of yours and tweak it, rather than try to tell you what I want :) Thanks for the patch!

[issue21083] Add get_content_disposition() to email.message.Message

Abhilash Raj added the comment: I read the discussion on issue #21079. Does this issue still needs a patch? If yes I am willing to write one. -- nosy: +abhilash.raj ___ Python tracker _

[issue18854] is_multipart and walk should document their treatment of 'message' parts.

Abhilash Raj added the comment: Sorry, my bad. I was a little confused. I have updated the patch and also added the example explicitly. -- Added file: http://bugs.python.org/file35174/email-1.patch ___ Python tracker

[issue21435] Segfault with cyclic reference and asyncio.Future

Tim Peters added the comment: Antoine, the carets are a symptom of my flu. My fingers jump on the keyboard from sneezing and coughing, and my eyes are watery so I don't see the typos. But I believe that can be fixed ;-) I doubt the trashcan cruft is responsible, for several reasons: I doubt

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Tim Golden added the comment: Updated patch with unsigned long applied throughout -- Added file: http://bugs.python.org/file35173/issue20737.condvar.2.patch ___ Python tracker __

[issue18854] is_multipart and walk should document their treatment of 'message' parts.

R. David Murray added the comment: Take a look at the source for msg_16.txt. The last part is a message/rfc822, which encapsulates a text/plain message. So it *does* iterate over it, even though it isn't a 'multipart' type (the opposite of what you say in the doc patch). Explicitly pointing

[issue21451] Improve error messages for malformed JSON

R. David Murray added the comment: Hmm. I guess I don't have any objection in principle. It is hard to imagine why someone would depend on the exact format of the old low-information messages, though anything is possible. -- ___ Python tracker

[issue18854] is_multipart and walk should document their treatment of 'message' parts.

Abhilash Raj added the comment: I have tried to document the issue in the patch as discussed. David: Do you think I should also add an example in walk() method to demonstrate that it does not iterate over a 'message/rfc822' part even though it is multipart? -- keywords: +patch nosy: +ab

[issue17752] many distutils tests fail when run from the installed location

Éric Araujo added the comment: For future fixes, please note that 3.3 is in security mode. Can this issue be closed? -- ___ Python tracker ___ __

[issue21451] Improve error messages for malformed JSON

Raymond Hettinger added the comment: What do you think about backporting the improved error messages? -- ___ Python tracker ___ ___ Py

[issue21451] Improve error messages for malformed JSON

R. David Murray added the comment: Python 3.4.0+ (3.4:d994d75cce95, May 6 2014, 21:37:02) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> json.loads('''[ ... "boys": 10, ... "girls": 20, ... ]''') Trace

[issue18492] Allow all resources if not running under regrtest.py

Zachary Ware added the comment: Here's a new and better patch. This patch keeps the regrtest_run global in support and moves the regrtest-or-not check into is_resource_enabled to make is_resource_enabled, requires, and requires_resource consistent with each other and in a way that still allow

[issue19643] shutil rmtree fails on readonly files in Windows

Changes by Tim Golden : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker ___ ___ Py

[issue19643] shutil rmtree fails on readonly files in Windows

Roundup Robot added the comment: New changeset 31d63ea5dffa by Tim Golden in branch 'default': Issue19643 Add an example of shutil.rmtree which shows how to cope with readonly files on Windows http://hg.python.org/cpython/rev/31d63ea5dffa New changeset a7560c8f38ee by Tim Golden in branch 'defa

[issue21451] Improve error messages for malformed JSON

New submission from Raymond Hettinger: The error message for malformed JSON just tells you that the JSON is invalid, it doesn't say why (showing you which character bombed, what text is being read, what the pending openers are, or what allowable characters would have been expected). In the ab

[issue21350] bug in file.writelines accepting buffers

Brian Kearns added the comment: So, for example: >>> f = open('blah', 'wb') >>> f.write(array.array('c', 'test')) >>> f.writelines([array.array('c', 'test')]) Traceback (most recent call last): File "", line 1, in TypeError: writelines() argument must be a sequence of strings While the commen

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Tim Golden added the comment: Just to be clear: the change *I'm* proposing for this issue has nothing to do with limiting the wait, artificially or otherwise. It's simply undoing an unintended conversion from unsigned to signed and back again, whicih currently causes any wait of more than 2147

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

R. David Murray added the comment: I have production code on Windows using python2.7 that calls Event().wait() with a timeout of approximately 24 hours, and it works just fine. Having that no longer work is, IMO, an unacceptable regression. (I'm ready to move this code to python3 as soon as

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Kristján Valur Jónsson added the comment: Tim, how about changing the variable to "unsigned long"? I'd like the signature of the function to be the same for all platforms. This will change the code and allow waits for up to 4000 seconds. There is still an overflow problem present, though.+ D

[issue21450] [Issue 13630] IDLE: Find(ed) text is not highlighted while dialog box is open

Changes by Berker Peksag : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> IDLE: Find(ed) text is not highlighted while dialog box is open ___ Python tracker

[issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open

Changes by Berker Peksag : -- nosy: +fgracia ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue21450] [Issue 13630] IDLE: Find(ed) text is not highlighted while dialog box is open

New submission from Francisco Gracia: I was delighted with the behaviour of IDLE in version 3.4 until I noticed the problem of the matches with the non highlighted background in the modified (and in this sense improved) iterative text search operations. I was wondering how could this be possible

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

R. David Murray added the comment: An implicit ceiling of 4000 seconds on the timeout? I routinely use timeouts of approximately 24 hours in calls to Event().wait(). What am I misunderstanding? If I'm not misunderstanding, then no, I don't think that change would be acceptable. --

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Tim Golden added the comment: Thanks for the feedback, Kristjan. You're obviously correct in that we can't account for timeouts greater than DWORD-size milliseconds and your proposed solution looks reasonable. However, I'd like to close off *this* particular issue which turns on the implicit and

[issue19643] shutil rmtree fails on readonly files in Windows

Tim Golden added the comment: Thanks. I'll hold off pushing until I've had a chance to run it on a Unix system. I'm not 100% whether it will operate in the same way there. -- ___ Python tracker

[issue19643] shutil rmtree fails on readonly files in Windows

Zachary Ware added the comment: LGTM! -- stage: -> commit review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue19643] shutil rmtree fails on readonly files in Windows

Tim Golden added the comment: Thanks, Zach. Updated patch. -- assignee: -> tim.golden Added file: http://bugs.python.org/file35170/issue19643-doc.2.patch ___ Python tracker ___

[issue19643] shutil rmtree fails on readonly files in Windows

Zachary Ware added the comment: Fair point, Paul. Patch looks good to me, Tim, barring a couple of nits pointed out on Rietveld. -- ___ Python tracker ___ __

[issue21428] Python suddenly cares about EOLs formats on windows

Eric V. Smith added the comment: Can you describe what command you ran and what you saw at the "executing with python-3.4.0 make the execution stop" step? -- nosy: +eric.smith ___ Python tracker __

[issue21447] Intermittent asyncio.open_connection / futures.InvalidStateError

Changes by Andrew Svetlov : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue13702] relative symlinks in tarfile.extract broken (windows)

Tim Golden added the comment: eryksun: could you essay a patch? I'd be happy to review & apply it. -- nosy: +tim.golden ___ Python tracker ___ ___

[issue17752] many distutils tests fail when run from the installed location

Roundup Robot added the comment: New changeset 7d1929cc08dd by doko in branch '3.3': - Issue #17752: Fix distutils tests when run from the installed location. http://hg.python.org/cpython/rev/7d1929cc08dd New changeset 01e933cb1de9 by doko in branch '3.4': - Issue #17752: Fix distutils tests whe

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Kristján Valur Jónsson added the comment: changing long to DWORD doesn't really fix the overflow issue. The fundamental problem is that some of the apis, e.g. WaitForSingleObject have a DWORD maximum. so, we cannot support sleep times longer than some particular time. Microseconds was chosen

[issue21411] Enable Treat Warning as Error on 32-bit Windows

Tim Golden added the comment: I'm at least +0.5 on this: I rather like the idea of forcing these things out into the open. The reason I'm not +1 is the danger of relatively benign or trivial warnings-turned-errors getting in the way of real, possibly critical, development. -- __

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Changes by Tim Golden : -- stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows

Tim Golden added the comment: The attached patch uses DWORD (essentially: unsigned long) in condvar.h:PyCOND_TIMEDWAIT. Adding Kristjan as it was his code. -- keywords: +patch nosy: +kristjan.jonsson Added file: http://bugs.python.org/file35169/issue20737.condvar.patch ___

[issue19643] shutil rmtree fails on readonly files in Windows

Changes by Tim Golden : -- keywords: +patch Added file: http://bugs.python.org/file35168/issue19643-doc.patch ___ Python tracker ___ _

[issue19643] shutil rmtree fails on readonly files in Windows

Tim Golden added the comment: The attached patch adds an example to the shutil documentation showing how to use an onerror handler to reattempt the removal of a read-only file. It's deliberately low-tech and simply removes the attribute and retries. If there's some other obstacle, it will cont

[issue21435] Segfault with cyclic reference and asyncio.Future

Antoine Pitrou added the comment: Larry, once this patch is finalized, I think it is a good candidate for 3.4.1. -- nosy: +larry ___ Python tracker ___ __

[issue21435] Segfault with cyclic reference and asyncio.Future

Antoine Pitrou added the comment: > The new info: its (the list object's) gc_refs also changed from > GC_TENTATIVELY_UNREACHABLE to GC_UNTRACKED, That the object became > untracked is wholly consistent with that its gc_next became NULL but > not its gc_prev. Could that be the trashcan mecanism

[issue21435] Segfault with cyclic reference and asyncio.Future

Antoine Pitrou added the comment: Tim's analysis is spot on, and finalize3.patch looks good to me (there's some strange commenting style there - do the carets "^" mean something special?). Still, I hope we can find a way to write a test case. -- ___

[issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument

Mark Dickinson added the comment: BTW, I think there's a design mistake in the EnhancedThreadPoolExecutor that's worth avoiding in any std. lib. implementation: the initialiser and uninitialiser for the EnhancedThreadPoolExecutor accept no arguments. In retrospect, it would have been better to