[issue21227] Decimal class error messages for integer division aren't good
New submission from leewz:
Python's `decimal.Decimal` doesn't seem to like taking modulo or intdiv of
large Decimals by integers (where "large" depends on how many digits are
internally stored).
>>> from decimal import *
>>> getcontext().prec
28
>>> Decimal(10**29)%1
Traceback (most recent call last):
File "", line 1, in
decimal.InvalidOperation: []
>>> getcontext().prec=50
>>> Decimal(10**29)%1
Decimal('0')
Same for `Decimal(10**29)//1`
This is a logical problem: "Alice has a 100-digit number which begins with
1543256. What is the last digit?"
But I found the error hard to understand. Searching for "DivisionImpossible"
didn't turn up anything immediate (it wasn't added to the official docs?). I
was most of the way through writing out a question to StackOverflow when it
clicked. (Also, why is it an InvalidOperation that holds an exception as a
message? Never saw that before.)
Suggestions:
- Improve docs with further examples. The examples of InvalidOperation are
logical MATH errors (e.g. division by 0), not logical PROGRAMMING errors.
- Uh, maybe the error message could be changed to something like, "The answer
you seek lies beyond the mantissa." Or more sanely, "Not enough precision to
compute the answer." Or something else that hints to me to look into precision.
--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 216253
nosy: docs@python, leewz
priority: normal
severity: normal
status: open
title: Decimal class error messages for integer division aren't good
type: enhancement
versions: Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue21227>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21227] Decimal class error messages for integer division aren't good
leewz added the comment: Fine grained? Do you mean that the error can't be distinguished from other such errors? Or that it's difficult to attach the message to DivisionError? I thought DivisionError was always about precision. I looked up the error in libmpdec: "This occurs and signals invalid-operation if the integer result of a divide-integer or remainder operation had too many digits (would be longer than precision). The result is [0,qNaN]." (http://speleotrove.com/decimal/daexcep.html) Now I'm more confused. Though it mentions precision, it is talking about the *result's* precision being too large (something which shouldn't happen with Python's unbounded ints, right?), rather than being unable to give a sane answer due to not having *enough* digits. That's also what the 2.7 error is: decimal.InvalidOperation: quotient too large in //, % or divmod I'm very much content with documenting it, but if possible, I'd like to understand whether this is an issue to take up with libmpdec. P.S.: As a side-note to others, Python floats allows float%int even when precision isn't high enough, and seems to always returns 0.0 with no warning. So behavior is inconsistent, if that's important to anyone here. -- ___ Python tracker <http://bugs.python.org/issue21227> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21227] Decimal class error messages for integer division aren't good
leewz added the comment: Nah. I found it surprising at first, but like I said, it's like the computer is given the first 28 digits of a number and then asked to figure out the 30th digit. What I'm confused about is how it fits the definition of "division impossible" given by libmpdec's docs (about the result size), and whether you're saying it's difficult to translate the `[]` part to an error message. -- ___ Python tracker <http://bugs.python.org/issue21227> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21227] Decimal class error messages for integer division aren't good
leewz added the comment: Total list of issues now: - Error message for `DivisionImpossible` is [] instead of an actual error message. - `decimal.DivisionImpossible.__doc__` is empty. - Calling `help(decimal.DivisionImpossible)` turns up nothing useful. I checked all of these just now on my 3.2.3 (Windows). These issues are a CHANGE from 3.2 to 3.3. For example: - Old error: decimal.InvalidOperation: quotient too large in //, % or divmod - New error: InvalidOperation: [] I assume that the issues also apply to the other InvalidOperation types. So I guess what I'm really asking for is to pull forward the 3.2 docs and messages. > That doesn't mean the implementation should change. Er, I was explaining why it wasn't really surprising once I thought about it. > There may be a documentation issue, but then again, people who are > "surprised" usually haven't studied the docs in detail. To clarify: - I looked at the Decimal docs - skimmed for references to modulo and division - looked for `DivisionImpossible` - Then looked on Google for '"DivisionImpossible" Python'. - Experimented with changing precision and fooling around with bigger and smaller numbers, and realized why the operation was logically impossible. - Came here, posted, got a response that it was a flag raised by libmpdec. I'm not asking for a change in behavior. I did point out that it was inconsistent with regular floats, in case consistency with Pyfloats was a thing that mattered. But I don't care about that. I only worry about anyone else who would use Decimal coming across the same unhelpful error. > AFAICT, this particular "confusion" has never arisen before (i.e. bug > reports, questions in python classes, posts on stackoverlow, blog posts, > etc). Likewise, the issue does not seem to have ever arisen in the many > other non-Python implementations of the decimal spec. I agree it'd be (very) rare, but part of the reason why it might not appear online is that the issues at the top of this email are relatively new (3.3). -- ___ Python tracker <http://bugs.python.org/issue21227> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20426] Compiling a regex with re.DEBUG should force a recompile
New submission from leewz:
Compiling a regex with the `re.DEBUG` flag indicates that the user wants to see
the debug output. `re.compile` is cached, though, so there is the possibility
of no output.
Example:
import re
re.compile('1',re.DEBUG) #expected output
re.compile('1',re.DEBUG) #no output
re.compile('',re.DEBUG) #no output (empty regex)
The workaround is to call `re.purge()`, which may remove other cached regexes
that are still in use.
(Background: I wanted to check for equivalence of regexes, and a StackOverflow
answer suggested comparing their `re.DEBUG`.
http://stackoverflow.com/a/21398362/2963903)
--
components: Regular Expressions
messages: 209595
nosy: ezio.melotti, leewz, mrabarnett
priority: normal
severity: normal
status: open
title: Compiling a regex with re.DEBUG should force a recompile
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue20426>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25428] Have `datetime` understand integer arguments for timezones
New submission from leewz: Current: If I want to create a datetime object with a particular timezone offset, I have to do this: import datetime mytime = datetime.datetime(2015, 10, 16, 9, 13, 0, tzinfo=datetime.timezone(datetime.timedelta(hours=-7))) Or with imports: from datetime import datetime, timezone, timedelta mytime = datetime(2015, 10, 16, 9, 13, 0, tzinfo=timezone(timedelta(hours=-7))) That's two extra imports and two extra objects created. Requested way: mytime = datetime(2015, 10, 16, 9, 13, 0, tzinfo=-7) # mytime.tzinfo == -7 Or if someone doesn't like the `tzinfo` keyword: mytime = datetime(2015, 10, 16, 9, 13, 0, tzhours=-7) # mytime.tzinfo == timezone(timedelta(-7)) For timezones, hours are the normal unit of time. At least, I think about time zones in hours, and I don't know who would think about them in minutes. There are half-hour offsets, so floats make sense to have. Imagine you have about a year of experience dabbling in Python, and you're trying to do a relatively simple task, like reading PDT times and converting them to local time. You would go to the datetime docs, see that you need to pass in a tzinfo object. You look that up, and run into this: """tzinfo is an abstract base class, meaning that this class should not be instantiated directly. You need to derive a concrete subclass, and (at least) supply implementations of the standard tzinfo methods needed by the datetime methods you use.""" Well, great. If you want to convert times, you'll have to subclass an abstract base class, and implement five methods. You'd probably have to read the whole docs for this class, too. (The docs for tzinfo take nine Page Downs for me to scroll past.) If you're not frightened off by the first two sentences, you'll see that there's the concrete subclass `datetime.timezone`. We're two levels down, now. Going there, you'll see that you need to pass in a timedelta object. Three levels. You need to learn about three classes just to specify an hour offset. Timezones are something that many non-programmers understand, and the rules are pretty simple (barring DST, but the library doesn't really deal with it anyway). Ideally, it should be simple to do simple things. PS: There seems to be unnecessary inconsistency with `.astimezone`, `fromtimestamp`, and `now` taking a `tz` kwarg rather than a `tzinfo` kwarg. -- assignee: docs@python components: Documentation, Library (Lib) messages: 253111 nosy: docs@python, leewz priority: normal severity: normal status: open title: Have `datetime` understand integer arguments for timezones type: enhancement versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue25428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25428] Have `datetime` understand integer arguments for timezones
leewz added the comment: Thanks. Will visit them. -- ___ Python tracker <http://bugs.python.org/issue25428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25840] Allow `False` to be passed to `filter`
New submission from leewz: Meaning: filter(False, lst) == (x for x in lst if not x) == itertools.filterfalse(None, lst) I understand that it is a very minor enhancement, and with not much benefit. I just happened to think about it, and wondered why it didn't already exist. I figured it wouldn't hurt to put the idea out here. (If anyone is interested, I was looking into ways that filter/map/itertools could "unwrap" each other at the C level to improve composition of generators, inspired by the functools.partial optimization.) -- messages: 256218 nosy: leewz priority: normal severity: normal status: open title: Allow `False` to be passed to `filter` type: enhancement versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue25840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25840] Allow `False` to be passed to `filter`
leewz added the comment: ebarry, note that `filter(None, lst)` is equivalent to `filter(bool, lst)`, which is the opposite of `filterfalse(None, lst)`. (Though `filter(True, lst) == filter(bool, lst)` would be a parallel.) -- ___ Python tracker <http://bugs.python.org/issue25840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25956] Unambiguous representation of recursive objects
leewz added the comment: Hey, I brought this up last month in the #python channel. I suggested `[ . . . ]`. I agree that there's no great need, though. -- nosy: +leewz ___ Python tracker <http://bugs.python.org/issue25956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26809] `string` exposes ChainMap from `collections`
New submission from leewz: I don't know if this kind of thing matters, but `from string import ChainMap` works (imports from `collections). It's used internally by `string`. This was done when ChainMap was made official: https://github.com/python/cpython/commit/2886808d3809d69a6e9b360380080140b95df0b6#diff-4db7f78c8ac9907c7ad6231730d7900c You can see in the above commit that `configparser` had `_ChainMap` changed to `ChainMap as _ChainMap`, but this was not done in `string`. -- components: Library (Lib) messages: 263824 nosy: leewz priority: normal severity: normal status: open title: `string` exposes ChainMap from `collections` type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue26809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26809] `string` exposes ChainMap from `collections`
leewz added the comment:
> The fact that ChainMap pollutes namespace when doing star import ("from
> string import *"), however, is unfortunate.
This is what I meant by "this kind of thing". (IPython also ignores underscored
names for autocomplete suggestions, unless you start with an underscore.
IPython doesn't respect `__all__` by default, but that's a report for IPython's
tracker.)
> This case is the opposite: we want to limit the exported names.
(Well, not exactly the opposite. Same purpose.)
--
___
Python tracker
<http://bugs.python.org/issue26809>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26809] `string` exposes ChainMap from `collections`
leewz added the comment: (Never mind that last bit. I see it now.) > I agree that the namespace pollution is a valid bug. It affects “from string > import *” and dir(string). How do I get this behavior for `dir`? I get '_re' in `dir(string)`. -- ___ Python tracker <http://bugs.python.org/issue26809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26809] `string` exposes ChainMap from `collections`
leewz added the comment: Why not both? -- ___ Python tracker <http://bugs.python.org/issue26809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
