Changes by Mark Dickinson [EMAIL PROTECTED]:
--
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2483
__
___
Python-bugs-list mailing list
Mark Dickinson [EMAIL PROTECTED] added the comment:
Closing this: the consensus seems to be that things are fine as they
are.
See the thread at
http://mail.python.org/pipermail/python-3000/2008-April/013100.html
for discussion.
--
resolution: - invalid
Gabriel Genellina [EMAIL PROTECTED] added the comment:
Are numbers so special to break
the rules? why stopping here?
what about other types that may
want to accept ASCII bytes
instead of characters? Isn't
this like going back to the 2.x
world?
The protocol with embedded ASCII
numbers
Nick Coghlan [EMAIL PROTECTED] added the comment:
Agreed - I've been convinced that the right thing to do is reject bytes
in int() and float() as well.
If we decide we still want to support a fast-path conversion it should
be via separate methods (e.g an int.from_ascii class method and an
New submission from Mark Dickinson [EMAIL PROTECTED]:
In 3.0, the int and float constructors accepts bytes instances as well as
strings:
int(b'1')
1
float(b'1')
1.0
but the complex constructor doesn't:
complex(b'1')
Traceback (most recent call last):
File stdin, line 1, in module
Nick Coghlan [EMAIL PROTECTED] added the comment:
I have a couple of use cases for bytes-as-ASCII-text - int, one of
which also touches on floats. The other numeric types also accepting
bytes as representing ASCII encoded strings would then follow from a
consistency of behaviour argument.
Use
Mark Dickinson [EMAIL PROTECTED] added the comment:
For both these use cases, don't you still have a problem going
the other way, from an integer back to bytes? Is there an easier way
than
bytes(str(n), 'ascii')
?
__
Tracker [EMAIL PROTECTED]
