David MacIver added the comment:
I should say, I don't actually care about this bug at all: I only ran into it
because of trying to recreate the random API and testing that my recreation
worked sensibly. I thought I'd do the good citizen thing and report it, but I'm
totally fine with any
David MacIver added the comment:
I guess on actual inspection of the code (which I should have done before,
sorry) it's obvious why this happens: u ** (1.0 / alpha) will round to 0.0 for
small values of u, and the smaller alpha is the higher the probability of that
happening
New submission from David MacIver :
The following code raises a ZeroDivisionError:
from random import Random
Random(14064741636871487939).paretovariate(0.01)
This raises:
random.py, line 692, in paretovariate
return 1.0 / u ** (1.0/alpha)
ZeroDivisionError: float division by zero
David MacIver added the comment:
Anthony Sottile has pointed out to me that I'm wrong about the xenial thing,
and that actually it does work it's just that you need to get multiple things
right in order for it to do so.
https://github.com/deadsnakes/travis-ci-python3.7-example is a good
David MacIver added the comment:
> According to
> https://github.com/travis-ci/travis-ci/issues/9069#issuecomment-395471575,
> setting "dist: xenial" instead (giving Ubuntu 16.04) provides a testing
> environment with a new enough OpenSSL for 3.7 to work.
No, th
Change by David MacIver <david.maci...@gmail.com>:
--
title: UUID -> UUID versions are not validated to lie in the documented range
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from David MacIver <david.maci...@gmail.com>:
The documentation for the UUID module says the UUID.version field is "The UUID
version number (1 through 5, meaningful only when the variant is RFC_4122)".
However, the UUID constructor doesn't actually validate that
David MacIver added the comment:
Sure, but 'i' is a single code point. The bug is that the regex matches 'i',
not that it doesn't match the actual two codepoint lower case of the string.
--
___
Python tracker <rep...@bugs.python.org>
New submission from David MacIver:
chr(304).lower() is a two character string - a lower case i followed by a
combining chr(775) ('COMBINING DOT ABOVE').
The re module seems not to understand the combining character and a regex
compiled with IGNORECASE will erroneously match a single lower
David MacIver added the comment:
So it does. My apologies. I'll close this.
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from David MacIver:
When run under Python 3.6.0 or 3.5.1 (and presumably other versions of Python
3) the attached code fails with "Fatal Python error: Cannot recover from stack
overflow." then aborts with a core dump and an error code indicating it got a
SIGABRT.
On
David MacIver added the comment:
Note that 3.x does not correctly handle -0.0, you just have to work a bit
harder:
>>> (lambda: (-0.0, 0.0), lambda: (0.0, -0.0))[1]()
(-0.0, 0.0)
--
nosy: +David MacIver
___
Python tracker <rep...@bug
New submission from David MacIver:
The following code produces an OverflowError:
import statistics
statistics.mean([8.988465674311579e+307, 8.98846567431158e+307])
The error is:
File "/home/david/.pyenv/versions/3.5.0/lib/python3.5/statistics.py", line
293, in mean
return _s
David MacIver added the comment:
I'm not sure what you mean by float having a limit here. It's certainly finite
precision, but there is still a representable value with that finite precision
closest to the mean.
As an example where there is an obvious correct answer that will trigger
David MacIver added the comment:
Ah, I hadn't seen that. Thanks for the link.
But... is it really? They have basically the same root cause, but the general
problem seems to be hard to fix, while the specific problem here seems to be
basically don't use the concrete API here because it breaks
New submission from David MacIver:
Converting a list to a tuple appears to have an optimisation that is wrong in
the presence of subclassing to override __iter__. It ignores the user defined
iter and uses the normal list one. I've attached a file with a test case to
demonstrate this.
I've
David MacIver added the comment:
So as a data point, this problem seems to be unique to tuple. set(x), list(x),
tuple(iter(x)) all seem to work as expected and respect the overridden __iter__
(set and list were both included in the test case I attached to demonstrated
this, iter I just
17 matches
Mail list logo
