Tim Peters added the comment:
Thanks, Mark! So if int.as_integer_ratio is added to the core, numpy.int64
won't magically have it too, regardless of whether we do or don't add an
implementation to numbers.Rational.
As an end user, I'd be surprised if numpy.int64 didn't su
Tim Peters added the comment:
[Raymond]
> The OPs notion of "absurd" behavior implies a rule that
> all float methods should be available for ints. That
> would suggest the is_integer, hex, fromhex, and
> as_integer_ratio would all need to propagate to the
> other type
Tim Peters added the comment:
Serhiy, I don't understand. If `numbers.Rational` is in fact a superclass of
`numpy.int64`, then the latter will inherit an implementation added to the
former. The idea here isn't to add an abstract method to the Rational
interface, but a concre
Tim Peters added the comment:
Thanks, Guido! I figured I was missing something :-)
It looks like `numbers.Rational` _is_ a "for real" base class of
`fractions.Fraction`, though, so I'm in favor of supplying a default
implementation of `.as_integer_ratio()` in `numbers.R
Tim Peters added the comment:
Serhiy, we already went down the path of implementing this as a method. Of
course `numbers.Rational` could define the method as `return (self.numerator,
self.denominator)` for itself and its subclasses. Unless I'm confused, that
would "magically&q
Tim Peters added the comment:
> Is this also desired for fractions.Fraction and numbers.Rational?
I think so. The idea, e.g., that "it's obvious" for Fraction is no more
compelling than that it's even more obvious for ints ;-) Given that it's
spreadin
Tim Peters added the comment:
What did you expect? The precision of Python ints is limited only by the
amount of memory you have, but Python floats are IEEE-754 double precision
numbers, and have only 53 bits of precision.
2**53 + 1 simply can't be represented exactly as a float
Tim Peters added the comment:
The docs could be clearer about this: the argument to .put() is _not_ pickled
at the time .put() is called. The object is remembered (by reference, not by
value), and a feeder thread pickles the value and puts the pickle on the queue
when the feeder thread
Tim Peters added the comment:
> Surprisingly, deleting a very large set takes much longer than creating it.
Luis, that's not surprising ;-) When you create it, it's mostly the case that
there's a vast chunk of raw memory from which many pieces are passed out in
address
Tim Peters added the comment:
Stefan, yup! Thank you. `array.array` and `bytearray` iterators appear to
work the same way as `list` iterators here.
Terry, the note in the `for` statement docs was written before there _was_ an
iterator protocol. For example, here are the 1.5.1 docs:
https
Tim Peters added the comment:
As I mentioned on StackOverflow, the literal in question appears to have been
crafted to convert to the best possible 53-bit binary approximation to log(2)
regardless of whether a compiler converts it to double precision (53 bits of
precision) or to "d
Tim Peters added the comment:
Some other points to consider: I don't think this belongs in the `for`
statement docs at all. Instead they should merely _note_ that what happens if
a sequence being iterated over is mutated is up to the sequence iterator.
Then, e.g., the `list` docs s
New submission from Tim Peters :
This has come up repeatedly, and the docs should be updated to resolve it:
https://stackoverflow.com/questions/48603998/python-iterating-over-a-list-but-i-want-to-add-to-that-list-while-in-the-loop/48604036#48604036
Seemingly the only relevant documentation is
Tim Peters added the comment:
Thank you for giving this worthy orphan a home, Raymond!
Victor, don't fret too much. The code is really quite simple, and at worst
affects only `sorted()` and `list.sort()`. The vast bulk of review effort (of
which it got enough) went into dreami
Tim Peters added the comment:
I agree it would be nice (very!) to get this in. Indeed, I'm surprised to see
that this is still open :-(
But who can drive it? I cannot.
--
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
This report appears to be the same:
https://bugs.python.org/issue27463
One other thing to note: the Python docs are sometimes unclear about whether
expressions are intended to be interpreted as Python code or as mathematical
expressions. In:
"&qu
Tim Peters added the comment:
By the way, going back to your original problem, "the usual" solution to that
different platforms can list directories in different orders is simply to sort
the listing yourself. That's pretty easy in Python ;-) Then your test can
verify the h
Tim Peters added the comment:
Jason, an ellipsis will match an empty string. But if your expected output is:
"""
x...
abcd
...
"""
you're asking for output that:
- starts with "x"
- followed by 0 or more of anything
- FOLLOWED BY A NEWLINE (I t
Tim Peters added the comment:
And I somehow managed to unsubscribe Steven :-(
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue32
Tim Peters added the comment:
Right, "..." immediately after a ">>>" line is taken to indicate a code
continuation line, and there's no way to stop that short of rewriting the
parser.
The workaround you already found could be made more palatable if
Tim Peters added the comment:
First thing: the code uses the global name `outputer` for two different
things, as the name of a module function and as the global name given to the
Process object running that function. At least on Windows under Python 3.6.4
that confusion prevents the
Tim Peters added the comment:
To answer the old accusation ;-), no, this isn't my wording. I _always_
explain that Python's integer bit operations act as if the integers were stored
in 2's-complement representation but with an infinite number of sign bits.
That's
Tim Peters added the comment:
Mark, indeed, in the email from Vincent Lefevre you linked to, his entire
argument was: (a) we already specified what happens when the base is a zero;
so, (b) for each of the six pow(a_zero, y) cases we specified, derive a
matching rule for an inf base via
Tim Peters added the comment:
No worries, Mark :-) Odd things happen sometimes when people are editing near
the same time. BTW, of course I agree with closing this!
--
___
Python tracker
<https://bugs.python.org/issue32
Tim Peters added the comment:
As a comment in the referenced patch says, the intent of the patch was to make
behavior match the C99 spec. Among other things, C99's annex F (section
F.9.4.4 "The pow functions") says:
"""
— pow(−∞, y) returns −0 for y an odd int
Tim Peters added the comment:
I agree the current recipe strikes a very nice balance among competing
interests, and is educational on several counts.
s/pending/numactive/
# Remove the iterator we just exhausted from the cycle.
numactive -= 1
nexts = cycle(islice(nexts, numactive
Tim Peters added the comment:
I have no opinion about any version of xxxBSD, because I've never used one ;-)
If current versions of those do have this failure, has anyone opened a bug
report on _their_ tracker(s)? I've seen no reason yet to imagine these
failures are a fault
Tim Peters added the comment:
Best I can tell, the fdlibm 5.3 on netlib was released in 2002, and essentially
stopped existing as a maintained project then. Everyone else copied the source
code, and made their own changes independently ever since :-( At least the
folks behind the Julia
Tim Peters added the comment:
Tomáš, of course you can combine testing methods any way you like. Don't
oversell this - there's nothing actually magical about comparing objects
instead of strings ;-)
I'm only -0 on this. It grates a bit against doctest's original intent
Tim Peters added the comment:
`doctest` is intended to be anal - there are few things more pointlessly
confusing for a user than to see docs that don't match what they actually see
when they run the doc's examples. "Is it a bug? Did I do it wrong? Why can't
they docum
Tim Peters added the comment:
Pass "autojunk=False" to your SequenceMatcher constructor and the ratio you get
back will continue to increase as `i` increases.
The docs:
"""
Automatic junk heuristic: SequenceMatcher supports a heuristic that
automatically treats
Tim Peters added the comment:
Oops! I mixed up `sin` and `cos` in that comment. If it's argument reduction
that's broken, then for x near pi/2 cos(x) will be evaluated as -sin(x - pi/2),
which is approximately -(x - pi/2), and so error in argument reduction (the "x
- pi/2&q
Tim Peters added the comment:
Since fdlibm uses tan(x) ~= -1/(x-pi/2) in this range, and the reciprocals of
the bad results have a whole of bunch of trailing zero bits, my guess is that
argument reduction (the "x-pi/2" part) is screwing up (losing bits of pi/2
beyond the long
Tim Peters added the comment:
BTW, has anyone tried running a tiny C program on these platforms to see what
tan(1.5707963267948961) delivers? The kind of code fdlibm uses is sensitive
not only to compiler (mis)optimization, but also to stuff like how the FPU's
"precision contr
Tim Peters added the comment:
Segfaults are different: they usually expose an error in CPython's
implementation. We don't prioritize them because the user may have to restart
their program (who cares? <0.5 wink>), but because they demonstrate the
language implementation is
Tim Peters added the comment:
On 16 Oct 2017, exactly the same test failures were reported on python-dev:
https://mail.python.org/pipermail/python-dev/2017-October/149880.html
>From the test output posted there:
"""
== CPython 3.6.3 (default, Oct 16 2017, 14:42:21) [GCC 4.7
Tim Peters added the comment:
Sure! The OP was obviously asking about the engine that ships with Python, so
that's what I talked about.
Raphaël, Matthew develops an excellent replacement ("regex") for Python's re
module, which you can install via, e.g., "pip insta
Tim Peters added the comment:
Well, the problem in the regexp is this part: "\d+,? ?". You're not
_requiring_ that strings of digits be separated by a comma or blank, you're
only _allowing_ them to be so separated. A solid string of digits is matched
by this,
Tim Peters added the comment:
I'll just add that it may be a different issue to argue about how
`_naive_is_dst()` is implemented.
--
nosy: +belopolsky
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
Since this is a pretty common gotcha, I'd prefer to add it as an example to the
text I already quoted; e.g., add:
"""
For example, the native Windows C libraries do not support times before the
epoch, and `localtime(n)` for negative `n`
Tim Peters added the comment:
The docs for the `time` module say:
"""
Although this module is always available, not all functions are available on
all platforms. Most of the functions defined in this module call platform C
library functions with the same name. It may sometime
Tim Peters added the comment:
When Sun was developing fdlibm, I was (among other things) working on a
proprietary libm for Kendall Square Research. I corresponded with fdlibm's
primary author (KC Ng) often at the time. There's no way he would have left
errors this egregious s
Tim Peters added the comment:
Thanks for tanny-openbsd.txt, Serhiy! OpenBSD didn't get anywhere close to the
best answer on any of those 201 inputs. I was hoping we could, e.g., test
something a little more removed from pi/2 - but even its best cases in this
range are hundreds of mil
Tim Peters added the comment:
If someone opens a bug report with OpenBSD, or just for us to get more info, it
could be useful to have a larger universe of troublesome tan inputs to stare
at. So the attached tanny.py supplies them, testing all inputs within 100 ulps
of math.pi/2 (or change N
Tim Peters added the comment:
Ah! So it looks like OpenBSD took its math functions from Sun's fdlibm. I
believe wxMaxima does too. That would certainly explain why they give the same
answer ;-)
So who's right? Using "bigfloats" in wxMaxima and feeding its bigfl
Tim Peters added the comment:
Of course the relationship is extremely delicate near pi/2. On my Windows
Python 3:
>>> import math
>>> (1.5707963267948961).hex()
'0x1.921fb54442d16p+0'
>>> math.tan(float.fromhex('0x1.921fb54442d16p+0')) # what t
Tim Peters added the comment:
Note that 2am doesn't exist on the local clock: it leaps from 1:59:59 to
3:00:00. You're claiming that one answer is "correct", but why? The relevant
_standards_ don't appear to specify what happens when the input is senseless.
Not
Tim Peters added the comment:
The text/binary distinction you have in mind doesn't particularly apply to
difflib: it compares sequences of hashable objects. "Text files" are
typically converted by front ends to lists of strings, but, e.g., the engine is
just as happy comp
Tim Peters added the comment:
I'm not familiar with `icdiff` - it's not part of the Python distribution,
right? If so, you should really talk to its author(s).
If two files have different line endings, then no pair of lines between them
can be equal, and the difference engine wil
Tim Peters added the comment:
Ya, it's clearly best for `current_thread()` to deliver consistent results.
--
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
Is there a problem here? I haven't heard of anyone even wondering about this
before. threading.py worries about Threads created _by_ threading.py, plus the
magical (from its point of view) thread that first imports threading.py. Users
mix in `_thread` th
Tim Peters added the comment:
[Guido]
> Why was task management ever added?
Raymond published a "joinable" queue class as a recipe here:
http://code.activestate.com/recipes/475160-taskqueue/
and later folded it into the standard Python queue. So the usual answer
applies: &q
Tim Peters added the comment:
@Rajath, I suspect Raymond may have been bamboozled because your suggested
`heapfix()` and `heapremove()` didn't appear to take any arguments. If the
index is a required argument, then these are O(log N) operations.
I thought about adding them years ago
Tim Peters added the comment:
Yes, I'm closing as not-a-bug. It's been this way (and documented) forever.
More specifically, as the docs say, a raw string can't end with an _odd_ number
of backslashes:
"""
String quotes can be escaped with a backslash, bu
Tim Peters added the comment:
This isn't a bug. 84 appears twice in the list, the first time at index 9.
The .index() method finds the first (leftmost; smallest index) occurrence.
Since 9 isn't even, the `if` test isn't satisfied, so 84 does not appear in the
result.
Tim Peters added the comment:
Victor, this part of the docs explains what you're seeing; scroll down to the
"""
In enforcing reflexivity of elements, the comparison of collections assumes
that for a collection element x, x == x is always true ...
"""
part.
Tim Peters added the comment:
Not a bug. For an explanation, I just answered a very similar question on
StackOverflow:
https://stackoverflow.com/questions/45180899/unexpected-result-from-in-operator/45180967#45180899
--
nosy: +tim.peters
Tim Peters added the comment:
Ya, prior to now ;-) there's generally been some cost-benefit thought given to
these things. Strings and ints are immutable and some values of each are
uniquely interned, so the case of identity is more than just plausible. It
happens often.
I'd gues
Tim Peters added the comment:
Measuring in isolation (like with, e.g., timeit) isn't really interesting.
Then everything is in L1 cache, branches are 100% predictable (because they
take the same branch over & over for the duration of the test), and
second-order effects on _other_
Tim Peters added the comment:
This is an unfortunate consequence of the default "autojunk" feature. You can
turn that off by passing `autojunk=False`, like so:
match = SequenceMatcher(None, string1, string2, auto
Tim Peters added the comment:
Just noting that every special code path "at the start" doesn't just speed the
case it's aiming at, it also _slows_ every case that doesn't pass the new
tests. It takes time to fail the new tests. So it usually makes things slower
over
Tim Peters added the comment:
I agree closing was appropriate at this time. I quite like PCG, but as Raymond
said it's more a template for creating PRNGs than a specific generator. So
even if a compelling case could be made, there's still a long way to having
specific code in min
Tim Peters added the comment:
Oops! I undercounted the shifts in the current scheme: there's an additional
shift for "perturb". That doesn't exist in the "double hashing" alternatives.
--
___
Python tracker
<
Tim Peters added the comment:
I suggest reading the thread I started here[1] before pursuing this: it looks
very likely that the entire collision resolution scheme should be replaced with
one of the "double hashing" ones given there, a bona fide algorithmic
improvement for small
Tim Peters added the comment:
Actually, there is something to be gained here, for smaller tables. The simple
formulas for the expected number of probes under uniform hashing are upper
bounds, and are significantly overstated when the load factor is very high (not
a concern for Python) or the
Tim Peters added the comment:
BTW, I should have spelled this out earlier: recall that x and y collide on
the first probe if and only if
x = y (mod 2**k) [1]
The second probe never happens unless they do collide on the first probe, so
when looking at the second probe we can assume
Tim Peters added the comment:
Dmitry, I suggest you spend more of the time you give to thinking to writing
code instead ;-) But, really, that's the easiest & surest way to discover for
yourself where your analysis is going off in the weeds.
For example, issue 28201 was both simpler
Tim Peters added the comment:
I don't see a reason to keep this open, but I haven't been able to follow the
OP's line of argument. My best _guess_ is that they're chasing illusions based
on not understanding (or grossly undervaluing) that the primary point of the
Tim Peters added the comment:
The attached hashsim.py pretty much convinces me there's nothing left to be
gained here. It shows that the current scheme essentially achieves the
performance of theoretical "uniform hashing" for string keys, for both
successful and unsuccessf
Tim Peters added the comment:
Yes, any scheme whatsoever that guarantees to visit every int in range(2**i)
meets the "correctness" part.
But I concur with Inada: "head arguments" aren't compelling here, not even if
I understood what they were saying ;-) If you imp
Tim Peters added the comment:
Whatever the iteration, accept that it's necessary it reach every value in
range(2**i) eventually. The current scheme does that, for reasons already
documented. You seem to be overlooking the importance of this part:
"""
Note that because
Tim Peters added the comment:
Users certainly have been fooled by this, although "unpacking" is a red
herring. I've been burned by it, and I've seen StackOverflow puzzles related
to the same thing. I think this is the heart of it: given a finite iterable
I, it usual
Tim Peters added the comment:
Generally speaking, trying to shuffle a dict D already blows up, unless D's
keys are the integers range(len(D)). In that case, D is indistinguishable from
a list in the sense that both map range(N) to values via __getitem__.
`shuffle()` does no type c
Tim Peters added the comment:
I already commented on github - +1 for this change.
--
nosy: +tim.peters
___
Python tracker
<http://bugs.python.org/issue30
Tim Peters added the comment:
Yes, that example takes time exponential in the number of blanks to (fail to)
match - each time you add a blank to `input`, it essentially doubles the time
required.
It's _possible_ for an implementation to deduce that `(\s+)+` is an insanely
inefficient w
Tim Peters added the comment:
Again, I don't care about orphans. In the usual cases people are running code
with no concern about what happens in case of forced termination. The only
thing stopping it now is that the code goes out of its way to prevent it (or,
alternatively, goes out o
Tim Peters added the comment:
@Eryk, not me ;-) I find the "daemonic or not?" distinction useless for
processes - it just gets in the way at times (e.g., a Pool worker dies with an
assert(!) error if it tries to create its own Pool for something).
I don't care about orphans ei
Tim Peters added the comment:
I'll take a crack at these ancient comments ;-)
"""
daemon
The process’s daemon flag, a Boolean value. This must be set before start()
is called.
The initial value is inherited from the creating process. [1]
When a process e
Tim Peters added the comment:
So there's more than one issue here.
First, should asserts be supported in the absence of Py_DEBUG? It seems, so
far, everyone agrees they should be.
Second, ...? I'm really not following your argument. It _appears_ to be
something along the lines
Tim Peters added the comment:
I think we should certainly support asserts regardless of whether Py_DEBUG is
in force (although Py_DEBUG should imply asserts run too).
And I wish you had stuck to just that much ;-) The argument against, e.g.,
'assert(!PyErr_Occurred())', seems e
Tim Peters added the comment:
See also:
https://en.wikipedia.org/wiki/Hamming_weight
As that says, there are a number of languages and processors with first class
support for a popcount function. I've frequently implemented it in Python when
using integers as integer bitsets (`i`
Tim Peters added the comment:
@ppperry, I believe you're right - good catch! I expect the current patch
would treat the NotImplemented return as meaning "the first argument is less
than the second argument".
I added a comment to the code (on github) suggesting an obvio
Changes by Tim Peters :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29797>
___
___
Tim Peters added the comment:
I think this is expected. Add this as the first line of `simulate()` and the
problem should go away:
q.cancel_join_thread()
As the docs say, a Queue works with a background thread, which feeds incoming
data from an internal buffer to a (interprocess) pipe
Tim Peters added the comment:
Elliot, PyObject_RichCompareBool calls PyObject_RichCompare. That in turn does
some checks, hides a small mountain of tests in the expansions of the
recursion-checking macros, and calls do_richcompare. That in turn does some
useless (in the cases you're a
Tim Peters added the comment:
The impact would be small: it would add one (or so) pointer-equality compare
that, in practice, will always say "yup, they're equal". Dirt cheap, and the
branch is 100% predictable.
--
___
Python
Tim Peters added the comment:
Elliot, did you run the example in a release build or a debug build? I'm
wondering why this:
assert(v->ob_type == w->ob_type &&
v->ob_type->tp_richcompare != NULL &&
v->ob_type->tp_richcompare == compa
Tim Peters added the comment:
Elliot, I don't care if the example behaves differently. Although someone else
may ;-)
The only things `.sort()` has ever tried to guarantee in the presence of
mutations (of either the list or the elements) during sorting are that (a) the
implementation
Tim Peters added the comment:
@ppperry, I have no idea what the bulk of the code in typeobect.c is trying to
do.
--
___
Python tracker
<http://bugs.python.org/issue28
Tim Peters added the comment:
I haven't tried the example, but at this point I'd be surprised if it failed.
The caching here isn't at level of `__lt__` but at the higher level of
(invisible from Python code) a type's tp_richcompare slot. A heap type -
regardless of wheth
Tim Peters added the comment:
Your last line can't possibly return True, because `somelist.reverse()` returns
None.
So the last line is irrelevant. Your complaint appears to be about the line
before, which shows that the list retains its original order.
That's expected. All th
Tim Peters added the comment:
I can't judge a use case for a thread gimmick in the absence of wholly
specified examples. There are too many possible subtleties. Indeed, if I'd do
anything with Event.clear() it would be to remove it - I've seen too much code
that suffers s
New submission from Tim Peters:
They already are.
>>> (-2)**0
1
You're probably doing this instead:
>>> -2**0
-1
Exponentiation has higher precedence than unary minus, so that last example
groups as -(2**0), and -1 is correct.
--
nosy: +tim.peters
resoluti
Tim Peters added the comment:
I also don't see a good reason to keep this open now - adds complication for no
quantifiable payoff.
--
___
Python tracker
<http://bugs.python.org/is
Tim Peters added the comment:
Yes, it's both intended and annoying ;-) The standard specifies that, by
default, comparisons involving NANs are "unordered": a NAN is _none_ of "less
than", "equal to", or "greater than" any other float, i
Tim Peters added the comment:
This won't be changed - it's a near-universally mandated behavior across
relevant standards. Many years ago it wasn't, but Knuth changed minds when he
wrote:
"""
We must define x^0=1 for all x, if the binomial theorem is to be valid
Tim Peters added the comment:
This has nothing to do with the _values_ you're passing - it has to do with the
length of the pickle string:
def _send_bytes(self, buf):
n = len(buf)
# For wire compatibility with 3.2 and lower
header = struct.pack("!i&
Tim Peters added the comment:
I think Raymond will have to chime in. I assume this is due to the
`letter_range` portion of the test suffering hash randomization dealing it a
bad hand - but the underlying string hash is "supposed to be" strong regardless
of seed. The
self.ass
Tim Peters added the comment:
It's fine. Read the docs. "s.insert(i, x) inserts x into s at the index given
by i (same as s[i:i] = [x])"
Note that:
>>> fred[-1:]
[4]
So the empty slice s[-1:-1] is _between_ 3 and 4 in `fred`. If you're not
surprised by
>&
Tim Peters added the comment:
LGTM! Ship it :-)
--
___
Python tracker
<http://bugs.python.org/issue28201>
___
___
Python-bugs-list mailing list
Unsubscribe:
701 - 800 of 1332 matches
Mail list logo
