[ANN] Python 2.4 Quick Reference available

[Richard Gruet]

Hi Pythoners,

An updated version of the Python Quick Reference is available for Python 2.4
at http://rgruet.free.fr/#QuickRef.
It is a single looonnng html page (30 printed A4 pages) with a choice of 4
different CSS styles; also available in PDF.

Richard

 

[Robin Becker]

Hi Pythoners,

An updated version of the Python Quick Reference is available for Python 2.4
at http://rgruet.free.fr/#QuickRef.
It is a single looonnng html page (30 printed A4 pages) with a choice of 4
different CSS styles; also available in PDF.

Richard

Great news; thanks and thanks again

 

[Franz Steinhäusler]

Hi Pythoners,

An updated version of the Python Quick Reference is available for Python 2.4
at http://rgruet.free.fr/#QuickRef.
It is a single looonnng html page (30 printed A4 pages) with a choice of 4
different CSS styles; also available in PDF.

Richard

Hello Richard,

many thanks!

Such a coincidence, because I wanted to ask these
days, wheter a newer one exist (I have a printed reference for Python
1.5.1)

 

[Pete Havens]

The is awesome! Thanks. I did notice one thing while reading it. In the
"File Object" section, it states:

"Created with built-in functions open() [preferred] or its alias
file()."

....this seems to be the opposite of the Python documentation:

"The file() constructor is new in Python 2.2. The previous spelling,
open(), is retained for compatibility, and is an alias for file()."

....but I'm picking nits, because this is a fantastic piece of work and
will be very useful to me. Thanks again!

 

[David M. Cooke]

The is awesome! Thanks. I did notice one thing while reading it. In the
"File Object" section, it states:

"Created with built-in functions open() [preferred] or its alias
file()."

...this seems to be the opposite of the Python documentation:

"The file() constructor is new in Python 2.2. The previous spelling,
open(), is retained for compatibility, and is an alias for file()."

Except if you look at the current development docs
(http://www.python.org/dev/doc/devel/lib/built-in-funcs.html) it says

"""
The file() constructor is new in Python 2.2 and is an alias for
open(). Both spellings are equivalent. The intent is for open() to
continue to be preferred for use as a factory function which returns a
new file object. The spelling, file is more suited to type testing
(for example, writing "isinstance(f, file)").
"""

.... which more accurately reflects what I believe the consensus is
about the usage of open vs. file.

 

[George Sakkis]

The is awesome! Thanks. I did notice one thing while reading it. In the
"File Object" section, it states:

"Created with built-in functions open() [preferred] or its alias
file()."

...this seems to be the opposite of the Python documentation:

"The file() constructor is new in Python 2.2. The previous spelling,
open(), is retained for compatibility, and is an alias for file()."

Except if you look at the current development docs
(http://www.python.org/dev/doc/devel/lib/built-in-funcs.html) it says

"""
The file() constructor is new in Python 2.2 and is an alias for
open(). Both spellings are equivalent. The intent is for open() to
continue to be preferred for use as a factory function which returns a
new file object. The spelling, file is more suited to type testing
(for example, writing "isinstance(f, file)").
"""

... which more accurately reflects what I believe the consensus is
about the usage of open vs. file.

--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca

Still the word "open" sounds too general if the meaning is "open a file-like object"; OTOH this
could be a good thing if in some future version "open('http://www.python.org')" was e.g. an alias to
urllib2.urlopen.

George

 

[Michael Hoffman]

"""
The file() constructor is new in Python 2.2 and is an alias for
open(). Both spellings are equivalent. The intent is for open() to
continue to be preferred for use as a factory function which returns a
new file object. The spelling, file is more suited to type testing
(for example, writing "isinstance(f, file)").
"""

There was a discussion on python-dev (earlier this year IIRC) where
someone started changing the stdlib to use file() instead of open()
and the BDFL clarified what he originally wanted with file().

That said, I still use file() instead of open(). I think that:

for line in file("mytext.txt"):

makes a lot more sense than:

for line in open("mytext.txt"):

I guess it's because the first option sounds a lot more like English.

It's one of the few places where my personal style disagrees with
the "official" Python style but I just like file() so much better

 

[Nick Coghlan]

Still the word "open" sounds too general if the meaning is "open a file-like object"; OTOH this
could be a good thing if in some future version "open('http://www.python.org')" was e.g. an alias to
urllib2.urlopen.

Exactly the reason the BDFL gave for preferring 'open' - it may be extended to
opening other types of objects than files.

Cheers,
Nick.

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Nick Coghlan]

Exactly the reason the BDFL gave for preferring 'open' - it may be extended
to opening other types of objects than files.

So, when we *know* we are opening a file, `file' cannot be a bad choice!
Moreover, practically, most of the times, we know we are opening a file.

`open' is opened (sic!) for some future magic. I prefer to protect my
programs against future magic, until this magic is precisely specified.

 

[Michael Hoffman]

[Nick Coghlan]

George Sakkis wrote:



Exactly the reason the BDFL gave for preferring 'open' - it may be extended
to opening other types of objects than files.

So, when we *know* we are opening a file, `file' cannot be a bad choice!
Moreover, practically, most of the times, we know we are opening a file.

`open' is opened (sic!) for some future magic. I prefer to protect my
programs against future magic, until this magic is precisely specified.

I agree. I don't want users to be able to specify URLs instead of
filenames unless I explicitly allow it.

To be honest I doubt open will be extended in this manner. I can see
the Pythoneers adding, say, a keyword argument to open to allow a URL
instead, but just changing the current behavior would be too risky. Plus,
what happens if I have a file named "http://www.python.org/"?

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Michael Hoffman]

To be honest I doubt open will be extended in this manner.

I did not read Guido's arguments for a while, so I may remember them
wrongly. So, take me with a grain of salt. I would not think Guido is
arguing for the sole sake of arguing. Maybe his plans or visions will
change, but until such changes are announced, I've no reason to doubt
them . All in all, `file' is now probably to be considered safer than
`open', despite Guido advises to prefer `open'.

 

[Peter Hansen]

That said, I still use file() instead of open(). I think that:

for line in file("mytext.txt"):

makes a lot more sense than:

for line in open("mytext.txt"):

I guess it's because the first option sounds a lot more like English.

Call me a space-waster (or a "waste of space" ;-) but I
still prefer this one to either of the above:

file = open('mytext.txt')
for line in file:
...


-Peter

 

[Michael Hoffman]

[Michael Hoffman]

To be honest I doubt open will be extended in this manner.

I did not read Guido's arguments for a while, so I may remember them
wrongly.

No, I think you remember them the same way I do.

So, take me with a grain of salt. I would not think Guido is
arguing for the sole sake of arguing. Maybe his plans or visions will
change, but until such changes are announced, I've no reason to doubt
them .

Well I'd hope they would.

All in all, `file' is now probably to be considered safer than
`open', despite Guido advises to prefer `open'.

Definitely.

 

[Christos TZOTZIOY Georgiou]

[snip: use 'open' in preference to 'file']

To be honest I doubt open will be extended in this manner. I can see
the Pythoneers adding, say, a keyword argument to open to allow a URL
instead, but just changing the current behavior would be too risky. Plus,
what happens if I have a file named "http://www.python.org/"?

I don't know in what filesystem you can have such a file name [1]. Slashes
('/') you can (kind of) get away with using \u2215 (DIVISION SLASH) on NTFS or
on UTF-8 encoded *nix filenames, but I haven't found a replacement for colon
(':'). Using similar glyphs, of course, invalidates the URL...


[1] Unless you mean it as a *path name*, which /could/ exist on *nix filesystems
(normalised to a directory called 'www.python.org' in the local subdirectory
'http:'), but still could not on NTFS.