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. But for
Tim Peters added the comment:
So as far as possible, CPython only uses __lt__ ("<") element comparisons for
its order-sensitive algorithms. This is documented for list.sort(), but the
bisect and heapq modules strive to do the same.
The point is to minimize the number of compa
Tim Peters added the comment:
I'm in favor of adding all of this (covariance, coefficient, linear
regression). It's still at the level of elementary statistics, and even taught
in watered down "business statistics" classes. It's about the minimum that can
be done beyond singl
Tim Peters added the comment:
> While Neil & I haven't thought of ways that can go wrong now
> beyond that a "surprise finalizer" may get run any number of
> times ...
Speaking of which, I no longer believe that's true. Thanks to the usual layers
of baffling renamin
Tim Peters added the comment:
> I'm often amazed it works at all, let alone perfectly. ;-P
Indeed! Every time I take a break from gc and come back, I burn another hour
wondering why it doesn't recycle _everything_ ;-)
> But what happens if the GC doesn't see that WZ is
Tim Peters added the comment:
Everything here has been addressed, so closing this. zleak.py can apparently
run forever now without leaking a byte :-)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
_
Tim Peters added the comment:
+1. This code got quite brittle when they decided to fit two pointers, a fat
integer, and 3 flags into a struct with room for only the two pointers ;-)
It's a mine field now. Enabling one of the few automated mine detectors is
thoroughly sensible
Tim Peters added the comment:
I checked the stat fix into master, but GH failed to backport to 3.7 or 3.8 and
I'm clueless. More info in the PR. Does someone else here know how to get a
backport done?
--
stage: patch review -> backport needed
versions: +Python 3.7, Python
Tim Peters added the comment:
New changeset ecbf35f9335b0420cb8adfda6f299d6747a16515 by Tim Peters in branch
'master':
bpo-38379: don't claim objects are collected when they aren't (#16658)
https://github.com/python/cpython/commit/ecbf35f9335b0420cb8adfda6f299d6747a16515
Tim Peters added the comment:
PR 16658 aims to repair the stats reported.
--
___
Python tracker
<https://bugs.python.org/issue38379>
___
___
Python-bugs-list m
Change by Tim Peters :
--
keywords: +patch
pull_requests: +16241
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/16658
___
Python tracker
<https://bugs.python.org/issu
Tim Peters added the comment:
I don't have a problem with the current behavior (early out on zero, even if
later arguments are senseless). So:
> * Just document that there is an early-out for zero.
--
___
Python tracker
<https://bugs.pyth
Tim Peters added the comment:
Just noting that check_garbage() currently only determines which trash objects
are now directly reachable from outside. To be usable for the intended
purpose, it would need to go on to compute which trash objects are reachable
from those too.
Maybe a new
New submission from Tim Peters :
While people are thinking about gc, zleak.py shows a small bug, and a possible
opportunity for improvement, in the way gc treats finalizers that resurrect
objects.
The bug: the stats keep claiming gc is collecting an enormous number of
objects, but in fact
Tim Peters added the comment:
Don't know. Define "the problem" ;-) As soon as the allocation is over 512
bytes (64 pointers), it's punted to the system malloc family. Before then, do
a relative handful of relatively small memcpy's really matter?
pymalloc is faster than syst
Tim Peters added the comment:
WRT pymalloc, it will always copy on growing resize in this context. A
pymalloc pool is dedicated to blocks of the same size class, so if the size
class increases (they're 16 bytes apart now), the data must be copied to a
different pool (dedicated to blocks
Tim Peters added the comment:
BTW, the phrase "missing tp_traverse" is misleading. If an object with a NULL
tp_traverse appears in a gc generation, gc will blow up the next time that
generation is collected. That's always been so - gc doesn't check whether
tp_traverse is NUL
Tim Peters added the comment:
My understanding is that the CFFI types at issue don't even have
Py_TPFLAGS_HAVE_GC. They're completely invisible to gc. As Armin says in the
CFFI issue report (linked to earlier), he never got the impression from the
docs that he needed to implement anything
Tim Peters added the comment:
Loose ends. Telegraphic because typing is hard.
1. Docs should be changed to encourage implementing the full gc protocol for
"all" containers. Spell out what can go wrong if they don't. Be upfront about
that history has, at times, proved us too
Tim Peters added the comment:
Neil, about this comment:
# - ct is not yet trash (it actually is but the GC doesn't know because of
# the missing tp_traverse method).
I believe gc should know ct is trash. ct is in the cf list, and the latter
does have tp_traverse.
What gc won't know
Tim Peters added the comment:
Łukasz, all type objects have tp_clear slots, and always did. The patch in
question put something useful in the function object's tp_clear slot instead of
leaving it NULL. No interface, as such, changes either way
Tim Peters added the comment:
Yes, it's better to have tp_clear than not for a variety of reasons (including
setting examples of best practice).
Best I can tell, the patch for BPO-33418 was reverted _only_ to worm around the
crash in _this_ report. That's no longer needed
Tim Peters added the comment:
It's unclear to me whether BPO-33418 was a bug or a contrived annoyance :-)
If someone believes it was worth addressing, then what it did is the only way
to fix it, so should be restored now.
--
___
Python tracker
Tim Peters added the comment:
FWIW, I agree with Neil in all respects about the release: his patch is the
best approach, plugs segfaulting holes that have been there for many years, and
the earlier patches aren't needed anymore.
--
___
Python
Tim Peters added the comment:
Neil, my brief msg 10 minutes before yours suggested the same thing (just clear
the weakref), so it must be right ;-)
--
___
Python tracker
<https://bugs.python.org/issue38
Tim Peters added the comment:
Neil, how about this alternative: leave the weakref implementation alone. If
we find a trash weakref, simply clear it instead. That would prevent callbacks
too, & would also prevent the weakref from being used to retrieve its
possibly-trash-too refe
Tim Peters added the comment:
> Would the attached rough patch (gc_disable_wr_callback.txt)
> be a possible fix? When we find W inside handle_weakrefs(),
> we mark it as trash and will not execute the callback.
It's semantically correct since we never wanted to execute a call
Tim Peters added the comment:
Ah, nevermind my last comment - yes. handle_weakrefs will clear all weakrefs to
the objects we know are trash.
--
___
Python tracker
<https://bugs.python.org/issue38
Tim Peters added the comment:
> I see that handle_weakrefs() calls _PyWeakref_ClearRef() and that
> will clear the weakref even if it doesn't have callback. So, I
> think that takes care for the hole I was worried about. I.e. a
> __del__ method could have a weakref to an non-
Tim Peters added the comment:
> Note that my flags show that W *is* in 'unreachable'. It has
> to be otherwise F would not have tp_clear called on it.
Right! W holds a strong reference to F, so if W were thought to be reachable,
F would be too. But F isn't.
> But when delet
Tim Peters added the comment:
Fleshing out something I left implicit: if there's a trash object T with a
finalizer but we don't KNOW it's trash, we won't force-run its finalizer before
delete_garbage starts either. Then, really the same thing: we may tp_clear
some piece of trash T's
Tim Peters added the comment:
Sorry, this is very hard for me - broke an arm near the shoulder on Tuesday,
and between bouts of pain and lack of good sleep, concentration is nearly
impossible. Typing with one hand just makes it worse :-(
We must know that F is trash, else we never would
Tim Peters added the comment:
> call_func and remove are part of a reference cycle. A forced garbage
> collection breaks the cycle and removes the two objects, but they are
> not removed in the expected order:
>
> * first: call_func
> * then: remove
>
> The c
Tim Peters added the comment:
tp_clear implementations are necessary to reclaim trash cycles. They're always
best practice for objects that may be in trash cycles. tuples are just "cute
rebels" that way ;-)
Best guess is that the (some) extension isn't playing by the rules.
Tim Peters added the comment:
Sorry, but there was nothing wrong with the CHECK_SMALL_INT macro, to my eyes,
to begin with - except that it was burdened with an over-elaborate "do ...
while(0)" wrapper.
Not all macros are _intended_ to be "cheap functions".
Tim Peters added the comment:
There's an eternal culture clash here: functional languages have a long
history of building in just about everything of plausible use, regardless of
how trivial to build on other stuff. This started when LISP was barely
released before (cadr x) was introduced
Tim Peters added the comment:
Some results of the "add perturb shifted left 1 instead" approach. These come
from using an old pile of Python code I have that allows for easy investigation
of different collision probe strategies.
- As expected, because it has no fi
Tim Peters added the comment:
I agree with Raymond here: using collections.namedtuple is fine in the pure
Python version. Since Raymond checked in doc changes to purge the phrase
"struct sequences" (thanks again for that!), it's consistent with everything
else now for the ne
Tim Peters added the comment:
Following up, at least under Visual Studio for x86 "it's free" to change the
code to add in `perturb` shifted left. The C source:
perturb >>= PERTURB_SHIFT;
i = (i*5 + (perturb << 1) + 1) & mask;
compiles to this, where
Tim Peters added the comment:
A more principled change would be to replace instances of this:
i = (i*5 + perturb + 1) & mask;
with this:
i = (i*5 + (perturb << 1) + 1) & mask;
The latter spelling has no fixed points. That's easy to see: `(perturb << 1)
+ 1
Tim Peters added the comment:
Something that may be slightly worth pursuing: in
j = (5*j + 1) % 2**power
to get a full-period sequence hitting every integer in range(2**power) exactly
once, the multiplier (5) is a bit delicate (it has to be congruent to 1 mod 4),
but the addend (1
Tim Peters added the comment:
Note that you can contrive similar cases with positive hash codes too. For
example, force both hash codes to 2**60 - 2.
The salient points are that 0 * 5 is congruent to 0 mod any power of 2, while
-2 * 5 = -10 is congruent to -2 mod 8, so they're fixed
Tim Peters added the comment:
Paul, please heed what Raymond said: it's not good to merge another core dev's
PR unless they ask you to. Besides what Raymond said, a core dev may well
check in incomplete work for any number of reasons (e.g., to see how the
automated test runs turn out
Tim Peters added the comment:
I don't believe that would improve the docs, but suit yourself. This is hardly
a FAQ, but instead a peculiar case where, for whatever reason, someone is
saying "I'm puzzled by what `or` does, but didn't read the docs for `or`".
Most peopl
New submission from Tim Peters :
The Glossary has this entry:
"""
struct sequence
A tuple with named elements. Struct sequences expose an interface similar to
named tuple in that elements can be accessed either by index or as an
attribute. However, they do not have any of
Tim Peters added the comment:
Ah, so you were expecting an error! That helps.
But that's not how the language works, or how it's documented to work, as has
been explained in quite some detail already.
In general, precedence _constrains_ evaluation order, but does not _define_
Tim Peters added the comment:
BTW, the docs also spell out that "and" and "or" ALWAYS evaluate their left
operand before their right operand, and don't evaluate the right operand at all
if the result of evaluating the left operand is true (for "or") o
Tim Peters added the comment:
@sangeetamchauhan, the reply you got in the image you attached was in error -
kind of. Section "6.16. Operator precedence" defines Python's operator
precedence:
https://docs.python.org/3/reference/expressions.html#index-92
"""
The f
Tim Peters added the comment:
I'm sorry you're not satisfied with the answer, but I'm a bona fide expert on
this and you're not going to get anyone to agree with your confusion here ;-)
But the bug tracker is not the right place for tutorials. Please take this up
on, e.g., the Python
Tim Peters added the comment:
It's working fine. What do you expect? For example,
9 or 7 > "str"
groups as
9 or (7 > "str")
9 is evaluated for "truthiness" first, and since it's not 0 it's considered to
be true. That's enough to determ
Change by Tim Peters :
--
assignee: -> rhettinger
___
Python tracker
<https://bugs.python.org/issue24416>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Peters added the comment:
I favor making this a structseq, primarily based on Paul's attempt to find
actual use cases, which showed that named member access would be most useful
most often. I have no intuition for that myself, because while I wrote the
original functions here, I've
Tim Peters added the comment:
You're probably chasing ghosts ;-) Please read about what needs to be done to
use valgrind successfully with Python:
https://github.com/python/cpython/blob/master/Misc/README.valgrind
--
nosy: +tim.peters
title: Use After Free: PyObject_Free ->
Tim Peters added the comment:
> Also, THE min("Infinity") is priniting "I". Practically,
> the minimum value is "e" right ?
Sorry, I have no idea what "practically" means to you. It's just a fact that
all uppercase ASCII letters compare less t
Tim Peters added the comment:
This has nothing in particular do with `min()`. As strings, 'I' < 'i', and 'F'
< 'I'. For example,
>>> 'I' < 'i'
True
>>> sorted("InFinity")
['F', 'I', 'i', 'i', 'n', 'n', 't', 'y']
That's all working as intended and as d
Tim Peters added the comment:
This just isn't going to happen. There's no agreement to be had. For example,
the proleptic Gregorian calendar _does_ have a "year 0", and so also does ISO
8601.
Version 1.0 of the XML schema spec did not have a year 0, but _claimed_ to be
Tim Peters added the comment:
> Sometimes you guys make me feel dumb as a rock.
I expect we all do that favor for each other at times ;-)
--
___
Python tracker
<https://bugs.python.org/issu
Change by Tim Peters :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tim Peters added the comment:
I don't have a problem with the trivial ring - I wasn't being that high-minded
;-) I was testing a different inverse algorithm, and in the absence of errors
checked that
minv(a, m) * a % m == 1
for various a and m >= 0. Of course that failed using
Tim Peters added the comment:
Mark, to save you the hassle, I'm closing this myself now. Thanks for the
feedback!
--
assignee: -> tim.peters
resolution: -> not a bug
stage: patch review -> resolved
status: open -> closed
___
Py
Tim Peters added the comment:
Yup, you have a point there! :-) I guess I'm just not used to 0 being a
multiplicative identity.
Don't know what other systems do. Playing with Maxima, modulo 1 it seems to
think 0 is the inverse of everything _except_ for 0. `inv_mod(0, 1)` returns
`false
Tim Peters added the comment:
@Batuhan, fine by me if you want to take this on! It should be relatively
easy. But Mark wrote the code, so it's really up to him. While I doubt this,
he may even argue that it's working correctly already
New submission from Tim Peters :
For example, these should all raise ValueError instead:
>>> pow(2, -1, 1)
0
>>> pow(1, -1, 1)
0
>>> pow(0, -1, 1)
0
>>> pow(2, -1, -1)
0
>>> pow(1, -1, -1)
0
>>> pow(0, -1, -1)
0
--
component
Tim Peters added the comment:
For posterity:
"Modular Inverse Algorithms Without Multiplications for Cryptographic
Applications"
Laszlo Hars
https://link.springer.com/article/10.1155/ES/2006/32192
"""
On the considered computational platforms
Tim Peters added the comment:
Some random notes:
- 1425089352415399815 appears to be derived from using the golden ratio to
contrive a worst case for the Euclid egcd method. Which it's good at :-) Even
so, the current code runs well over twice as fast as when replacing the
pow(that, -1
Tim Peters added the comment:
I'm with Mark: leave numeric hashes alone. There's no reason to change them,
and in addition to what Mark wrote it's a positively Good Thing that `hash(i)
== i` for all sufficiently small ints. Not only is that efficient to compute,
it guarantees
Tim Peters added the comment:
Mark, I did just a little browsing on this. It seems it's well known that egcd
beats straightforward exponentiation for this purpose in arbitrary precision
contexts, for reasons already sketched (egcd needs narrower arithmetic from the
start, benefits from
Tim Peters added the comment:
Well, details matter ;-) Division in Python is expensive. In the
exponentiation algorithm each reduction (in general) requires a 122-by-61 bit
division. In egcd, after it gets going nothing exceeds 61 bits, and across
iterations the inputs to the division
Tim Peters added the comment:
Why I expected a major speedup from this: the binary exponentiation routine
(for "reasonably small" exponents) does 30 * ceiling(exponent.bit_length() /
30) multiply-and-reduces, plus another for each bit set in the exponent.
That's a major differen
New submission from Tim Peters :
Recording before I forget. These are easy:
1. As the comments note, cache the hash code.
2. Use the new (in 3.8) pow(denominator, -1, modulus) to get the inverse
instead of raising to the modulus-2 power. Should be significantly faster. If
not, the new
Tim Peters added the comment:
BTW, I should clarify that I think the real "sin" here was making bool a
subclass of int to begin with. For example, there's no sane reason at all for
bools to support division, and no reason for a distinct type not to define "~"
a
Tim Peters added the comment:
I don't agree that "~" doesn't "work". If people are reading it as "not",
they're in error. The Python docs say ~x
means
the bits of x inverted
and that's what it does. There's no sense it which it was _intended_ to
Tim Peters added the comment:
Mark, isn't `int()` the obvious way "to convert an integer-like thing to an
actual int"?
>>> int(True)
1
>>> int(False)
0
For the rest, I'm -True on making ~ do something magical for bools inconsistent
with what it does fo
Tim Peters added the comment:
I agree: we "shouldn't have" documented anything about hash codes beyond the
invariants needed to guarantee they work for their intended purpose, chiefly
that x == y implies hash(x) == hash(y).
Which leads to your other question ;-) That invariant
Tim Peters added the comment:
Well, I have no code that would benefit from this change. What's the point?
Sure, I use _parts_ of hash codes at times, but, e.g.,
index = the_hash_code & SOME_LOW_BIT_MASK
in Python couldn't care less about the sign of `the_hash_code` - it ret
Tim Peters added the comment:
Since this depends on the platform libm implementation of pow(), I'm closing
this as "won't fix".
Steve, on the chance you're serious ;-) , there are implementations of the
"constructive reals", which indeed act like infinite-precision flo
Change by Tim Peters :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.or
Tim Peters added the comment:
Python delegates exponentiation with a Python float result to the platform C's
double precision `pow()` function. So this is just what the Windows C pow(2.0,
-1075.0) returns. All native floating point operations are subject various
kinds of error
Tim Peters added the comment:
You'll see much the same in every programming language that supports your
computer's floating-point hardware. Start by reading this gentle introduction:
https://docs.python.org/3/tutorial/floatingpoint.html
This bug tracker isn't a place for tutorials, though
Change by Tim Peters :
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue37537>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Tim Peters :
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue37543>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
> we could say that it does not matter if
>
> def f():
> if 0:
> yield
>
> should be or not a generator
Slippery slope arguments play better if they're made _before_ a decade has
passed after the slope was fully greased.
There's not
Tim Peters added the comment:
> Using jumps is not removing the optimization
> entirely, is just a weaker and more incomplete
> way of doing the same.
Sorry, I'm afraid I have no idea what that means. The generated code before
and after was wildly different, as shown in Ned's
Tim Peters added the comment:
> This is the expected result of fixing a bug that has been
> open since 2008
It's the expected result of fixing a bug _by_ eliminating the optimization
entirely. It's not an expected result of merely fixing the bug. It's quite
obviously _possible_ t
Tim Peters added the comment:
There's "correctness" that matters and "correctness" that's merely pedantic ;-)
CPython has acted the current way for about 15 years (since 2.4 was released),
and this is the first time anyone has raised an objection. That's just not
en
Tim Peters added the comment:
I hate this change :-( The code generated for something like this today:
def f():
if 0:
x = 1
elif 0:
x = 2
elif 1:
x = 3
elif 0:
x = 4
else:
x = 5
print(x)
is the same as for:
def f():
x = 3
Tim Peters added the comment:
Mark's analysis is spot-on - good eye :-)
Here under 3.7.3 [MSC v.1916 64 bit (AMD64)] on win32, in the original script
it makes no difference at all for negative "small x" (where, as Mark said, `1 -
random.random()` is exactly representable):
Count
Tim Peters added the comment:
I haven't used protobuf, but it's _generally_ true that crashes that occur for
the first time in the presence of C or C++ extension modules are due to subtle
(or not so subtle) mistakes in using the sometimes-delicate Python C API. So
it's too soon to play
Change by Tim Peters :
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue37448>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
In real life, I expect 99.999%+ of calls will be made with small arguments, so
(1) is worth it. I like Mark's suggestion to use uint64_t so the acceptable
range doesn't depend on platform. At least in the world I live in, 32-bit
boxes are all but extinct
Tim Peters added the comment:
Thanks, Terry! Based on your latest results, "quadratic time" isn't plausible
here anymore, so I'm closing this. Nasty cache effects certainly played a
role, but they were just a flea on the dog ;-)
--
resolution: -> fixed
stage:
Tim Peters added the comment:
Raymond, please read my very recent comment one above yours. A (overall)
quadratic-time algorithm (O(A**2) where A is the number of arenas) in
obmalloc.c is (to my eyes) probably the _primary_ cause of the sloth here.
That's been fixed for 3.8, but I don't
Change by Tim Peters :
--
stage: resolved -> commit review
___
Python tracker
<https://bugs.python.org/issue32846>
___
___
Python-bugs-list mailing list
Un
Tim Peters added the comment:
Looks likely that the _major_ cause of the quadratic-time delete behavior was
due to that obmalloc used a linear-time method to keep its linked list of
usable arenas sorted in order of number of free pools. When a pool became
unused, its arena's count of free
Change by Tim Peters :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tim Peters added the comment:
New changeset d1c85a27ea9fe70163cad3443d5e534d94f08284 by Tim Peters in branch
'master':
bpo-37257: obmalloc: stop simple arena thrashing (#14039)
https://github.com/python/cpython/commit/d1c85a27ea9fe70163cad3443d5e534d94f08284
Change by Tim Peters :
--
keywords: +patch
pull_requests: +13903
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/14039
___
Python tracker
<https://bugs.python.org/issu
Change by Tim Peters :
--
type: -> performance
___
Python tracker
<https://bugs.python.org/issue37257>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Tim Peters :
Scenario: all arenas are fully used. A program then runs a loop like:
while whatever:
p = malloc(n)
...
free(p)
At the top, a new arena has to be created, and a single object is taken out of
a single pool. At the bottom, that object
Change by Tim Peters :
--
assignee: -> tim.peters
___
Python tracker
<https://bugs.python.org/issue37211>
___
___
Python-bugs-list mailing list
Unsubscrib
401 - 500 of 1679 matches
Mail list logo
