"Jack Jansen" <Jack.Jansen at cwi.nl> wrote in message
news:8F23FB57-3A79-4521-9462-BE8B10FE0F54 at cwi.nl...
|
| On 12-Jan-2007, at 19:01 , Guido van Rossum wrote:
|
| > On 1/12/07, A.M. Kuchling <amk at amk.ca> wrote:
| >> Many types in Python are idempotent, so that int(1) works
| >> as expected, float(2.34)==2.34, ''.join('hello')=='hello'
| >> et cetera.
| >
| > I'm not sure I understand the use case; I don't believe I've ever felt
| > the need for this.
|
| I have oodles of routines of the form
| def foo(thefile):
| if type(thefile) == str: thefile = open(thefile)
| or
| if not hasattr(thefile, 'read'): thefile = open(thefile)
| or something similar.
This strikes me as being pretty directly analogous with functions that take
either an iterable or iterator as argument for a parameter, and which start
with
'it = iter(iterable)'. If we follow that analogy, file(fileob) should be
the fileob itself, just as iter(iterator) == iterator.
| > 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.
Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4