file() on a file

[felixlee]

BPO	1155485
Nosy	@tim-one, @loewis

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2005-04-03.16:28:22.000>
created_at = <Date 2005-03-02.23:48:53.000>
labels = ['interpreter-core', 'type-feature']
title = 'file() on a file'
updated_at = <Date 2005-04-03.16:28:22.000>
user = 'https://bugs.python.org/felixlee'

bugs.python.org fields:

activity = <Date 2005-04-03.16:28:22.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2005-03-02.23:48:53.000>
creator = 'felixlee'
dependencies = []
files = []
hgrepos = []
issue_num = 1155485
keywords = []
message_count = 6.0
messages = ['54403', '54404', '54405', '54406', '54407', '54408']
nosy_count = 3.0
nosy_names = ['tim.peters', 'loewis', 'felixlee']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1155485'
versions = []

[felixlee]

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.

[loewis]

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.

[felixlee]

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().

[loewis]

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.

[tim-one]

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.

[loewis]

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).