This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: add ability to specify name to os.fdopen
Type: enhancement Stage: test needed
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: christian.heimes, collinwinter, diekhans, georg.brandl, pitrou, serhiy.storchaka
Priority: normal Keywords:

Created on 2007-01-01 07:19 by diekhans, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (9)
msg54958 - (view) Author: Mark Diekhans (diekhans) Date: 2007-01-01 07:19
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>'...>
msg54959 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2007-03-09 01:02
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()?
msg54960 - (view) Author: Mark Diekhans (diekhans) Date: 2007-03-09 04:58
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.
msg54961 - (view) Author: Mark Diekhans (diekhans) Date: 2007-03-09 05:00
p.s.  I will happy implement the change.
msg59356 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-06 12:05
Where is the patch, Mark?

Collin, does fdopen(fd[, mode[, bufsize[, msg=None]]]) and <open file
'<fdopen \d+ (msg)>'> sound good to you?
msg121026 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2010-11-12 07:23
Christian: yes, that sounds fine.
msg121027 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-11-12 07:57
Collin: I doubt Christian will do much about this anymore :)
msg121047 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-11-12 17:10
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'>
msg235683 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-02-10 11:58
And the name attribute of FileIO object is writable. So you can change it after calling fdopen.

>>> import os
>>> f = os.fdopen(2, "w")
>>> f
<_io.TextIOWrapper name=2 mode='w' encoding='UTF-8'>
>>> f.buffer.raw.name = 'useful name'
>>> f
<_io.TextIOWrapper name='useful name' mode='w' encoding='UTF-8'>
History
Date User Action Args
2022-04-11 14:56:21adminsetgithub: 44391
2015-02-10 11:58:03serhiy.storchakasetstatus: languishing -> closed

nosy: + serhiy.storchaka
messages: + msg235683

resolution: rejected
2013-11-17 15:30:21christian.heimessetstatus: open -> languishing
versions: + Python 3.4, - Python 3.2
2010-11-12 17:10:38pitrousetnosy: + pitrou
messages: + msg121047
2010-11-12 07:57:02georg.brandlsetnosy: + georg.brandl
messages: + msg121027
2010-11-12 07:23:33collinwintersetassignee: collinwinter ->
messages: + msg121026
2010-08-09 03:45:36terry.reedysetversions: + Python 3.2, - Python 3.1, Python 2.7
2009-03-30 18:33:16ajaksu2setstage: test needed
versions: + Python 3.1, Python 2.7, - Python 2.6
2008-01-06 12:05:28christian.heimessetassignee: collinwinter
versions: + Python 2.6
messages: + msg59356
nosy: + christian.heimes
2007-01-01 07:19:56diekhanscreate