Tim Peters added the comment:
A simple (finalizer-only) example of what an SCC-based DAG topsort ordering
would accomplish:
import gc
class C:
def __init__(self, val):
self.val = val
def __del__(self):
print("finalizing", self.val)
Tim Peters added the comment:
This wasn't written with subclassing in mind to begin with. A class was just
an obvious way to allow advanced users to construct instances with their own
states (e.g., so they could build pseudo-independent generators for parallel
programming).
Tim Peters added the comment:
>> Making it easy to create subclasses was never a goal regardless.
> It's clearly advertised at the beginning of the documentation:
>
> "Class Random can also be subclassed if you want to use a
> different basic generator of your own
Tim Peters added the comment:
There is no possible world in which the best answer is "hack gcmodule.c" ;-)
I haven't tried to dig into the details here, but Pablo's approach looked
spot-on to me: put the solution near the source of the problem. The problem
is specific
Tim Peters added the comment:
Mark, you don't count ;-) Neither do I. Of course I've subclassed Random too,
to experiment with other base generators (including PCG variants). But they're
throwaways, and I don't care that it can require staring at the code to make
Tim Peters added the comment:
To be serious about numpy ;-) , people consuming a great many random outputs
will eventually move to numpy out of necessity (speed). So for that reason
alone it's good to mimic what they do. But more fundamentally, they have more
people with relevant
Tim Peters added the comment:
Sounds good to me, Lewis - thanks! Note, though, that alo and blo should
default to 0. `None` is best reserved for cases where the default value needs
to be computed at runtime. But alo == blo == 0 apply to all possible instances
Tim Peters added the comment:
I'm not clear on exactly what it is you're asking, but it's better to ask for
forgiveness than permission ;-) That is, it's unlikely anyone will object to
adding a test in a feature PR.
--
stage: -> needs patc
Tim Peters added the comment:
Just noting that the program runs to completion without issues under 3.8.1, but
on Win10. Of course Windows doesn't support fork().
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
New changeset 3209cbd99b6d65aa18b3beb124fac9c792b8993d by lrjball in branch
'master':
bpo-40394 - difflib.SequenceMatched.find_longest_match default args (GH-19742)
https://github.com/python/cpython/commit/3209cbd99b6d65aa18b3beb124fac9
Tim Peters added the comment:
All done. Thank you, Lewis! You're now an official Python contributor, and
are entitled to all the fame, fortune, and power that follows. Use your new
powers only for good :-)
--
resolution: -> fixed
stage: patch review -> resolved
s
Change by Tim Peters :
--
resolution: fixed -> not a bug
___
Python tracker
<https://bugs.python.org/issue40446>
___
___
Python-bugs-list mailing list
Un
Tim Peters added the comment:
"The 'aux' object" is simply the integer 1. The dict is irrelevant to the
outcome, except that the dict owns one reference to 1. Do
sys.getrefcount(1)
all by itself and you'll see much the same.
This isn't a bug, but
Tim Peters added the comment:
Note that doctest has the same kind of potential problem with matching ellipsis
(0 or more characters) in expected output blocks. Backtracking isn't needed at
all to resolve patterns of that limited kind, but I don't think Python's re
module
Tim Peters added the comment:
"The trick" with this kind of pattern is that a `*` should consume as little as
possible to allow the next fixed portion to match. Apply that at every stage,
and it succeeds or it doesn't. Backtracking can't change that outcome. For,
e.g
Tim Peters added the comment:
Changed version to 3.9, because anything done would change the regexp
generated, and fnmatch.translate()` makes that regexp visible.
--
stage: -> needs patch
versions: +Python 3.9 -Python 3.8
___
Python trac
Change by Tim Peters :
--
keywords: +patch
pull_requests: +19223
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19908
___
Python tracker
<https://bugs.python.org/issu
Tim Peters added the comment:
New changeset b9c46a2c2d7fc68457bff641f78932d66f5e5f59 by Tim Peters in branch
'master':
bpo-40480 "fnmatch" exponential execution time (GH-19908)
https://github.com/python/cpython/commit/b9c46a2c2d7fc68457bf
Change by Tim Peters :
--
assignee: -> tim.peters
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python
Tim Peters added the comment:
Thanks for the effort, but I'm rejecting this. The language deliberately
defines nothing about how these are calculated. It defines how `.ratio()` is
computed, but that's all. An implementation is free to do whatever it likes
for the "
Tim Peters added the comment:
Ned, would it be possible to rewrite code of the form:
if giant pasted regexp matches:
to:
if any(p matches for p in patterns):
That should work under any version of Python.
There's no guarantee that regexps _can_ be pasted together and still
Tim Peters added the comment:
I don't want something probabilistic. Fix it or don't ;-)
One thing that would work, but at the cost of non-determinism: do the same as
now, but obtain the number part of the group name by applying next() to a
module-global private instance of itert
Change by Tim Peters :
--
pull_requests: +19358
pull_request: https://github.com/python/cpython/pull/20049
___
Python tracker
<https://bugs.python.org/issue40
Tim Peters added the comment:
New changeset b1b4c790e7d3b5f4244450aefe3d8f01710c13f7 by Tim Peters in branch
'master':
bpo-40480: restore ability to join fnmatch.translate() results (GH-20049)
https://github.com/python/cpython/commit/b1b4c790e7d3b5f4244450aefe3d8f
Tim Peters added the comment:
Ned, I'm happy to do this. While the ability to join wasn't documented, it's
not an unreasonable expectation. I'm not sure it's possible to fail _unless_
the regexps use named groups (and/or numbered backreferences) - and nobody in
thei
Tim Peters added the comment:
Please ask for help on StackOverflow or the general Python mailing list. Your
understanding of the operations is incorrect.
"&" is NOT a logical operator ("and" is). It's a bitwise operator on integers.
>>> 10 & 10
10
&
Tim Peters added the comment:
It appears to be spam: the title is the single letter "I", and there's not a
single word of text. There was nothing sensible to be done _except_ to close it
:-)
--
nosy: +tim.peters
___
Python
Tim Peters added the comment:
Any principled change costs more than it's worth :-(
I'm mostly sympathetic with Guido's view, and have long advocated a new `imath`
module to hold the ever-growing number of functions that are really part of
integer combinatorics. But it&
Tim Peters added the comment:
Not a problem. Arguments to a function are evaluated before the function is
invoked. So in
self._finalizer = weakref.finalize(self, shutil.rmtree, self.name)
self.name is evaluated before weakref.finalize is called(). `self.name`
_extracts_ the `.name
Tim Peters added the comment:
I agree this doesn't occur in 3.10, but think Raymond pasted wrong outputs.
Here:
Python 3.10.0a4+ (heads/master:64fc105b2d, Jan 28 2021, 15:31:11)
[MSC v.1928 64 bit (AMD64)] on win32
>>> x = 0.6102683302836215
>>> y1 = 0.7906090004346
Tim Peters added the comment:
(len(moves) + 1) // 2
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue43255>
___
___
Python-bugs-list mailin
Tim Peters added the comment:
I'm very sorry for not keeping up with this - my health has been poor, and I
just haven't been able to make enough time.
Last time I looked to a non-trivial depth, I was quite happy, and just
quibbling about possible tradeoffs.
I can't honestly
Tim Peters added the comment:
New changeset 73a85c4e1da42db28e3de57c868d24a089b8d277 by Dennis Sweeney in
branch 'master':
bpo-41972: Use the two-way algorithm for string searching (GH-22904)
https://github.com/python/cpython/commit/73a85c4e1da42db28e3de57c868d24
Tim Peters added the comment:
This won't go anywhere without code (preferably minimal) we can run to
reproduce the complaint. If there were a "general principle" at work here,
someone else would surely have reported it over the last few decades ;-)
To the contrary, the comm
Tim Peters added the comment:
I agree with everyone ;-) That is, my _experience_ matches Mark's: as a
more-or-less "numeric expert", I use Fraction in cases where it's already fast
enough. Python isn't a CAS, and, e.g., in pure Python I'm not doing things like
Tim Peters added the comment:
Issue 21922 lists several concerns, and best I know they all still apply. As a
practical matter, I expect the vast bulk of core Python developers would reject
a change that sped large int basic arithmetic by a factor of a billion if it
slowed down basic
Tim Peters added the comment:
I see I never explicitly said +1, so I will now: +1 on merging this :-)
--
___
Python tracker
<https://bugs.python.org/issue29
Tim Peters added the comment:
`functools` is clearly a poor place for this. `imath` would also be.
`graph_stuff_probably_limited_to_a_topsort` is the only accurate name ;-)
Off-the-wall possibilities include `misclib` (stuff that just doesn't fit
anywhere else - yet) and `cslib` (Com
Tim Peters added the comment:
The repr truncates the pattern string, for display, if it's "too long". The
only visual clue about that, though, is that the display is missing the pattern
string's closing quote, as in the output you showed here. If you look at
url_pat.pat
Tim Peters added the comment:
Note that the relatively tiny pattern here extracts just a small piece of the
regexp in question. As the output shows, increase the length of a string it
fails to match by one character, and the time taken to fail approximately
doubles: exponential-time
Tim Peters added the comment:
Closing this as "Won't Fix", since the possibility of exponential-time behavior
with naively written nested quantifiers is well known, and there are no plans
to "do something" about that.
--
resolution: -> wont fix
stag
Tim Peters added the comment:
Read the PEP Serhiy already linked to:
https://www.python.org/dev/peps/pep-0238/
This was a deliberate change to how "integer / integer" works, introduced with
Python 3.
--
nosy: +tim.peters
status: open
Tim Peters added the comment:
Mike, read that exchange again. You originally wrote
"print(2 / 2) gives 2.0 instead of 2"
but you didn't _mean_ that. You meant to say it "gives 1.0 instead of 1", or
you meant something other than "2 / 2"). In Python 3,
Tim Peters added the comment:
I don't see real value in the docs noting that Bad Things can happen if code
lies about true refcounts. If a container points to an object, _of course_ the
container should own that reference. Cheating on that isn't intended to be
supported in a
Tim Peters added the comment:
For the first, your hardware's binary floating-point has no concept of
significant trailing zeroes. If you need such a thing, use Python's `decimal`
module instead, which does support a "significant trailing zero" concept. You
would need
Tim Peters added the comment:
I assumed Mark would tell us what's up with the arange() oddity, so let's see
whether he does. There is no truly good way to generate "evenly spaced" binary
floats using a non-representable conceptual decimal delta. The dumbass ;-)
Tim Peters added the comment:
Cool! So the only thing surprising to me here is just how far off balance the
arange() run was. So I'd like to keep this open long enough for Mark to
notice, just in case it's pointing to something fish
Tim Peters added the comment:
Thanks, Mark! I didn't even know __round__ had become a dunder method.
For the rest, I'll follow StackOverflow - I don't have an instant answer, and
the instant answers I _had_ didn't sur
Tim Peters added the comment:
Huh! I thought everyone in Standards World gave up by now, and agreed 0**0
should be 1.
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue41
Tim Peters added the comment:
Gregory, care to take their code and time it against Python?
I'm not inclined to: reading the comments in the code, they're trying "fast
paths" already described in papers by Clinger and - later - by Gay. When those
fast paths don't
Tim Peters added the comment:
Pro: focus on the "iterable" part of the title. If you want to, e.g., select 3
lines "at random" out of a multi-million-line text file, this kind of reservoir
sampling allows to do that holding no more than one line in memory
simultaneous
Tim Peters added the comment:
Thanks! That explanation really helps explain where "geometric distribution"
comes from. Although why it keeps taking k'th roots remains a mystery to me ;-)
Speaking of which, the two instances of
exp(log(random())/k)
are numerically suspect. Be
Tim Peters added the comment:
Julia's randsubseq() doesn't allow to specify the _size_ of the output desired.
It picks each input element independently with probability p, and the output
can be of any size from 0 through the input's size (with mean output length
p*length
Tim Peters added the comment:
The lack of exactness (and possibility of platform-dependent results,
including, e.g., when a single platform changes its math libraries) certainly
works against it.
But I think Raymond is more bothered by that there's no apparently _compelling_
use cas
Tim Peters added the comment:
I see no evidence of a bug here. To the contrary, the output proves that
__del__ methods are getting called all along. And if garbage weren't being
collected, after allocating a million objects each with its own megabyte string
object, memory use at th
Tim Peters added the comment:
What makes you think that? Your own output shows that the number of "Active"
objects does NOT monotonically increase across output lines. It goes up
sometimes, and down sometimes. Whether it goes up or down is entirely due to
accidents of when your
Tim Peters added the comment:
It's impossible for any implementation to know that cyclic trash _is_ trash
without, in some way, traversing the object graph. This is expensive, so
CPython (or any other language) does not incur that expense after every single
decref that leaves a non
Tim Peters added the comment:
Well, this isn't a help desk ;-) You may want instead to detail your problem
on, say, StackOverflow, or the general Python mailing list.
Please note that I don't know what your "problem" _is_: you haven't said. You
posted some numbers
Tim Peters added the comment:
I'm inclined to ignore this. No actual user has complained about this, and I
doubt any ever will: it's got to be rare as hen's teeth to use a parameter
outside of, say, [0.1, 10.0], in real life. The division error can't happen for
thos
Tim Peters added the comment:
BTW, if we have to "do something", how about changing
return 1.0 / u ** (1.0/alpha)
to the mathematically equivalent
return (1.0 / u) ** (1.0/alpha)
? Not sure about Linux-y boxes, but on Windows that would raise OverflowError
instead of ZeroDiv
Tim Peters added the comment:
I'm not clear on that the alias method is valuable here. Because of the
preprocessing expense, it cries out for a class instead: an object that can
retain the preprocessed tables, be saved to disk (pickled), restored later, and
used repeatedly to mak
Tim Peters added the comment:
Oh yes - I understood the intent of the code. It's as good an approach to
living with floating-point slop in this context as I've seen. It's not
obviously broken. But neither is it obviously correct, and after a few minutes
I didn't
Tim Peters added the comment:
That text is fine, if you feel something needs to be said at all. I really
don't. A Pareto distribution of this kind with parameter <= 1.0 has infinite
expected value - VERY long tail. Anyone who knows what they're doing already
knows that. T
Tim Peters added the comment:
I'm skeptical of the need for - and wisdom of - this. Where does it come up? I
can't think of any context where this would have been useful, or of any other
language or package that does something like this. Long chains of mults are
unusual outside
Tim Peters added the comment:
See "wisdom" earlier ;-) It's ad hoc trickery that seemingly can't be explained
without showing the precise implementation in use today. As already mentioned,
frexp() trickery _can_ be explained: exactly what you'd get if left-to-righ
Tim Peters added the comment:
Cool! So looks like you could also address an accuracy (not out-of-range)
thing the frexp() method also does as well as possible: loosen the definition
of "underflow" to include losing bits to subnormal products. For example, with
the inputs
>&g
Tim Peters added the comment:
I may well have misread the code, believing it can still allow spurious
over/underflows. On second reading of the current file, I don't know - it's
more complicated than I thought.
If it does guarantee to prevent them, then I shift from -1 to (pro
Tim Peters added the comment:
"Denormal" and "subnormal" mean the same thing. The former is probably still in
more common use, but all the relevant standards moved to "subnormal" some years
ago.
Long chains of floating mults can lose precision too, but hardly
Tim Peters added the comment:
Well, that can't work: the most likely result for a long input is 0.0 (try
it!). frexp() forces the mantissa into range [0.5, 1.0). Multiply N of those,
and the result _can_ be as small as 2**-N. So, as in Mark's code, every
thousand times (2
Tim Peters added the comment:
More extensive testing convinces me that pairing multiplication is no real help
at all - the error distributions appear statistically indistinguishable from
left-to-right multiplication.
I believe this has to do with the "condition numbers" of fp ad
Tim Peters added the comment:
Or, like I did, they succumbed to an untested "seemingly plausible" illusion ;-)
I generated 1,000 random vectors (in [0.0, 10.0)) of length 100, and for each
generated 10,000 permutations. So that's 10 million 100-element products
overall.
Tim Peters added the comment:
Cute: for any number of arguments, try computing h**2, then one at a time
subtract a**2 (an argument squared) in descending order of magnitude. Call
that (h**2 - a1**2 - a2**2 - ...) x.
Then
h -= x/(2*h)
That should reduce errors too, although not nearly
Tim Peters added the comment:
> ...
> one at a time subtract a**2 (an argument squared) in descending
> order of magnitude
> ...
But that doesn't really help unless the sum of squares was computed without
care to begin with. Can do as well by skipping that but instead comput
Tim Peters added the comment:
Oh no - I wouldn't use this as a default implementation. Too expensive. There
is one aspect you may find especially attractive, though: unlike even the
Decimal approach, it should be 100% insensitive to argument order (no info is
lost before fsum() is c
Tim Peters added the comment:
I suspect you're reading some specific technical meaning into the word "block"
that the PR and release note didn't intend by their informal use of the word.
But I'm unclear on what technical meaning you have in mind.
Before the change
Tim Peters added the comment:
About speed, the fsum() version I posted ran about twice as fast as the
all-Decimal approach, but the add_on() version runs a little slower than
all-Decimal. I assume that's because fsum() is coded in C while the add_on()
prototype makes mounds of addit
Tim Peters added the comment:
Here's a "correct rounding" fail for the add_on approach:
xs = [16.004] * 9
decimal result = 48.01065814103642
which rounds to float 48.014
add_on result: 48.01
That's about 0.500
Tim Peters added the comment:
> That's about 0.50026 ulp too small - shocking ;-)
Actually, that's an illusion due to the limited precision of Decimal. The
rounded result is exactly 1/2 ulp away from the infinitely precise result -
it's a nearest/even tie case.
Tim Peters added the comment:
Here's an amusing cautionary tale: when looking at correct-rounding failures
for the fsum approach, I was baffled until I realized it was actually the
_decimal_ method that was failing. Simplest example I have is 9 instances of
b=4.999, which
Tim Peters added the comment:
There's no evidence of a Python issue here, so I recommend closing this. It's
not the Python bug tracker's job to try to make sense of platform-specific
reporting tools, which, as already explained, can display exceedingly confusing
numbers.
Tim Peters added the comment:
Just FYI, if the "differential correction" step seems obscure to anyone, here's
some insight, following a chain of mathematical equivalent respellings:
result + x / (2 * result) =
result + (sumsq - result**2) / (2 * result) =
result + (su
Tim Peters added the comment:
My apologies if nobody cares about this ;-) I just think it's helpful if we all
understand what really helps here.
> Pretty much the whole trick relies on computing
> "sumsq - result**2" to greater than basic machine
> precision.
But
Tim Peters added the comment:
> won't have a chance to work through it for a week or so
These have been much more in the way of FYI glosses. There's no "suggestion"
here to be pursued - just trying to get a deeper understanding of code already
written :-)
While I ca
Tim Peters added the comment:
Do it! It's elegant and practical :-)
--
___
Python tracker
<https://bugs.python.org/issue41513>
___
___
Python-bugs-list m
Tim Peters added the comment:
One more implication: since the quality of the initial square root doesn't
really much matter, instead of
result = sqrt(to_float(parts))
a, b = split(result)
parts = add_on(-a*a, parts)
parts = add_on(-2.0*a*b, parts)
parts = add_on
New submission from Tim Peters :
This started on StackOverflow:
https://stackoverflow.com/questions/63623651/how-to-properly-share-manager-dict-between-processes
Here's a simpler program.
Short course: an object of a subclass of mp.Process has an attribute of
seemingly any type obt
Tim Peters added the comment:
Weird. If I insert these between the two process starts:
import time
time.sleep(2)
then the producer produces the expected output:
at start: 666
at producer start: 666
and the program blows up instead when it gets to
print("in con
Tim Peters added the comment:
And more weirdness, changing the tail to:
for i in range(10):
state_value.value = i
state_ready.clear()
producerprocess = MyProducer(state_value, state_ready)
consumerprocess = MyConsumer(state_value, state_ready
Tim Peters added the comment:
Noting that adding a `.join()` to the failing code on the StackOverflow report
appeared to fix that problem too.
In hindsight, I guess I'm only mildly surprised that letting the main process
run full speed into interpreter shutdown code while worker proc
Tim Peters added the comment:
About test_frac.py, I changed the main loop like so:
got = [float(expected)] # NEW
for hypot in hypots:
actual = hypot(*coords)
got.append(float(actual)) # NEW
err = (actual - expected
Tim Peters added the comment:
Closing, since it remains a unique report and there hasn't been another word
about it in over a year.
--
resolution: -> works for me
stage: -> resolved
status: pending -> closed
___
Python t
Tim Peters added the comment:
The docs are already clear about that you play with `setrecursionlimit()` at
your own risk:
"""
Set the maximum depth of the Python interpreter stack to limit. This limit
prevents infinite recursion from causing an overflow of the C stack and
Tim Peters added the comment:
There is no way in portable ANSI C to deduce a "safe" limit. The limits that
exist were picked by hand across platforms, to be conservative guesses at what
would "never" break.
You're allowed to increase the limit if you think you know
Tim Peters added the comment:
Right, generators played no essential role here. Just one way of piling up a
tall tower of C stack frames.
Search the web for "stackless Python" for the history of attempts to divorce
the CPython implementation from the platform C stack.
There a
Tim Peters added the comment:
"Stackless" is a large topic with a convoluted history. Do the web search. In
short, no, it will never go in the core - too disruptive to too many things.
Parts have lived on in other ways, watered down versions. The PyPy project
captured most of wh
Tim Peters added the comment:
I believe your testing code is in error, perhaps because it's so overly
elaborate you've lost track of what it's doing. Here's a straightforward test
program:
import difflib
s1='http://local:56067/register/200930162135700"
Tim Peters added the comment:
Also reproduced on 64-bit Win10 with just-released 3.9.0.
Note that string search tries to incorporate a number of tricks (pieces of
Boyer-Moore, Sunday, etc) to speed searches. The "skip tables" here are
probably computing a 0 by mistake. The
Tim Peters added the comment:
Good sleuthing, Dennis! Yes, Fredrik was not willing to add "potentially
expensive" (in time or in space) tricks:
http://effbot.org/zone/stringlib.htm
So worst-case time is proportional to the product of the arguments' lengths,
and the cases
Tim Peters added the comment:
Just FYI, the original test program did get the right answer for the second
search on my box - after about 3 1/2 hours :-)
--
___
Python tracker
<https://bugs.python.org/issue41
Tim Peters added the comment:
BTW, this initialization in the FASTSEARCH code appears to me to be a mistake:
skip = mlast - 1;
That's "mistake" in the sense of "not quite what was intended, and so
confusing", not in the sense of "leads to a wrong result
401 - 500 of 1332 matches
Mail list logo
