Tim Peters added the comment:
Stuff like that happens in any language supporting a tell() function for a file
opened in text mode on Windows, inherited from the platform C's ftell()
implementation:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/ftell-ftelli64?view=vs
Tim Peters added the comment:
I have no use for this either, and agree with rejecting it - in nearly 30
years, nobody has asked for this before, and it's still the case that we don't
have an actual programming use case (some theoretical use in an abstract
mathematical mod
Tim Peters added the comment:
Jurjen, the errors you see in Python's sin() are _entirely_ due to your
platform C's libm. Python just calls the platform C's sin. So nothing can be
said about it in general.
The better libm trig functions today do indeed perform trig argument
New submission from Tim Burke :
While the RFCs are rather clear that non-ASCII data would be out of spec,
* that doesn't prevent a poorly-behaved client from sending non-ASCII bytes on
the wire, which means
* as an application developer, it's useful to be able to mimic such a client
Tim Peters added the comment:
I'm at best -0 on this, and on the edge of -1. We already supply
mutate-in-place operations for when this is wanted, and, e.g., for lists, it's
as dead easy to spell as
L1 += L2
Half the point of the hack for string catenation was that the simil
Tim Peters added the comment:
Brandt, it's quite possible I have no real idea what this patch is aimed at. I
didn't reverse-engineer the code, the title is extremely broad, and there are
no Python examples I can find for what it _is_ aimed at. If, e.g., it's
impossible that
Tim Peters added the comment:
Serhiy, if I understand this, it _could_ pay big with even just a few
operations. For example,
[0] * 100 + [1] + [2] + [3]
As-is, we'll copy the million zeroes three times. WIth the patch, more likely
the original vector of a million zeroes
Change by Tim Burke :
--
keywords: +patch
pull_requests: +12288
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36274>
___
___
Python-
Change by Tim Burke :
--
pull_requests: +12289
___
Python tracker
<https://bugs.python.org/issue36274>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
Josh, I agree - but do read Armin's response. The string hack was done inside
ceval.c, where we have extraordinary knowledge of context. Adding similar
hacks inside Python C API functions seems to be a non-starter - they can't
magically star
New submission from Tim Mitchell :
The new functools.singledispatchmethod (issue32380) class interacts poorly with
subclasses.
There is no way for a sub-class to override or extend the dispatch registry.
E.g.
class BaseVistor:
@singledispatchmethod
def visit(self, obj):
raise
Tim Peters added the comment:
I'm inclined to agree with Mark - the wholly naive algorithm is already
"perfect" away from extreme (whether large or small) magnitudes, and can't be
beat for speed either. This kind of thing gets much more attractive in IEEE
single prec
New submission from Tim Hatch :
The grammar in lib2to3 is out of date and can't parse `:=` nor `f(**not x)`
from running on real code. I've done a cursory `diff -uw Grammar/Grammar
Lib/lib2to3/grammar.txt`, and would like to fix lib2to3 so we can merge into
both fissix and bl
Change by Tim Hatch :
--
pull_requests: +12627
___
Python tracker
<https://bugs.python.org/issue36541>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Hatch added the comment:
jreese reminded me of pep570, which will make more grammar changes. I'm open
to the idea of replacing the grammar with the live one, plus porting the 2isms
forward like print, eval, except with comma.
My sincere hope is that everyone that depends on
Tim Hatch added the comment:
Here's approximately what it would look like to do the big change now:
https://github.com/python/cpython/compare/master...thatch:lib2to3-update-grammar
(one test failing, and some helpers may need more test cov
Tim Mitchell added the comment:
Attached is an improved implementation that does not use a module level
register() function.
It makes the code in the original post work as expected: The
`@BaseVisitor.visit.register()` decorator on the `AVisitor` class does not
modify the base class
Change by Tim Hatch :
--
nosy: +thatch
___
Python tracker
<https://bugs.python.org/issue36607>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Hatch added the comment:
My strong preference would be getting the lib2to3 grammar to be the python
grammar + additions, to make future changes easier to merge. The strongest
argument against doing that is the backwards-incompatibility of patterns --
some won't compile, while o
Tim Hatch added the comment:
Also see discussion about divergence on issue36541
--
nosy: +thatch
___
Python tracker
<https://bugs.python.org/issue33348>
___
___
Tim Golden added the comment:
Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 03:37:03) [MSC v.1900 64 bit
(AMD64)] on win32
I can't reproduce this on Windows. And it does seem an unlikely combination of
effect and cause.
Do I take it that if you take out all the "logging...&q
Tim Peters added the comment:
+1 from me! I'm tired of re-inventing this too :-)
Agree with every point Mark made.
Just in passing, noting a triviality: for the ceiling, `1 + isqrt(n - 1)`
fails when `n` is zero.
But I've never had a use for the ceiling here, or for "near
Tim Peters added the comment:
Note that this pure Python gives the same result:
>>> "%.0f" % float(1639873214337061279)
'1639873214337061376'
That's not surprising: int -> float conversion is limited to the precision of
a Python float, which is a C doub
Tim Peters added the comment:
It sounds like you need to read an introduction (any!) to computer
floating-point formats. The relevant part in the output you showed is this:
mant_dig=53
As on almost other current machines, your platform's floating point format is
restricted to 53 bi
Change by Tim Peters :
--
nosy: +noam, tim.peters
___
Python tracker
<https://bugs.python.org/issue26092>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
Noam Yorav-Raphael, I tried to add you because this is pushing back against
your patch in issue 8408. It's been some years now, and nobody has cared
enough to pursue it, so I'll just close this if you still don't care ;-)
As doctest'
Tim Peters added the comment:
Oops! Should be issue 8048.
--
___
Python tracker
<https://bugs.python.org/issue26092>
___
___
Python-bugs-list mailing list
Unsub
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
New submission from Tim Morris :
In the HOWTO for urllib2 for Python 2, in the Handling Exceptions section, it
discusses the URLError exception being raised by urlopen()
(https://docs.python.org/2/howto/urllib2.html#urlerror). The code snippet
example for this has (I think) a minor error:
the
Change by Tim Smith :
--
nosy: +tdsmith
___
Python tracker
<https://bugs.python.org/issue32616>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
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
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 Graham added the comment:
The last commit that added the deprecation warning needs to be added to the 3.7
branch.
--
nosy: +Tim.Graham
___
Python tracker
<https://bugs.python.org/issue25
Tim Graham added the comment:
It might be worth adding part of the problematic regex to the warning message.
For Django's tests, I see an error like "FutureWarning: Possible nested set at
position 17 return re.compile(res).match". It took some effort to track down
the sou
New submission from Tim Graham :
As discussed in issue30349#msg311684, fnmatch.translate() can produce a pattern
which emits a nested set warning:
>>> import fnmatch, re
>>> re.compile(fnmatch.translate('[[]foo]'))
__main__:1: FutureWarning: Possible nested set at
Tim Graham added the comment:
Okay, I created #32775.
--
___
Python tracker
<https://bugs.python.org/issue30349>
___
___
Python-bugs-list mailing list
Unsub
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
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:
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:
> 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:
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:
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:
> 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:
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:
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, 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:
[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:
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:
Serhiy, nobody is proposing to add float.as_integer(). It already exists:
>>> (3.1).is_integer()
False
I already allowed I don't have a feel for how _generally_ useful it is, but you
have at least my and Stefan's word for that the functionali
Tim Peters added the comment:
If you want to deprecate the method, bring that up on python-dev or
python-ideas. It's inappropriate on the issue tracker (unless, e.g., you open
a new issue with a patch to rip it out of the language). It's also
inappropriate to keep on demanding
Tim Peters added the comment:
This won't be changed. The dict type doesn't support efficient random choice
(neither do sets, by the way), and it's been repeatedly decided that it would
do a disservice to users to hide that. As you know, you can materialize the
keys in a
Tim Peters added the comment:
I'd be +1 on generalizing math.hypot to accept an arbitrary number of
arguments. It's the natural building block for computing distance, but the
reverse is strained. Both are useful.
Here's scaling code translated from the Fortran implementat
Tim Peters added the comment:
Some notes on the hypot() code I pasted in: first, it has to special case
infinities too - it works fine if there's only one of 'em, but returns a NaN if
there's more than one (it ends up computing inf/inf, and the resulting NaN
propagates).
S
Tim Peters added the comment:
Mark, thanks! I'm happy with that resolution: if any argument is infinite,
return +inf; else if any argument is a NaN, return a NaN; else do something
useful ;-)
Serhiy, yes, the scaling that prevents catastrophic overflow/underflow due to
naively squ
Tim Peters added the comment:
Mark, how about writing a clever single-rounding dot product that merely
_detects_ when it encounters troublesome cases? If so, it can fall back to a
(presumably) much slower method. For example, like this for the latter:
def srdp(xs, ys):
"S
Tim Peters added the comment:
Please see the response to issue31889. Short course: you need to pass
`autojunk=False` to the SequenceMatcher constructor.
--
nosy: +tim.peters
resolution: -> duplicate
stage: -> resolved
status: open -&g
Tim Peters added the comment:
factorial(float) was obviously intended to work the way it does, so I'd leave
it alone in whatever changes are made to resolve _this_ issue. I view it as a
harmless-enough quirk, but, regardless, if people want to deprecate it that
should be a different
Tim Peters added the comment:
There's nothing in the docs I can see that implies `sample(x, n)` is a prefix
of what `sample(x, n+1)` would have returned had the latter been called
instead. If so, then - as always - it's "at your own risk" when you rely on
behavio
Tim Peters added the comment:
I don't see anything objectionable about the class optimizing the
implementation of a private method.
I'll note that there's a speed benefit beyond just removing the two type checks
in the common case: the optimized `_randbelow()` also avoids
Tim Peters added the comment:
I'm the wrong guy to ask about that. Since I worked at Zope Corp, my natural
inclination is to monkey-patch everything - but knowing full well that will
offend everyone else ;-)
That said, this optimization seems straightforward to me: two distinct m
Tim Peters added the comment:
Sounds good (removing \b) to me, Terry!
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue33204>
___
___
Pytho
New submission from Tim Shaffer :
The documentation for ConfigParser.items(section, raw=False, vars=None) says
the following:
> Changed in version 3.2: Items present in vars no longer appear in the result.
> The previous behaviour mixed actual parser options with variables provided
Change by Tim Shaffer :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue33251>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Peters added the comment:
I agree this isn't a bug (and it was right to close it). I expect the OP is
confused about what the `.timestamp()` method does, though. This note in the
docs directly address what happens in their problematic
`datetime.utcnow().timestamp()` case:
&qu
Tim Peters added the comment:
Ned, I think this one is more the case that the OP didn't read the docs ;-)
That said, there's a level of complexity here that seemingly can't be reduced:
the distinctions between the `datetime` and `time` modules' views of the world,
and
Tim Peters added the comment:
docstrings give brief statements intended to jog your memory; they're not
intended to be comprehensive docs. Read the actual documentation and see
whether you're still confused. When you "assumed it is irrelevant to time
zone", that w
Tim Peters added the comment:
Please find a minimal example that illustrates the problem you think you've
found, and paste the plain text _into_ the bug report.
In the meantime, I'm closing this as "not a bug". The division operator
applied to integers in Python 2 defau
Tim Peters added the comment:
-1. We should stop pretending this _ might_ happen ;-)
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue33
Tim Peters added the comment:
Closing because this appears to be senseless.
--
nosy: +tim.peters
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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:
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:
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:
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:
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:
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:
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:
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 Graham added the comment:
Perhaps the reason for the undeprecation could use some clarification. In a
Python 3 only world (where Django's master branch is), I believe there's still
usefulness for inspect.getfullargspec() -- see
https://github.com/django/django/search?q=getfulla
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:
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:
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:
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:
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:
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:
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:
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:
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:
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 Chambers added the comment:
I suggest adding the option to keep the namespace prefixes in the tree when
reading in (will it need to set a tree wide variable for the instance?). I
haven't looked at the etree internals in detail.
Add a function to ElementTree that returns the tag usin
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:
`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:
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:
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:
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:
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 Graham added the comment:
This is appearing as a backwards incompatible change for Django because test
case class attributes are now evaluated at load time before setUpClass runs
(which initializes some things that those class attributes use). It's possible
to adapt Django for
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:
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:
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
1001 - 1100 of 2346 matches
Mail list logo
