Tim Peters added the comment:
+1 "in theory". But I too don't know whether any platforms would be adversely
affected, or how to find out :-(
--
nosy: +tim.peters
___
Python tracker
<https://bugs.pyt
Tim Peters added the comment:
Stefan, thanks - I think I understand what you're driving at now.
You're (re)discovering that sorting by lexicographic ordering rules is
_inherently_ suboptimal if list elements can only be compared "starting at
index 0" each time. Not j
Tim Peters added the comment:
To be concrete, here's an implementation of a full-blown, stable lexicographic
sort based on "bucket refinement". `xs` is a list of sequences to be sorted in
lexicographic order. The types of the sequences don't matter (lists, tuples,
s
Tim Peters added the comment:
New changeset 51ed2c56a1852cd6b09c85ba81312dc9782772ce by Tim Peters in branch
'main':
bpo-45530: speed listobject.c's unsafe_tuple_compare() (GH-29076)
https://github.com/python/cpython/commit/51ed2c56a1852cd6b09c85ba8
Change by Tim Peters :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Tim Peters :
A number of contexts allow specifying a tuple of arguments to be passed later
to a function. The Thread constructor is a fine example, and happened to come
up (again! for me) here today:
https://stackoverflow.com/questions/69858950/why-do-we-have-to-add-comma
Change by Tim Peters :
--
title: Promise that the long-time truth that `args=list` works -> Promise the
long-time truth that `args=list` works
___
Python tracker
<https://bugs.python.org/issu
Tim Peters added the comment:
Serhiy, we haven't documented such stuff, and, indeed, I've been burned by it
but much more often in the case of multiprocessing.Process. But note that I'm
SWAPPING the order of your last two lines. In the original, you mutated the
argument _b
Tim Peters added the comment:
Changed stage back to "needs patch", since Raymond appears to have closed his
PR. Raymond, what's up with that?
--
stage: patch review -> needs patch
___
Python tracker
<https://bugs.
Tim Peters added the comment:
Note that, on Windows, ldexp() in the presence of denorms can truncate.
Division rounds, so
assert x / 2**i == ldexp(x, -i)
can fail.
>>> import math
>>> d = math.nextafter(0.0, 1.0)
>>> d
5e-324
>>> d3 = 7 * d # .
Tim Peters added the comment:
Mark, ya, MS's Visual Studio's ldexp() has, far as I know, always worked this
way. The code I showed was run under the 2019 edition, which we use to build
the Windows CPython.
Raymond,
x = float(i)
is screamingly obvious at first glance.
Tim Peters added the comment:
> Objects/longobject.c::long_true_divide() uses ldexp() internally.
> Will it suffer the same issues with subnormals on Windows?
Doesn't look like it will. In context, looks like it's ensuring that ldexp can
only lose trailing 0 bits, so that
Tim Peters added the comment:
But I would like to leave it alone. Extended precision simply is not an issue
on any current platform I'm aware of ("not even Windows"), and I would, e.g.,
hate trying to explain to users why
1 / 2731 != 1.0 / 2731.0
(assuming we're n
Tim Peters added the comment:
Not a good idea in general - this rounding mode is _mostly_ "to zero", and
isn't intended for chains of operations. I don't believe I've ever seen it used
in a real program, so the current "no example at all" is a
Tim Peters added the comment:
I'll add that the rounding mode is intended to ease emulating fixed-point
arithmetic. The decimal spec claimed that was a goal, but there really isn't
any direct support for saying, e.g., "I want two digits after the decimal
point". Only
Tim Peters added the comment:
I agree with closing this - I don't know of real use cases either.
Serhiy, essentially all LSD radix sorts are stable, and rely on that for their
own correctness. MSD radix sorts vary.
--
___
Python tracker
&
Tim Peters added the comment:
Bad news: on Windows, exp2(x) is way worse then pow(2, x). Here I changed the
loop of Mark's little driver like so:
differ = really_bad = 0
worst = 0.0
for n in range(100_000):
x = random.uniform(-1000.0, 999.0) + random.random()
Tim Peters added the comment:
Across millions of tries, same thing: Windows exp2 is off by at least 1 ulp
over a third of the time, and by over 2 ulp about 3 times per million. Still
haven't seen pow(2, x) off by as much as 0.52 ulp.
>From its behavior, it appears Windows implement
Tim Peters added the comment:
Python is a general-purpose language, and as such I believe it's inappropriate
for it to be "a leader" in adopting new PRNGs. That's for area specialists to
pioneer.
If NumPy switched, that is a good reason to evaluate this again
Tim Peters added the comment:
Function objects can be used as dict keys too. Given that, it would be _very_
surprising if generator-iterators weren't. I don't really see a good point to
leaving this open. Live with it - it's a feature ;-)
--
no
Tim Peters added the comment:
What makes you think generator-iterator objects are mutable?
--
___
Python tracker
<https://bugs.python.org/issue38769>
___
___
Tim Peters added the comment:
Yes, what Steven said. All kinds of functions (including, but not limited to,
generator-iterators) are compared by object identity, nothing at all about
internal state. The contract of hash() is that if a == b, then we must have
that hash(a) == hash(b) too
Tim Peters added the comment:
Please be explicit: exactly which functions are you talking about, and exactly
what do you want them to do instead. Since, best I can tell, this is the first
complaint of its kind, it's a pretty safe bet people can't guess what you want
;-)
Note
Tim Peters added the comment:
Raymond, I think you've tricked yourself ;-) The prototype for C's duoble modf
is
double modf(double x, double *intptr);
Yes, after the call *intptr is an exact integer, but in the double format.
>>> math.modf(1e300)
(0.0, 1e+300)
I don&
Tim Peters added the comment:
Thanks for the NumPy discussion link, Mark! Did that set a world record for an
issue report's length? ;-) Not complaining - it's a very high quality and
informative discussion.
I'd be comfortable adopting whichever PRNGs numpy uses. n
Tim Peters added the comment:
I'm taking Raymond's advice to close this for now. The issue tracker isn't the
right place to work out ideas - python-ideas is far better for that
(StackOverflow isn't a good place for that either - StackOverflow is best for
when you have
Tim Peters added the comment:
There are a number of "obvious" properties that should obtain, given the
intended meaning of weights:
- An input with weight 0 should never be returned.
- The distribution shouldn't be affected by adding a new input with weight 0.
- The distrib
Tim Peters added the comment:
This behavior is intended and expected, so I'm closing this.
As has been explained, in any kind of function (whether 'lambda' or 'def'), a
non-local variable name resolves to its value at the time the function is
evaluated, not the v
Tim Peters added the comment:
Closing as Mark suggested, but as "not a bug" rather than "won't fix". That
floats aren't totally ordered is a consequence of IEEE 754 semantics, not
Python's whim. As Mark said, if people want a total_ordering function for
Tim Peters added the comment:
Marco, your
> I suppose the sorting function checks if the objects of
> the iterable are minor that another object
was incoherent to me. No idea what "are minor that another object" could
possibly mean.
As Mark explained, the mathema
Tim Peters added the comment:
Ah, so you're proposing a hack that would catch some, but not all, cases where
a total ordering doesn't exist. Why? The issue tracker isn't a suitable place
to discuss it regardless, so if you want to pursue it I'd suggest taking it to
p
Tim Peters added the comment:
Sorry, but I'm not replying here any more: the issue tracker is not for asking
questions or brainstorming ideas. Take this to python-ideas, please. If a
concrete proposal that gains traction results, _then_ the issue tracker may be
an appropriate place
Tim Peters added the comment:
Long ago I thought about adding "a buffer in front of" CPython's cyclic gc:
newly tracked items would be added there, and not participate in cyclic gc at
all until a collection passed.
For example, break the youngest generation into parts A &
Tim Peters added the comment:
Oh, I don't expect it to help appreciably - which is why I never did it ;-)
It's aimed at something different, I think, than what you're after: reducing
the burden of cyclic gc on objects that would otherwise soon be reclaimed by
refcounting an
Tim Peters added the comment:
All right! So, at a first look, "buffering" isn't an obvious disaster ;-)
I'm afraid nailing anything here is hard. For example, I don't know what you
did to "measure memory", but if you're using stats reported by
Tim Peters added the comment:
It's hard to be clearer without being annoyingly wordy. The truth is that sort
does all comparisons by calling the CAPI:
PyObject_RichCompareBool(v, w, Py_LT)`
Sorting doesn't know (or care) how `PyObject_RichCompareBool()` is implemented.
T
Tim Peters added the comment:
Try passing
autojunk=False
to the SequenceMatcher constructor.
More on that here:
https://bugs.python.org/issue31889
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue39
Tim Peters added the comment:
Let's stir this up a bit ;-) I recently had occasion to exchange ideas with
Larry Hastings about topsorts for use in a package manager he's writing. I
thought his API for adding edges was ... perfect:
add(node, *dependson)
So, e.g., add(A, B,
Tim Peters added the comment:
No doubt that something along these lines would be useful.
`nextafter()` is too widely implemented to fight against, despite the sucky
name ;-)
I believe the rest should be straightforward (for those who want them) to do
with one-liners, so there's not mu
Tim Peters added the comment:
[Steven]
> I think the second argument should also be optional, so
> that nextafter(x) returns the next representable float.
That's why the name sucks - there are, in general, two adjacent floats, so
"next" is ambiguous. I expect you int
Tim Peters added the comment:
+1
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue39310>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
What, exactly, in the output shows "the problem"? When I run it, the `a == b`
part is always True, while `len(x)` and `len(crazyQuilt2)` are always 30. The
other three (len(coordinates), len(x2), len(x3)) are always equal to each
other, but are mon
Change by Tim Peters :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue39338>
___
___
Tim Peters added the comment:
No problem! If you are trying to swap the values in two variables `x` and `y`,
in most languages that's spelled:
temp = x
x = y
y = temp
and that works in Python too. But in Python it's more common to do it with a
one-liner:
x
Tim Peters added the comment:
> I am slightly confused about what .prepare() should do. Why
> is this step necessary?
To say "I'm done adding edges". Any call to add() after prepare() should raise
an exception. Likewise, e.g., any call to get_ready() before prepa
Tim Peters added the comment:
I'll add ts.py, which was a work-in-progress that implements a minor variation
of most everything I typed about. If nothing else, its _find_cycle is useful
as a non-recursive linear-time cycle finder (recursion is deadly here because
recursive depth-
Tim Peters added the comment:
Oh, it's fine! Kahn's algorithm is what I meant when I wrote the "bog-standard
implementation" before.
I don't believe I've ever seen a context in real life where topsort speed made
a lick of real difference, so I expect any
Tim Peters added the comment:
`ulp()` is the right name: universally understood by those who know how to use
it, and easy to find exhaustive web explanations for those who don't.
In a different context, spelling out some variant of
Hypertext_Transfer_Protocol would be as wrong-head
Tim Peters added the comment:
+0 from me.
Another use is computing the Carmichael function for composite numbers (like an
RSA encryption modulus, in which context the Carmichael function is routinely
used).
But only +0 instead of +1 because it's so easy to build from gcd().
I don&#x
Tim Peters added the comment:
And I in turn agree with everything Mark said ;-) But I'll add that while the
analogy to comb/perm is a good one, I think the case for lcm is stronger than
for perm. Not only is lcm more common in real life (although, no, not at all
common overall!), per
Tim Peters added the comment:
Raymond, there was a thread a while back about adding an `imath` module, to
package the number-theoretic functions that frequently come up. _All_ these
things should really go into that instead, IMO. `math` started as a thin
wrapper around C's libm, an
Tim Peters added the comment:
I'd have to hear back from Raymond more on what he had in mind - I may well
have been reading far too much in the specific name he suggested.
Don't much care about API, etc - pick something reasonable and go with it. I'm
not overly ;-) conce
Tim Peters added the comment:
Arguments to `remainder()` are converted to floats, and the returned value is
also a float. These specific arguments convert to the same float:
>>> a = 12345678901234567890
>>> b = 12345678901234567891
>>> float(a) == float(b)
True
Tim Peters added the comment:
[Steven]
> ... Try it on numbers like this:
> ...
> Q = P*(313*(P-1)+1)*(353*(P-1)+1)
>
> Q is a 397 digit Carmichael Number. Its smallest factor is P,
> which has 131 digits.
> ...
> My old and slow PC can prove that Q is a composite num
Tim Peters added the comment:
[Tim]
>> The pure-Python Miller-Rabin code i posted in the
>> aforementioned thread is typically at least 100
>> times faster than that.
[Steven]
> This is exactly the sort of argument about quality of
> implementation which isn't, o
New submission from Tim Peters :
Here under Python 3.8.1 on 64-bit Windows:
>>> import decimal
>>> c = decimal.getcontext()
>>> c.prec = decimal.MAX_PREC
>>> i = decimal.Decimal(4)
>>> i / 2
Traceback (most recent call last):
File "", l
Tim Peters added the comment:
Vedran, as Mark said, the result is defined to have no trailing zeroes. In
general the module strives to return results "as if" infinite precision were
used internally, not to actually _use_ infinite precision internally ;-) Given
the same setup, e.
Tim Peters added the comment:
Formulas based on physical RAM probably work well on Linux, but not so well on
Windows: Windows has no "overcommit". Whether a virtual memory request
succeeds on Windows depends on how much RAM (+ swap space, if any) has already
been requested
Tim Peters added the comment:
This is almost all down to pragmatics for me.
For sum() and prod(), if there are only two operands then there are trivial
other ways to spell that (+ and *). So it makes most sense for them to accept
iterables instead. Essentially, e.g., nobody would ever
Tim Peters added the comment:
Thanks, Stefan! This turned out better than I expected ;-)
I'm closing the report, under the likely assumption that nobody cares enough
about obscure inelegancies in the Python version to bother.
--
status: open ->
Tim Peters added the comment:
Ya, I'll close this, channeling that Raymond would also reject it for now
(although he's certainly free to reopen it).
There's nothing wrong with adding such functions, but the `math` module is
already straying too far from its original inten
Tim Peters added the comment:
"!=" and "in" are comparison operators in Python, and _all_ comparison
operators "chain". That is,
x < y < z
means
x < y and y < z
(although y is evaluated only once), and in the same way
True != True in [Fals
Tim Peters added the comment:
Orion, you're using the interface as intended :-)
While it's too late to change now, if Python started over from scratch I'd
argue to leave "in" and "not in" out of this feature - chaining them is
_usually_ an unintended beh
Tim Peters added the comment:
Thanks for the succinct example! Although you don't need the print() ;-)
I can confirm this crashes the same way under a current master build (albeit on
Windows 64-bit).
gc is calculating how many references in the current generation are accounted
f
Tim Peters added the comment:
I'm suspecting that maybe we shouldn't be doing
Py_VISIT(od->od_weakreflist);
at all - best I can tell from a quick (non-exhaustive!) scan, the objects in
the weakref list aren't incref'ed to begin with. And even if they were, t
Tim Peters added the comment:
Be cautious about this. Many years ago I looked into this, mostly in the
context of the list sort's binary insertion sort, and results were all over the
map, depending on the compiler in use, the optimization level, and the range at
which (if any!) me
Tim Peters added the comment:
Ya, this change will never be made - give up gracefully :-)
1e100 and 10**100 aren't just of different types, they have different
mathematical _values_ now:
>>> 1e100 == 10**100
False
Tim Peters added the comment:
Then please take it to python-ideas? The issue tracker isn't a right place for
endless argument. python-ideas is. This is my last response here.
--
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
After some thought, I'm sure the diagnosis is correct: the weakref list must
be made invisible to gc. That is, simply don't traverse it at all. The crash
is exactly what's expected from traversing objects a container doesn't own
referen
Tim Peters added the comment:
Sorry, I don't see "a problem" here either. Rounding instead can change the
precise nature of the correlations if you insist on starting from the same
seed, but it hardly seems a real improvement; e.g.,
>>> random.seed(12)
>>>
Tim Peters added the comment:
This is where you're not getting traction:
"A randrange() function should a priori not be so strongly tied to the binary
base."
That's a raw assertion. _Why_ shouldn't it be? "Because I keep saying so"
isn't changing m
Tim Peters added the comment:
I've been involved - usually very lightly, but sometimes deeply - with PRNGs
for over 40 years. I've never seen anyone raise the kinds of concerns you're
raising here, and, frankly, they don't make sense to me.
But on the chance tha
Tim Peters added the comment:
If you pursue this, please introduce a new function for it. You immediately
have an idea about how to change the current function precisely because it
_doesn't_ try to guess what you really wanted. That lack of magic is valuable
- you're not actuall
Tim Peters added the comment:
This is very well known on Windows, and the behavior is inherited from the
Windows C libraries. If you need a byte count instead, then - as the docs
already say - you need to open the file in binary mode instead.
--
nosy: +tim.peters
Tim Peters added the comment:
Sorry, but there is no documented relationship between byte offsets and tell()
results for text-mode files in Windows:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/ftell-ftelli64?view=vs-2019
Tim Peters added the comment:
Good to know, Eryk - thanks!
--
___
Python tracker
<https://bugs.python.org/issue39962>
___
___
Python-bugs-list mailing list
Unsub
Tim Peters added the comment:
u1 is a global _only_ in a process that runs `function()`, which declares u1
global and assigns it a value. You have no sane expectation that a worker
process (none of which run `function()`) will know anything about it.
Are you sure you're running 2.7 an
Change by Tim Peters :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue40005>
___
___
Tim Peters added the comment:
Good idea, but yet another that really belongs in an `imath` module (which
doesn't yet exist).
How ambitious should it be? Sympy supplies a `factorint()` function for this,
which uses 4 approaches under the covers: perfect power, trial division,
Pollar
Tim Peters added the comment:
I have scant memory of working on this code. But back then Python wasn't at
all keen to enforce type checking in harmless contexts. If, e.g., someone
found it convenient to pass integers that happened to be in float format to
randrange(), why not? Going
Tim Peters added the comment:
Jonathan, _almost_ no factoring algorithms have any use for a table of primes.
Brute force trial division can use one, but that's about it.
A table of primes _is_ useful for implementing functions related to pi(x) = the
number of primes <= x, and th
Tim Peters added the comment:
It's neither "bug" nor "feature" - it's an inherited quirk CPython maintains to
avoid annoying users for no good reason.
If you absolutely have to "do something", how about adding a mere footnote?
The docs already impl
Tim Peters added the comment:
Raymond is talking about the cause of this error in what you showed:
AttributeError: 'Queue' object has no attribute 'Empty'
The exception you're _trying_ to catch is "queue.Empty", where "queue" is the
queue _mod
Tim Peters added the comment:
> ... so the _intended_ "queue.Queue" still works.
Oops. Of course that should have said:
> ... so the _intended_ "queue.Empty" still works.
--
___
Python tracker
<https
Tim Peters added the comment:
"Lazy" has several possible aspects, of which Pool.imap() satisfies some:
- Its iterable argument is materialized one object at a time.
- It delivers results one at a time.
So, for example, if `worker` is a function that takes a single int, then
Tim Peters added the comment:
Raymond, what application do you have that wouldn't be completely addressed by
sticking to just .add() (to record dependencies) and .static_order() (to
retrieve a linear order)?
Larry Hastings and I originally worked out the fancier bits of the interfa
Tim Peters added the comment:
Possibly, sure. But I believe it's hard to beat
add(node, *predecessors)
for usability as a way to build the dependency graph. For example, a list of
pairs is a comparative PITA for most use cases I've had. Whether it's
following a recipe
Tim Peters added the comment:
Whenever there's parallel processing with communication, there's always the
potential for producers to pump out data faster than consumers can process
them. But builtin primitives generally don't try to address that directly.
They don'
Tim Peters added the comment:
If object A owns a strong reference to object B, and A participates in cyclic
gc, and B may be part of a cycle, then it's necessary and sufficient that A's
type's tp_traverse implementation invoke Py_VISIT() passing A's pointer to B.
It w
Tim Peters added the comment:
Possibly related:
https://bugs.python.org/issue10109
Henry, I'm not clear at all about what you're saying. Please give at least one
specific, concrete example of the behavior you're objecting to, and specify the
behavior you want
Tim Peters added the comment:
Serhiy, are you aware of heapq.merge()? If not, look it up. And then if you
still think merge_sorted() would differ in some way, please spell out how it
would differ.
Based on what you wrote, you threw an invalid invocation of tee() into the mix
for some
Tim Peters added the comment:
Henry, I have to ask again: please give at least one specific, concrete
example of the behavior you're objecting to. English isn't helping, and I
still have no idea what your complaint is.
What I'm looking for:
for i in it
Tim Peters added the comment:
Henry, no, I see no problem while running your example. It's been running on
my box for over 5 minutes now, and memory use remains trivial.
Note that in the code I posted for you, instead of [1, 2] I used range(100),
and instead of 50 I used a million:
Tim Peters added the comment:
Raymond, I think that removing sample(set) support is a different issue. This
report will just change its final example line to
>>> print(random.sample(list(x), 1))
or
>>> print(random.sample(tuple(x), 1))
and have the same complaint
Tim Peters added the comment:
Yup, I agree sample(set) is a misfeature.
--
___
Python tracker
<https://bugs.python.org/issue40325>
___
___
Python-bugs-list m
Tim Peters added the comment:
Offhand I'm surprised because of this: if a weakref W refers to object O, and
W and O are _both_ in cyclic trash, gc does not want to invoke W's callback (if
any). In fact, it works hard not to call it. So I'm surprised that the
callback is
Tim Peters added the comment:
Ah, I missed that `cache` is global. So it will hold reachable strong refs to
the weakrefs stored for the dict's values. So gc will run the callbacks
associated with weakrefs' trash referents.
I think you're out of luck. Nothing is defined abo
Tim Peters added the comment:
Things get complicated here because in older versions of Python an instance of
ForeverObject(True) could "leak" forever: if an object in a trash cycle had a
__del__ method, that method would never be called, and the object would never
be collected.
Tim Peters added the comment:
Allan, we don't (at least not knowingly) write tests that rely on order of
end-of-life actions, because the _language_ defines nothing about the order.
So you can permute the order and it's unlikely any standard tests would fail.
The only reason yo
Tim Peters added the comment:
Well, the refcounts on _everything_ cyclic gc sees are greater than 0. Because
if an object's refcount ever falls to 0 in CPython, reference counting deals
with it immediately, and so it doesn't survive to participate in cyclic gc.
IOW, absolutely
301 - 400 of 1332 matches
Mail list logo
