Please add an optional argument to os.fdopen() to specify the name field in
the resulting file object.  This would allow
for a more useful name than:
  <open file '<fdopen>'...>

Changing this to a "feature request", since it's certainly not a bug.

I can see both sides of this; on the one hand, <fdopen> isn't the most descriptive string and doesn't give you an idea where it came from; on the other hand, you lose the distinction between files opened by filename and those by file descriptor.

If the purpose is to distinguish between fdopen()'d files, what if fdopen() was changed so that the filename matched <fdopen \d+>, where \d+ is the file descriptor passed to fdopen()?

thanks collin; that was suppose to be a feature request!

<fdopen \d+> doesn't really help.  For end user message, a file name is very use, the fact that it is opened by fdopen is not.  If one is debugging a program and knows the file name, one can usually figure out where it is opened, the file number, or for that matter that fdopen was used is less useful.

The particular case that prompted this request was the need use os.open to get non-blocking mode and then pass the result to fdopen.  However this now loses the file name, replacing it with something not useful.

thanks.

p.s.  I will happy implement the change.

Where is the patch, Mark?

Collin, does fdopen(fd[, mode[, bufsize[, msg=None]]]) and <open file
'<fdopen \d+ (msg)>'> sound good to you?

Christian: yes, that sounds fine.

Collin: I doubt Christian will do much about this anymore :)

The requested feature would require an additional argument to fdopen() and open(), which already have many args. It would be better IMO to make the `name` attribute on file objects writeable.

By the way, right now (in 3.x) fdopen() gives you the file descriptor number, which is better than nothing:

>>> import os
>>> f = os.fdopen(2, "w")
>>> f
<_io.TextIOWrapper name=2 encoding='UTF-8'>