This patch allows the file constructor to take a file
descriptor, allowing for  much easier extension of its
functionality.

Logged In: YES 
user_id=25129

Bah, forgot the variable.

Logged In: YES 
user_id=33168

fp's and fd's are not interchangable.  The variable should
be called fd, since it's an int.  fill_file_fields() 2nd arg
is a FILE*, not an int.  So you would need to do file =
fdopen(fd, mode), then pass file as the 2nd arg.  In order
for this patch to be accepted, a test would also need to be
added (see Lib/test/test_file.py) and doc should be updated
(see Doc/lib/libfuncs.tex).

Logged In: YES 
user_id=25129

Okay, fixed it all. Passes 'make test' on linux/x86 with
default configure (does not test dbm/gdbm/mpz/bsddb).

(btw, old versions can be deleted)

Logged In: YES 
user_id=21627

What's wrong with os.fdopen? Why is

f = file(10, "r")

much easier than

f = os.fdopen(10, "r")

Logged In: YES 
user_id=25129

class some_class(file):
    def __init__(self, arg):
        fd = do_some_os_stuff_with_forks_and_pipes_or_sockets
        return file.__init__(self, fd, 'r')

    def close(self):
        do_some_cleanup_stuff
        return file.close(self)

and so on.

Logged In: YES 
user_id=25129

Didn't make it into 2.3alpha?

Logged In: YES 
user_id=357491

This functionality has still not made it into 2.3b1 .  If no one speaks up and 
comes up with a good argument to apply this by May 15 I am going to reject 
this patch.

Logged In: YES 
user_id=25129

I have a very good reason! Without it, there are file
objects that CANNOT be subclassed, specifically those
created via os.fdopen.

Yes, I am _still_ waiting for this to go in. Do I need to do
something else on some mailing list to get people to notice it?

Logged In: YES 
user_id=31435

You do need to convince people it's a good idea.  I cringe 
for two reasons:  it mixes up a higher-level facility with a 
lower-level one; and, in a language with dynamic typing, it's 
*helpful* that file(xyz, 'w') raises TypeError today when the 
runtime type of xyz is an integer.  This catches a serious 
error before it can harm files.

I'd dislike losing that error detection more than I'd like the 
new facility this offers.  Perhaps I'm in a small minority, 
though, in which case a discussion on comp.lang.python 
could reveal that.  Someone there will point out that while 
you can't get what you want directly via subclassing file 
today, you can get the effect via containment and a 
__getattr__ hook (to delegate the file methods you don't 
want to intercept to the contained file object).  That covers 
cases this patch doesn't, too, such as file objects returned 
by os.popen() (i.e., even with this patch, there are still "file 
objects that CANNOT be subclassed").

Logged In: YES 
user_id=25129

Okay, you have a good point. I could convert it to this format:

file(filename[, mode[, buffering[, fd]]])
or
file(filename[,mode[, buffering]][, fd=fd])

That should satisfy the type requirement. I kind of prefer
the keyword version, but that's just me.

I know about the containment solution, but I can't pass
containers to functions that expect isinstance(arg, file).

(As for os.popen, that's happens to be why I made this patch
in the first case. I needed to extend popen functionality,
and this was the minimum way to do it without violating the
above isinstance requirement.)

Logged In: YES 
user_id=357491

Has a discussion comp.lang.python occured to judge the demand for this 
feature?

Logged In: YES 
user_id=25129

No, I don't have usenet access.

Logged In: YES 
user_id=357491

You can use groups.google.com or python-list@python.org.

Logged In: YES 
user_id=21627

I'm rejecting the patch, on grounds that nobody sees any
need for it but the submitter.