open(False) in python3
in [Python]
|
Prev: default argument
Next: py2exe help
From: geremy condra on 11 May 2010 17:40 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 >>> <redacted>@<redacted>:~$ python Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f = open(False) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: coercing to Unicode: need string or buffer, bool found >>> Should I chalk this up to stupid coder syndrome or file a bug report? Geremy Condra
From: Gabriel Genellina on 11 May 2010 18:27 En Tue, 11 May 2010 18:40:36 -0300, geremy condra <debatem1(a)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
From: Johan Förberg on 12 May 2010 04:05 On Tue, 11 May 2010 19:27:37 -0300, Gabriel Genellina wrote: > 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 That's interesting. Are there any more numbered pseudofiles? I suppose its mainly an excellent way to confuse people when you open(0).read(), but it would be interesting to know. Johan Förberg
From: Stefan Behnel on 12 May 2010 04:36 Johan F�rberg, 12.05.2010 10:05: > On Tue, 11 May 2010 19:27:37 -0300, Gabriel Genellina wrote: > >> 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 > > That's interesting. Are there any more numbered pseudofiles? I suppose > its mainly an excellent way to confuse people when you open(0).read(), > but it would be interesting to know. Standard Unix behaviour dictates that 0 is stdin, 1 is stdout, and 2 is stderr. So you can only read() from 0. Stefan
From: Christian Heimes on 12 May 2010 04:42
Johan Förberg every: > That's interesting. Are there any more numbered pseudofiles? I suppose > its mainly an excellent way to confuse people when you open(0).read(), > but it would be interesting to know. All opened files (and on Unix even network sockets, epoll queues, inotify handlers etc) have a number. It's called a file descriptor. By default stdin, stdout and stderr have the file descriptors 0, 1 and 2. The concept of file descriptors is much older than Python and not Python specific. Even shells use the numbers, e.g. "cmd >logfile 2>&1" means "write stdout to logfile, redirect and combine stderr stream with stdout". |