open(False) in python3

[Gabriel Genellina]

En Tue, 11 May 2010 18:40:36 -0300, geremy condra <debatem1 at 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