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
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.
--
___
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?
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 rep...@bugs.python.org
http://bugs.python.org/issue21435
___
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
Changes by Tim Golden m...@timgolden.me.uk:
--
keywords: +patch
Added file: http://bugs.python.org/file35168/issue19643-doc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19643
___
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
Changes by Tim Golden m...@timgolden.me.uk:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20737
___
___
Python-bugs-list
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.
--
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
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
Tim Golden added the comment:
eryksun: could you essay a patch? I'd be happy to review apply it.
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13702
___
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21447
___
___
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 rep...@bugs.python.org
http://bugs.python.org/issue21428
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 rep...@bugs.python.org
http://bugs.python.org/issue19643
___
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 rep...@bugs.python.org
http://bugs.python.org/issue19643
Zachary Ware added the comment:
LGTM!
--
stage: - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19643
___
___
Python-bugs-list
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 rep...@bugs.python.org
http://bugs.python.org/issue19643
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
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.
--
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
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: +fgracia
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13630
___
___
Python-bugs-list
Changes by Berker Peksag berker.pek...@gmail.com:
--
resolution: - duplicate
stage: - resolved
status: open - closed
superseder: - IDLE: Find(ed) text is not highlighted while dialog box is open
___
Python tracker rep...@bugs.python.org
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.+
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
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
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 stdin, line 1, in module
TypeError: writelines() argument must be a sequence of strings
While the
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
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
Changes by Tim Golden m...@timgolden.me.uk:
--
resolution: - fixed
stage: commit review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19643
___
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
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,
... ]''')
Traceback (most recent
Raymond Hettinger added the comment:
What do you think about backporting the improved error messages?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21451
___
Éric Araujo added the comment:
For future fixes, please note that 3.3 is in security mode.
Can this issue be closed?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17752
___
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:
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
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
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 rep...@bugs.python.org
http://bugs.python.org/issue20737
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
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 rep...@bugs.python.org
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 rep...@bugs.python.org
http://bugs.python.org/issue21083
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
R. David Murray added the comment:
Yes, that would be great.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21083
___
___
Python-bugs-list
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,
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 rep...@bugs.python.org
http://bugs.python.org/issue20737
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 rep...@bugs.python.org
http://bugs.python.org/issue20737
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 GIL
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
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 rep...@bugs.python.org
http://bugs.python.org/issue20737
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 rep...@bugs.python.org
http://bugs.python.org/issue17752
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 rep...@bugs.python.org
http://bugs.python.org/issue21083
Matthias Klose added the comment:
adding unittest developers
--
nosy: +ezio.melotti, michael.foord
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21264
___
Matthias Klose added the comment:
adding unittest developers
--
nosy: +ezio.melotti, michael.foord
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17756
___
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
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
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
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:
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,
R. David Murray added the comment:
Looks good, thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21083
___
___
Python-bugs-list mailing
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21422
___
___
Python-bugs-list mailing list
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
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
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
63 matches
Mail list logo
