it would be nice if file(f) worked when f is already a
file, either by returning f or by constructing a new
file that refers to the same thing.  that would make it
easy to write functions that can take either a file or
a filename as an argument, like so:
    def p(f): print list(file(f))
which is kind of like using int() as a cast operation.

Logged In: YES 
user_id=21627

It's not at all obvious what this should do. Three
alternatives come to mind:
1. return f
2. return a wrapper object which delegates all calls
3. return a new file object, which is dup(2)'ed from the
original one.

Either of them might be meaningful in some context, and they
are mutually incompatible. In the face of ambiguity, refuse
the temptation to guess, so I'm -1.

Logged In: YES 
user_id=77867

that argument also works against str() and list().  it's not
obvious whether str(s) and list(v) should return itself, a
proxy, or a copy, and they're all useful in different
situations.  I don't think anyone would argue that the
ambiguity means those should be undefined.

I think file(f) is similar.  it has a few more issues
because files are special, but I think picking a reasonable
behavior for file(f) would simplify some programming. 
returning a dup is probably the least surprising in most
situations, because of f.close().

Logged In: YES 
user_id=21627

The same argument can *not* be made for strings, since
strings are immutable, so it does not matter whether you get
the original thing or a copy. Also, str(x) invokes x's
__str__ conversion. For lists, the argument is also
different: list(x) requires an iterable object and creates a
list out of it. The notion of an iterable object is
well-defined, and if you pass something that is not
iterable, you get a TypeError.

For files, this is entirely different. file() does not take
one argument, but three (and two of them are optional). The
first (mandatory) argument is a "filename". It might be
debatable what precisely a file name is, and indeed you can
pass both byte strings and unicode strings. A file, most
certainly, is *not* a filename, and there is no notion of
"converting to a file" in Python (e.g. by means of
__file__). This just isn't a useful generalization.

Logged In: YES 
user_id=31435

I'm also -1 on this -- I have no idea what would make sense 
when applying file() to a file object, or to a file-like object.  
Therefore anything it did in response would be surprising to 
me, except for raising an exception.

Logged In: YES 
user_id=21627

Since several people have commented that the change would
not be desirable, I'm closing it as "Won't fix". If you
still think that feature should be added, please write a
PEP, and collect feedback from the community (altough a part
of the community will likely react the same way to such a PEP).