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/b9c46a2c2d7fc68457bff641f78932
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:
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
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., the she
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 supports enough
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 neither is it a feat
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:
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
status
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/3209cbd99b6d65aa18b3beb124fac9c792b8993d
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/issue40
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 patch
versions: +Python
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:
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 deep
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 as
many changes
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 to a relat
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 devi
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).
When
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:
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 everything
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 your example
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:
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 about the order
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 invoked at all
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:
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:
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:
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 itertools.product
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:
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 to see instead
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 would be a Really Bad
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't - and can't - know
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 to bake a cake
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 interface
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:
> ... 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:
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 _module_. But you reb
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 imply the a
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 the big
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 &quo
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,
Pollard rho
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:
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 and 3.7
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:
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:
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
[Marco Sulla ]
> Excuse me, Tim Peters, what do you think about my (probably heretical)
> proposal of simply raising an exception instead of return a NaN, like
> Python already do for division by zero?
Sorry, I'm missing context. I don't see any other message(s) from you
in this thread,
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 actually confused
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 that I've missed recent
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 minds ;-)
I under
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:
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
references to.
I agree
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/issue39
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:
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!) memmove
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, that
line would o
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
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 behavior.
T
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 [F
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 intent as a home
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 -> clo
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:
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:
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.
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:
[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'
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:
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:
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 ;-) concerned with being
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, and has
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!), perm
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't agree
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-headed
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 linear-time (
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-first
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 prepare
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, y = y, x
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:
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
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:
[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 inten
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 much
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, C) says
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:
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.
The closest
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 the OS, that's
frau
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 anyway
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 & B.
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:
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
python-ideas. If you
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 math
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
floats, t
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 value it _had_ at the time
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 distribution
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 a very specific use
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. numpy has better
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't think
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 that, e.g
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:
What makes you think generator-iterator objects are mutable?
--
___
Python tracker
<https://bugs.python.org/issue38769>
___
___
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 ;-)
--
nosy: +tim.peters
301 - 400 of 1679 matches
Mail list logo
