Facundo Batista wrote:
> 2008/3/25, Mark Dickinson <dickinsm at gmail.com>:
>
>> So int and float accepts bytes, while complex, Decimal and Fraction do
>> not...
>
> I'm -1 to accept bytes as input for Decimal, I don't see a case of
> use, and I think that conceptually there's no reason to do it.
>
> Of course, I can be wrong, ;)
I was thinking converting directly from bytes would be significantly
quicker than going through Unicode (e.g. for numbers read from a file),
but that may not actually be the case (it'll definitely be faster
because there is less data copying and movement involved, but the speed
difference may be less dramatic than I first thought). So while the
internal storage of the mantissa definitely needs to be changed to a
bytes object in order to retain Mark's hard-won performance
improvements, the case of whether or not to accept bytes is far less clear.
The way I see it either complex, Decimal and Fraction all need to be
updated to accept bytes objects, or else int and float need to be
updated to reject them.
It *definitely* needs to be possible to convert bytes objects to
integers as if they were ASCII strings - otherwise a lot of wire
protocol processing would become a nightmare. Indeed, the proposed
change to Decimal to have it store the mantissa as a bytes object in
Py3k assumes that it will still be possible to convert that value
directly to a long object.
Since we have some strong use cases at least for the bytes->int case,
consistency then suggests that the other numeric types should all accept
bytes as well (interpreting them as ASCII encoded strings).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4