Tim Peters added the comment:
Seeing as Python 3 _does_ open these files in binary mode, I fiddled my local
.hgeol to mark the test files as BIN (then deleted the test data directory and
did an "hg revert" on the directory). Then test_sax passes.
I don't know whether that&#
Tim Peters added the comment:
test_email still passed on Windows under 3.2.5 (but test_sax failed).
test_email and test_sax both fail under 3.3.2.
I'll just push the change to .hgeol - minimally invasive, fixes the immediate
problem, and it appears these "really are&quo
Changes by Tim Peters :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Peters added the comment:
Terry, yes, the installer won't change line endings. I think - we'll find out
for sure next time a release is cut - LOL ;-)
Agreed that Lib/email/test/data/msg_26.txt is probably obsolete. Fix it, if
you like! It's helpful to get rid of
Tim Peters added the comment:
I'm closing this. While it makes a big difference for a cwr coded in Python,
it turn out to be minor in C. The extra complications (more state to remember
and update across next() invocations) isn't worth the minor speedup in C.
--
New submission from Tim Peters:
Here under 3.3.2:
"""
>>> from threading import Lock
>>> help(Lock)
Help on built-in function allocate_lock in module _thread:
allocate_lock(...)
allocate_lock() -> lock object
(allocate() is an obsolete synonym)
Tim Peters added the comment:
Oh, I'm not opposed, I'm just complaining ;-)
It would be much nicer to have an approach that worked for all thread users,
not just threading.Thread users. For example, a user can easily (well,
plausibly) get into the same kinds of troubles here
New submission from Tim Peters:
Here from the 3.3.2 docs for threading.Lock:
"""
acquire(blocking=True, timeout=-1)
Acquire a lock, blocking or non-blocking.
...
When invoked with the floating-point timeout argument set to a positive value,
block for at most the number of se
Tim Peters added the comment:
Oops! The docs are wrong - a negative timeout actually raises:
ValueError: timeout value must be strictly positive
unless the timeout is exactly -1. All the more reason to ensure that a
negative waittime isn't passed.
I opened a different issue about th
Tim Peters added the comment:
I think the docs are already clear: they say "the generator-iterator’s close()
method will be called". That's all that needs to be said: now go look at the
docs for generator.close(). They explain _all_ that close() does, and it would
b
Tim Peters added the comment:
Fudge - there's another unlikely problem here. For example: main program
creates a threading.Thread t, runs it, and does t.join(5) (whatever - any
timeout value). When t.join() returns, the main program has no idea whether t
is done or not. Suppose t
Tim Peters added the comment:
When the comment was introduced, Python's Wichmann-Hill generator had a much
shorter period, and we couldn't even generate all the permutations of a deck of
cards.
The period is astronomically larger now, but the stackoverflow answer (2080) is
corre
Changes by Tim Peters :
--
resolution: -> invalid
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue18928>
___
___
Python-bugs-
Tim Peters added the comment:
So you're not concerned about a now-private API (which used to be advertised),
but are concerned about a user mucking with a new private lock in an
exceedingly unlikely (in the absence of malice) way. That clarifies things ;-)
I'm not really conce
New submission from Tim Peters:
On Windows, _debugmallocstats() output ends with lines like this:
0 free 12-sized PyTupleObjects * zd bytes each =0
0 free 13-sized PyTupleObjects * zd bytes each =0
"zd" is senseless. Betting it's due
Changes by Tim Peters :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Tim Peters :
--
components: +Tests -Interpreter Core
___
Python tracker
<http://bugs.python.org/issue18944>
___
___
Python-bugs-list mailing list
Unsub
Changes by Tim Peters :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Peters added the comment:
The fix is obviously correct ;-) - so what next? Armin & Terry, I don't know
whether you have commit privileges. If you don't, assign it to me and I'll
commit it.
Removed 3.5 from the Versions list and added 3.3 and 3.4.
--
nosy: +
Tim Peters added the comment:
All the timeout args are great! I wish Python had always had them :-)
Back to the pain at hand, it's not the number of lines of code that rubs me the
wrong way, but the sheer obscurity of it all. This handful of lines is - of
necessity - sprayed across
Tim Peters added the comment:
Right, I should have asked specifically about cpython commit privs ;-) Thanks
for expounding!
--
___
Python tracker
<http://bugs.python.org/issue18
Tim Peters added the comment:
New patch (threadstate_join_4.patch) refactors so that is_alive() returns True
until the tstate is cleared. This simplifies join() a lot (it doesn't have to
roll its own timeout implementation anymore), but complicates is_alive().
Caution: I don't kno
Tim Peters added the comment:
New patch threadstate_join_5.patch adds more testing of is_alive().
An inelegance I don't care about (but someone might): if join() is called with
a timeout, and the Python part of the thread ends before the timeout expires
(_stopped gets set), then a
Tim Peters added the comment:
Ah! I'm running on Windows, where all fork() tests are skipped. Can you fix
it? My prejudice is that anyone mixing threads with fork() should be shot for
the good of humanity <0.7 wink>.
--
___
Python tra
Tim Peters added the comment:
Cool! What could possibly go wrong? ;-)
--
___
Python tracker
<http://bugs.python.org/issue18808>
___
___
Python-bugs-list mailin
Tim Peters added the comment:
If would be nice if Tamas could test it in his application, since we're not
actually testing Py_EndInterpreter. But, ya, commit it! If it doesn't work
for Tamas, we can start over again ;-)
--
___
Pyth
Tim Peters added the comment:
Excellent - ship it! :-)
--
___
Python tracker
<http://bugs.python.org/issue18808>
___
___
Python-bugs-list mailing list
Unsub
Tim Peters added the comment:
Figures. That's why I wanted your name on the blamelist ;-)
--
___
Python tracker
<http://bugs.python.org/issue18808>
___
___
Tim Peters added the comment:
Just pushed 5cfd7b2eb994 in a poke-and-hope blind attempt to repair the
annoying ;-) buildbot failures.
--
___
Python tracker
<http://bugs.python.org/issue18
Tim Peters added the comment:
Doesn't look like 5cfd7b2eb994 is going to fix it :-( So I'll revert it.
Attaching the patch as blind.patch. After that patch, is_alive() only looks at
Thread data members, where ._is_stopped "is obviously" True, and ._tstate_lock
"
Tim Peters added the comment:
Weird! The Ubuntu box passed test_is_alive_after_fork on its /second/ run with
the patch:
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/8564/steps/test/logs/stdio
The other box passed all tests:
http://buildbot.python.org/all
Tim Peters added the comment:
Well, the next time the Ubuntu box ran the tests, it was clean all the way. So
it's fixed! Despite that it isn't ;-)
--
___
Python tracker
<http://bugs.python.o
Tim Peters added the comment:
[Antoine]
> Oh, I also get the following sporadic failure
> which is triggered by slight change in semantics
> with Thread.join(timeout) :-)
> ==
> FAIL: t
Tim Peters added the comment:
Ah - the test used to do t.join(NUMTASKS)! That's just bizarre ;-)
I believe I can repair that too (well - there was never a _guarantee_ that
waiting 10 seconds would be long enough), but I'll wait until this all settles
down.
join() and is_alive
Tim Peters added the comment:
Without _stopped, join() can simply wait to acquire _tstate_lock (with or
without a timeout, and skipping this if _tstate_lock is already None). Etc ;-)
Of course details matter, but it's easy. I did it once, but the tests joining
the main thread failed
Tim Peters added the comment:
-1 from me, and I'm a comma-loving American ;-)
I'm sure lots of code in the wild parses this output - Serhiy isn't the only
one doing it.
--
___
Python tracker
<http://bugs.pyt
Tim Peters added the comment:
> The MainThread class could override is_alive() and join(), then.
I think it will be easier than that, but we'll see ;-)
--
___
Python tracker
<http://bugs.python.org
New submission from Tim Peters:
As discussed in issue 18808, now that we're checking for a tstate lock, the
Thread._stopped Event has become an "attractive nuisance". The attached patch
removes it.
This simplifies .join() and .is_alive(), and restores pre-18808 .join(ti
Changes by Tim Peters :
--
dependencies: +Thread.join returns before PyThreadState is destroyed
___
Python tracker
<http://bugs.python.org/issue18984>
___
___
Tim Peters added the comment:
I agree with your diagnosis. Unfortunately, I can't test the fork stuff.
Well, OK, I actually think that's fortunate (for me ;-) ).
If you can see a quick way to fix these, please do. I'm going to vanish for
ab
Tim Peters added the comment:
Thanks, Antoine! I pushed this change, figuring that even if some buildbots
are still unhappy about 18808, getting rid of the Event can't make them more
unhappy, and may make them happier.
--
resolution: -&g
Changes by Tim Peters :
--
Removed message: http://bugs.python.org/msg197342
___
Python tracker
<http://bugs.python.org/issue18984>
___
___
Python-bugs-list mailin
Tim Peters added the comment:
New changeset aff959a3ba13 by Tim Peters in branch 'default':
Issue 18984: Remove ._stopped Event from Thread internals.
http://hg.python.org/cpython/rev/aff959a3ba13
--
___
Python tracker
<http://bu
Tim Peters added the comment:
Antoine, could I bother you to try the attached cleanup.patch? It looks
harmless to me, but when I checked it in the Unix-y buildbots failed the
thread+fork tests again :-( Two examples:
http://buildbot.python.org/all/builders/x86%20Gentoo%203.x/builds/4914
Changes by Tim Peters :
--
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue18808>
___
___
Tim Peters added the comment:
Yes - and I just closed 18808 :-)
--
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Tim Peters added the comment:
Well - I remain baffled, but am grateful for the patch - thanks :-)
--
___
Python tracker
<http://bugs.python.org/issue18
New submission from Tim Peters:
Don't know whether this is new. Found it running the test suite under a
3.4.0a2 freshly installed from the python.org .msi installer:
== CPython 3.4.0a2 (v3.4.0a2:9265a2168e2c+, Sep 8 2013, 19:41:05) [MSC v.1600
32 bit (Intel)]
== Windows-Vista-6.0.600
Tim Peters added the comment:
Serhiy, did you test "hg update -C default"? Didn't work for me :-(
Martin, I don't know an easy way. eol fiddling in Hg seems brittle :-(
I suppose you could get a fresh clone and then _compare_ the checked-out files
to your old clone.
Tim Peters added the comment:
OK, "hg up -C" _can_ work, but it appears to require that "hg stat" shows that
the files with the "bad" line endings are modified (M). That may or may not be
the case, depending on lots of things.
Martin, can you verify that (for e
Tim Peters added the comment:
BTW, the reason I wonder whether you don't have bad line ends in your tree is
this: if you did, test_sax would have been failing for you too. I assume you
run the test suite before building the inst
Tim Peters added the comment:
No problems, Martin - thanks for following up on this! :-)
--
___
Python tracker
<http://bugs.python.org/issue18992>
___
___
Pytho
Tim Peters added the comment:
Matthew is right: the nested quantifiers can cause this to take a very long
time when the regexp doesn't match. Note that the example cannot match,
because nothing in the regexp can match the space before "warning" in the
example string.
Tim Peters added the comment:
Matthew, yes, PyPy's regex module implements regular expressions of the
"computer science" (as opposed to POSIX) sense. See Friedl's book for a full
explanation. Short course is that regex's flavor of regexp matching is
linear-time, but
Tim Peters added the comment:
+1. Note that this really can't be done in user-level code. For example,
consider matching the pattern
a|ab
against the string
ab
Without being _forced_ to consider the "ab" branch, the regexp will match just
the "a" branch. So, e
Tim Peters added the comment:
Antoine, that's certainly the conceptual intent here. Can't say whether your
attempt works in all cases. The docs don't guarantee it. For example, if the
original regexp started with (?x), the docs explicitly say the effect of (?x)
is undefine
Tim Peters added the comment:
Matthew, Guido wrote "check that the whole input string matches" (or slice if
pos and (possibly also) endpos is/are given). So, yes, \Z is more to the point
than $ if people want to continue wasting time trying to implement this as a
Python-level funct
Tim Peters added the comment:
Serhiy, I expect this is easy to implement _inside_ the regexp engine. The
complications come from trying to do it outside the engine. But even there,
wrapping the original regexp in
(?:)\Z
is at worst very close. The only insecurity with that I've th
Tim Peters added the comment:
I like "matchall" fine, but I can't channel Guido on names - he sometimes gets
those wrong ;-)
--
___
Python tracker
<http://bugs.pyt
Tim Peters added the comment:
In the absence of Guido here, I'll channel him ;-) "The problem" with oddball
platforms has been that some require major changes in many parts of the
interpreter, and then all the added cruft complicates life for every
maintainer, while few peo
Tim Peters added the comment:
The first footnote in the docs explain this:
Examples containing both expected output and an
exception are not supported. Trying to guess where
one ends and the other begins is too error-prone,
and that also makes for a confusing test.
So, sorry
Tim Peters added the comment:
Steven, no objection here.
--
___
Python tracker
<http://bugs.python.org/issue21183>
___
___
Python-bugs-list mailing list
Unsub
Tim Peters added the comment:
Yup, agreed with all: ValueError makes a lot more sense, but the change
shouldn't be backported.
--
___
Python tracker
<http://bugs.python.org/is
Tim Peters added the comment:
Comparison can certainly trigger a recursion error if the sequences contain no
(or few) matching non-junk elements, but contain many "almost matching"
elements. If the sequences have lengths M and N, recursion can go as deep as
2*min(M, N) then.
Now i
Tim Peters added the comment:
I wonder whether this new function would attract any users, given that the user
already has control over the smallest ratio that will be accepted, and over the
maximum number of close matches returned. That's always been sufficient for me.
What useful th
Tim Peters added the comment:
Russell, I'm still looking for a sufficiently compelling "use case" here:
something tangible and useful that can be done with the new function that can't
be easily done now.
"I plan to write a web API that accepts a word, 'doge&#x
Tim Peters added the comment:
Just noting that, for me, the problem goes away if
del c, c2
is added as the last line of the test. This suggests the problem is due to
changes in end-of-life module cleanup.
Without that line, I see 3 kinds of output:
1.
del child
del child
del parent
parent
Changes by Tim Peters :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue21351>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
I think Antoine is right on all counts. The most surprising bit may be that p,
c, and c2 are in reference cycles, but - surprising or not - that's always been
true. The reason "it worked" before 3.4 is that CPython happened to break the
cycle
Tim Peters added the comment:
After more thought, I don't think the user can do anything to influence
finalization order in cases like this, short of adding "del" statements (or
moral equivalents) to break cycles before the interpreter shuts down.
Fine by me ;-) Something C
Tim Peters added the comment:
I don't see a way to test it either, but it's easy enough to prove it's correct
;-) That is, looks good to me!
--
nosy: +tim.peters
___
Python tracker
<http://bugs.pyt
Tim Peters added the comment:
There's no way to influence finalization order for objects in cycles, and there
never was. So nothing actually changed in that respect ;-) What did change is
that Python used to forcibly break many module-level cycles in a way that just
happened to resu
Tim Peters added the comment:
Guido, that's no good. The outer loop is traversing a doubly-linked circular
list, and it should be flatly impossible for gc to ever be NULL - the list
structure is insanely damaged if any gc_next or gc_prev field reachable from it
is NULL (gc always comes
Tim Peters added the comment:
Thought question: suppose finalize_garbage() is called with a collectable list
all of whose members are in fact going to be destroyed?
I don't see how the loop iteration logic could reliably work then. For
concreteness, suppose there's only object -
Tim Peters added the comment:
Noting that in a Windows debug build, at death gc is 0xdbdbdbdb, so we are in
reading up free'd memory (0xdb is pymalloc's "dead byte" marker).
--
___
Python tracker
<http://bug
Tim Peters added the comment:
Also noting that the loop "looks funny" because it appears never to process the
first element in the input list (unless the input list contains only one
element). That is, the loop starts by processing the second element in the
list, and exits as
Tim Peters added the comment:
Ah, fudge - I think I forgot that these circular lists also have dummy heads,
in which case it's A Good Thing "the first element" is skipped, and it should
be impossible for one to become physically empty (the dummy header should
always survive
Tim Peters added the comment:
Sorry for the earlier noise. I'm fighting a flu and my head is mush :-(
Anyway, this doesn't look obvious. We get to this point:
if (Py_REFCNT(op) == 1) {
/* op will be destroyed */
gc = gc-&
Tim Peters added the comment:
A bit more info: recall that, when deleting a type object (for class B), the
previous (list) object's gc_next got overwritten with NULL. The new info: its
(the list object's) gc_refs also changed from GC_TENTATIVELY_UNREACHABLE to
GC_UNTRACKED,
Tim Peters added the comment:
Attaching a marginally cleaner version of the patch, with comments.
I think it's clear this addresses _some_ real fatal problems, but they're rare:
for a problem to show up, it has to be the case that finalize() reduces the
refcount of the current o
Tim Peters added the comment:
Oh, fudge. There are other failure modes in the test suite after I took out
the seemingly redundant incref/decref pair. Adding it back in finalize3.patch.
--
Added file: http://bugs.python.org/file35167/finalize3.patch
Tim Peters added the comment:
Guido, it's best if Antoine reviewed it - he wrote the relevant PEP, and the
code I'm changing. I'm sure he'll agree it's a necessary change.
About the rarity of the bug, not only do the refcounts and cyclic structure
have to be just ri
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 reason
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
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 both
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
Changes by Tim Peters :
--
assignee: -> tim.peters
___
Python tracker
<http://bugs.python.org/issue21435>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Tim Peters :
--
title: Segfault with cyclic reference and asyncio.Future -> Segfault in gc with
cyclic trash
___
Python tracker
<http://bugs.python.org/issu
Tim Peters added the comment:
finalize42.patch includes a test case. If nobody objects within a few hours,
I'll commit it.
--
Added file: http://bugs.python.org/file35187/finalize42.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Tim Peters :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue21435>
___
Tim Peters added the comment:
@asvetlov, glad this fixes crashes in aiohttp library tests too, but I hadn't
heard about that before. Is there an open bug report about it on this tracker
(so we can close it)?
--
___
Python tracker
Tim Peters added the comment:
+1, although it could really use a comment explaining that 2500 bytes was
chosen to be >= the Twister's 19937 internal bits of state. Otherwise it looks
as arbitrary as 32 did ;-)
--
nosy: +tim.peters
__
Tim Peters added the comment:
[neologix]
> some code spawns many processes per second (see recent
> discussion on python-dev).
But that doesn't imply they're seeding the random module many times per second,
right? Seeding isn't part of Python initialization, it's part
Tim Peters added the comment:
[haypo]
> What is an uninteresting sequence? What are the problem of these
> sequences?
A sequence that would greatly surprise a user. For example, if you generate
32-bit ints from the Twister in one obvious way, there are starting places
where you'
Tim Peters added the comment:
[haypo]
> No user complained past years.
Raymond said "We've previously had this problem with MT (since resolved, where
it is was landed in a very non-random zone)." Do you believe he was wrong?
> I don't think that we should worry so m
Tim Peters added the comment:
[pitrou]
> I still find it difficult to understand where is the said danger.
The theoretical properties that make the Twister so attractive were all proved
based on mathematical analysis of its entire period. The only way to get at
the whole period is to al
Tim Peters added the comment:
> Thanks for the explanation. It's much clearer now.
Maybe, but it's also overblown - LOL ;-) That is, no matter what the starting
seed, the user will see a microscopically tiny span of the Twister's entire
period. So all those "prova
Tim Peters added the comment:
Crytpo generators are a whole different world, and I wouldn't listen to anyone
save a bona fide expert in that field. Plausible: the "hardest thing" OpenSSL
has to do is generate secure RSA keys. But the bit length of an RSA key can't
be
Tim Peters added the comment:
I suggest this needs a measurable goal, like "minimize expected-case time" or
"minimize worst-case time". "Use a state of the art implementation" isn't a
measurable goal - it's an abstract wish with no measurable mer
Tim Peters added the comment:
The gcd function is documented as taking two integer arguments:
"Return the greatest common divisor of the integers a and b."
I'm -0 on generalizing it, and also -0 on burning cycles to enforce the
restriction to integer arguments.
901 - 1000 of 1332 matches
Mail list logo
