Re: open(False) in python3
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
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 21 means write stdout to logfile, redirect and combine stderr stream with stdout. -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
On Wed, May 12, 2010 at 1:36 AM, Stefan Behnel stefan...@behnel.de wrote: 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 Nitpicking, but open(1).read() and open(2).read() both succeed (for small values of success) the same way that open(0).read() does. Thanks for the advice, everybody. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
2010/5/12 Gabriel Genellina gagsl-...@yahoo.com.ar: 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. Interesting. I wasn't aware of this. Is it documented somewhere? --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
On Wed, May 12, 2010 at 10:56 PM, Giampaolo Rodolà g.rod...@gmail.com wrote: 2010/5/12 Gabriel Genellina gagsl-...@yahoo.com.ar: 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. Interesting. I wasn't aware of this. Is it documented somewhere? http://docs.python.org/py3k/library/functions.html#open -- regards, kushal -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
On 5/12/2010 1:26 PM, Giampaolo Rodolà wrote: 2010/5/12 Gabriel Genellinagagsl-...@yahoo.com.ar: 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. The change actually happened, according to 'What's new', in 2.6 when 'open' was made a synonym for the new io.open. In particular, open(some_integer) assumes some_integer is a file descriptor and return some variant of file object using the given file descriptor. Interesting. I wasn't aware of this. Is it documented somewhere? Right where it should be, in the entry for 'open' under 'built-in functions': file is either ... or an integer file descriptor of the file to be wrapped -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
Giampaolo Rodolà wrote: 2010/5/12 Gabriel Genellina gagsl-...@yahoo.com.ar: 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. Interesting. I wasn't aware of this. Is it documented somewhere? http://docs.python.org/py3k/library/functions.html#open or an integer file descriptor of the file to be wrapped. -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
geremy condra wrote: On Wed, May 12, 2010 at 1:36 AM, Stefan Behnel stefan...@behnel.de wrote: 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 Nitpicking, but open(1).read() and open(2).read() both succeed (for small values of success) the same way that open(0).read() does. That's because your operating system made that so. Try a different operating system, and you may get different results. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
Terry Reedy dixit (2010-05-12, 14:26): On 5/12/2010 1:26 PM, Giampaolo Rodolà wrote: 2010/5/12 Gabriel Genellinagagsl-...@yahoo.com.ar: 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. The change actually happened, according to 'What's new', in 2.6 when 'open' was made a synonym for the new io.open. It did happened in 3.0, not in 2.6. Regards, *j -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
On 5/12/2010 7:07 PM, Jan Kaliszewski wrote: Terry Reedy dixit (2010-05-12, 14:26): On 5/12/2010 1:26 PM, Giampaolo Rodolà wrote: 2010/5/12 Gabriel Genellinagagsl-...@yahoo.com.ar: 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. The change actually happened, according to 'What's new', in 2.6 when 'open' was made a synonym for the new io.open. It did happened in 3.0, not in 2.6. I do not have 2.6 loaded to test and was judging from What's New in Python 3.0 has a section Changes Already Present In Python 2.6 which has an entry PEP 3116: New I/O Library. The io module is now the standard way of doing file I/O, and the initial values of sys.stdin, sys.stdout and sys.stderr are now instances of io.TextIOBase. The builtin open() function is now an alias for io.open() The 2.6.5 doc says io.open(file[, mode[, buffering[, encoding[, errors[, newline[, closefd=True]])¶ Open file and return a stream. If the file cannot be opened, an IOError is raised. file is either a string giving the name (and the path if the file isn’t in the current working directory) of the file to be opened or a file descriptor of the file to be opened. If you are right, then The builtin open() function is now an alias for io.open() is misleading and does not apply to 2.6 even though it appears in an entry on things backported to 2.6. I do not really care. tjr -- http://mail.python.org/mailman/listinfo/python-list
open(False) in python3
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: open(False) in python3
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
