open(False) in python3
in [Python]
|
Prev: default argument
Next: py2exe help
From: Martin v. Loewis on 12 May 2010 16:24 geremy condra wrote: > On Wed, May 12, 2010 at 1:36 AM, Stefan Behnel <stefan_ml(a)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
From: Jan Kaliszewski on 12 May 2010 19:07 Terry Reedy dixit (2010-05-12, 14:26): > On 5/12/2010 1:26 PM, Giampaolo Rodolà wrote: > >2010/5/12 Gabriel Genellina<gagsl-py2(a)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
From: Terry Reedy on 12 May 2010 23:04
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 Genellina<gagsl-py2(a)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 |