[issue41421] Random.paretovariate sometimes raises ZeroDivisionError for small alpha
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 resolution and given that that code has been unchanged for at least 18 years I doubt anyone else has ever run into this problem. I do think it would be beneficial to document the range of reasonable alpha on paretovariate - the lack of such documentation is the only reason I hit this at all - but I think leaving the behaviour as is would be fine. -- ___ Python tracker <https://bugs.python.org/issue41421> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41421] Random.paretovariate sometimes raises ZeroDivisionError for small alpha
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, in that it happens with probability c ** alpha for some c. -- ___ Python tracker <https://bugs.python.org/issue41421> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41421] Random.paretovariate sometimes raises ZeroDivisionError for small alpha
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 That specific stack trace is from 3.8.5 but I've tried this on 3.6 and 3.7 as well. It's a little hard to tell what the intended correct range of parameter values is for paretovariate, and this may just be lack of validation for the alpha < 1 case - perhaps that was never intended to be supported? Based on some very informal inspection, what seems to happen is that the probability of getting a ZeroDivisionError approaches one as you approach zero. They rarely occur at this level of alpha (0.01), but for alpha=0.001 they seem to occur just under half the time, and for alpha=0.0001 they occur more than 90% of the time. (For the interested, this bug was found by Hypothesis as part of its own testing of our integration with the Random API) -- components: Library (Lib) messages: 374516 nosy: David MacIver priority: normal severity: normal status: open title: Random.paretovariate sometimes raises ZeroDivisionError for small alpha versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue41421> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34009] Document Travis CI / Ubuntu 14.04 OpenSSL compatibility issues
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 example of making it work. -- ___ Python tracker <https://bugs.python.org/issue34009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34009] Document Travis CI / Ubuntu 14.04 OpenSSL compatibility issues
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, this doesn't work either. The xenial environment is an experimental feature and doesn't work at all reliably. At the time of this writing setting "dist: xenial" actually puts you into Trusty. Currently the viable ways of making it work on Travis are to either run a custom docker image (which requires you to opt out of their containerized builds and thus makes everything slower), or to build OpenSSL yourself (and making the latter work correctly is a far from straightforward process). -- nosy: +David MacIver ___ Python tracker <https://bugs.python.org/issue34009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31958] UUID versions are not validated to lie in the documented range
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.python.org/issue31958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31958] UUID
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 the version lies in that range if you don't pass a version to the constructor and, as a result, this isn't actually true - the version number can be anything between 0 and 15. For an example consider the following: >>> from uuid import UUID >>> u = UUID(int=1133377179260751706062848) >>> u.variant 'specified in RFC 4122' >>> u.version 15 I have only actually run this example on Python 3.6, but inspection of the code suggests that it's been like this since its introduction. -- components: Library (Lib) messages: 305636 nosy: David MacIver priority: normal severity: normal status: open title: UUID versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31193] re.IGNORECASE strips combining character from lower case of LATIN CAPITAL LETTER I WITH DOT ABOVE
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> <http://bugs.python.org/issue31193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31193] re.IGNORECASE strips combining character from lower case of LATIN CAPITAL LETTER I WITH DOT ABOVE
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 case i without
the required combining character. The attached file demonstrates this. I've
tested this on Python 3.6.1 with my locale as ('en_GB', 'UTF-8') (I don't know
whether that matters for reproducing this, but I know it can affect how
lower/upper work so am including it for the sake of completeness).
The problem does not reproduce on Python 2.7.13 because on that case
chr(304).lower() is 'i' without the combining character, so it fails earlier.
This is presumably related to #12728, but as that is closed as fixed while this
still reproduces I don't believe it's a duplicate.
--
components: Library (Lib)
files: casing.py
messages: 300219
nosy: David MacIver
priority: normal
severity: normal
status: open
title: re.IGNORECASE strips combining character from lower case of LATIN
CAPITAL LETTER I WITH DOT ABOVE
versions: Python 3.6
Added file: http://bugs.python.org/file47080/casing.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31193>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29792] "Fatal Python error: Cannot recover from stack overflow." from pure Python code
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.org/issue29792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29792] "Fatal Python error: Cannot recover from stack overflow." from pure Python code
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 Python 2.7 it instead hangs indefinitely. Obviously this code is stupid and shouldn't be expected to do anything very reasonable - It's shrunk down from what was probably just a bug on my end in a larger example - but it seemed like it might be symptomatic of a more general class of problems. -- files: recursionerror.py messages: 289441 nosy: David MacIver priority: normal severity: normal status: open title: "Fatal Python error: Cannot recover from stack overflow." from pure Python code versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file46720/recursionerror.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25843] lambdas on the same line may incorrectly share code objects
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...@bugs.python.org> <http://bugs.python.org/issue25843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25177] OverflowError in statistics.mean when summing large floats
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 _sum(data)/n File "/home/david/.pyenv/versions/3.5.0/lib/python3.5/statistics.py", line 184, in _sum return T(total) File "/home/david/.pyenv/versions/3.5.0/lib/python3.5/numbers.py", line 291, in __float__ return self.numerator / self.denominator OverflowError: integer division result too large for a float If this is intended behaviour then it is not documented: https://docs.python.org/3/library/statistics.html#statistics.mean only specifies that it may raise StatisticsError. -- components: Library (Lib) messages: 251076 nosy: David MacIver priority: normal severity: normal status: open title: OverflowError in statistics.mean when summing large floats versions: Python 3.4, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25177] OverflowError in statistics.mean when summing large floats
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 this error: statistics.mean([sys.float_info.max, sys.float_info.max]), this should return sys.float_info.max (which is definitely representable!), but instead raises this overflow error. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__
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 things. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23757 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__
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 verified this on both python 2.7 and python 3.4. It's presumably also the case on everything in between. This was found because it caused a bug with a type that pytz uses, which lazily populates the list on iteration: https://bugs.launchpad.net/pytz/+bug/1435617 -- components: Library (Lib) files: listwithiter.py messages: 239098 nosy: David MacIver priority: normal severity: normal status: open title: tuple function gives wrong answer when called on list subclass with custom __iter__ versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file38663/listwithiter.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23757 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__
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 checked right now). This suggests that the problem is in what tuple is doing, not in some general iterator protocol, -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23757 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
