En Tue, 11 May 2010 18:40:36 -0300, geremy condra <debat...@gmail.com>
escribió:
I'm unsure if this qualifies as a bug (it is also clearly user error)
but I just
ran into a situation where open() was inadvertantly called on a False,
and I was somewhat surprised to see that this didn't bail horribly, but
rather hung forever. Here's some example sessions for python3.x and
python2.x:
<redacted>@<redacted>:~$ python3
Python 3.1.2 (r312:79147, Apr 15 2010, 12:35:07)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
f = open(False)
f.read()
^CTraceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyboardInterrupt
open() in Python 3 does a lot of things; it's like a mix of codecs.open()
+ builtin open() + os.fdopen() from 2.x all merged together. It does
different things depending on the type and quantity of its arguments, and
even returns objects of different types.
In particular, open(some_integer) assumes some_integer is a file
descriptor and return some variant of file object using the given file
descriptor.
Now, False is an instance of bool, a subclass of int, and is numerically
equal to 0:
p3> isinstance(False, int)
True
p3> False==0
True
so open(False) is the same as open(0), and 0 is the file descriptor
associated to standard input. The program isn't hung, it's just waiting
for you to type some text:
p3> f = open(False)
p3> f.read()
Type some text
^Z
^Z
'Type some text\n'
p3>
Should I chalk this up to stupid coder syndrome or file a bug report?
Uhm, perhaps the bug is, bool should not inherit from int in Python 3, but
it's way too late to change that.
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
