RetroSearch Browse

Sat Jan 13 14:25:09 CET 2007 · https://mail.python.org/pipermail/python-dev/2007-January/070618.html

   Terry Reedy schrieb:

> | > We should also consider the semantics in more detail. Should the seek
> | > position be shared between the two objects? What about buffering?
> |
> | That's definitely the hard part. But it's somewhat similar to
> | "normal" mutable objects which are (I think always, right?) shallow
> | copied when used in a constructor.
> 
> But why, in the normal case, do you want a copy?  It seems to me that is 
> thefile is a file rather than a string, then that is what you want, and you 
> are asking for
> 'thefile = file(thefile)' to work just as the iter statement does.

Consider the use case presented before:

def foo(thefile):
     if type(thefile) == str:
         thefile = open(thefile)

Now, if thefile is already a file object, you won't have to close it
because it came from somewhere else. If thefile is a string, you'll have to
close it at the end.

Now, if file(fileobject) would return another file object created by
something like os.dup(), you can do

def foo(thefile):
     try:
         thefile = file(thefile)

         (...)
     finally:
         thefile.close()

Georg

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-January/070618.html below:

[Python-Dev] file(file)