altering an object as you iterate over it?

[Tim Peters]

[John Salerno, on the difference between `open` and `file`]

Interesting. What is the difference between them now?

In 2.5 `file` is unchanged but `open` becomes a function:
<built-in function open>

 

[John Salerno]

[John Salerno, on the difference between `open` and `file`]

Interesting. What is the difference between them now?

In 2.5 `file` is unchanged but `open` becomes a function:
<built-in function open>

So they are still used in the same way though?

 

[Paul Rubin]

In 2.5 `file` is unchanged but `open` becomes a function:

<built-in function open>

So which one are we supposed to use?

 

[Tim Peters]

[Tim Peters]
[Paul Rubin]

So which one are we supposed to use?

Use for what? If you're trying to check an object's type, use the
type; if you're trying to open a file, use the function.
True

 

[Ben Finney]

[John Salerno, on the difference between `open` and `file`]

Interesting. What is the difference between them now?

In 2.5 `file` is unchanged but `open` becomes a function:
<built-in function open>

In that case I'll happily use 'file()', since it meshes nicely with
creating a new instance of any built-in type.

 

[netvaibhav]

fin = open(path, 'r')
fout = open(temp, 'w')
for line in fin:
if line.strip():
fout.write(line)
fin.close()
fout.close()

then delete path and rename temp, and you're done. And yes, this is
actually the canonical way to do this !-)

What if there's a hard link to path?

 

[Fredrik Lundh]

Ben Finney wrote:

Note though that you're calling a class (in this case, type)
constructor, to return a new object.

no, he's calling a factory function to get an object that provides the
expected behaviour.

in future versions of Python, open() may not always create an instance
of the file type.

</F>

 

[Aahz]

[John Salerno, on the difference between `open` and `file`]

Interesting. What is the difference between them now?

In 2.5 `file` is unchanged but `open` becomes a function:

file

open

<built-in function open>

In that case I'll happily use 'file()', since it meshes nicely with
creating a new instance of any built-in type.

Nobody will prevent you from going against the standard decreed by Guido.
But you also probably won't be able to contribute any code to the
standard library, and other people mucking with your code who do care
about Guido's decrees will probably change it.

Unlike all the other built-in types, files are special because they are
proxies for non-Python external objects. For that reason, there has long
been interest in extending open() to work with file-like objects (such as
URLs). Splitting open() and file() is a necessary precondition to making
that happen, and it's also possible that Python 3.0 may have separate
textfile and binary file objects. Finally, file() doesn't exist in
Python 2.1 and earlier, and using file() instead of open() is gratuitous
breakage.

 

[Dennis Lee Bieber]

no, he's calling a factory function to get an object that provides the
expected behaviour.

in future versions of Python, open() may not always create an instance
of the file type.

Let me guess... In Python 3000 one will have to do:

f = file(name, mode)
f.open()

<G>

With maybe a side-effect of having f.open() return f, so one can do
the one-line
f = file(name, mode).open()
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[bruno at modulix]

Do you ever flame yourself?

class Myself(Developper, Schizophrenic):
def _flame(self):
""" implementation left as an exercice to the reader...
Note that this is *not* part of the public API !-)
"""
pass