classification
Title: What about an enum for open() modes?
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.9
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Marco Sulla, serhiy.storchaka, vstinner
Priority: low Keywords:

Created on 2019-08-22 15:54 by Marco Sulla, last changed 2019-08-30 14:41 by Marco Sulla. This issue is now closed.

Messages (8)
msg350203 - (view) Author: Marco Sulla (Marco Sulla) Date: 2019-08-22 15:54
As title. I just created it:

https://pastebin.com/pNYezw2V

I think it could be useful to have a more descriptive way to declare a file open mode. Many languages has an enum for this.

Maybe open(), os.fdopen(), os.popen() and pathlib.Path.open() can just accept also an OpenMode enum as mode parameter, without the need to write OpenMode.append.value, for example, but just OpenMode.append. As an alternative, OpenMode could be a namedtuple.

I don't know in which module should be put. In `builtins`, `os` or `pathlib`?
msg350664 - (view) Author: Marco Sulla (Marco Sulla) Date: 2019-08-28 14:59
Mh. No one is interested?
msg350697 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-08-28 23:57
Please send an email to the python-ideas mailing list, rather than opening a bug report at bugs.python.org.
msg350828 - (view) Author: Marco Sulla (Marco Sulla) Date: 2019-08-29 20:41
Excuse me, but this is not a bug report, but a feature request. Indeed there's the possibility to submit also enhancements, not only bugs, as in all bug reporting board worthy of respect. You see the Type select with "Enhancement" option selected?
msg350866 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-08-30 10:53
The open() function is very commonly used, so modifying it requires a lot of discussion. In Python, we prefer to discuss such changes ("feature request" if you want) on python-ideas, rather than on the bug tracker, to get more reviews and feedback.

open() modes and os.open() modes are very different. IMHO it's ok and simple to add enums for os.open() modes, but I'm not sure about open() modes which are strings. I don't think that enum supports mode1 | mode1 if mode values are strings. Moreover, for backward compatibility, enums should behaves a the str type. I don't think that it's possible neither, whereas IntEnum would fit nicely for os.open() modes (integers).

Usability and backward compatibility deserves a long discussion.

Note: there is python-ideas mailing and the Ideas category of discuss.python.org. I'm not sure which one is preferred.

https://mail.python.org/mailman3/lists/python-ideas.python.org/
https://discuss.python.org/c/ideas
msg350879 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-08-30 14:21
No modification of open() is needed. Just make your enum class a subclass of str.

This idea does not look particularly attractive to me, but you can create a package on PyPi with your OpenMode class and test how popular it will be.
msg350881 - (view) Author: Marco Sulla (Marco Sulla) Date: 2019-08-30 14:39
Well, I'll discuss it in python-ideas. Let me do the testament before... :D

@serhiy.storchaka thank you for the StrEnum tip, but no PyPi package please. It has no sense to add an addional package only for having an enum that should be built-in as in all other languages.

And at most I'll do it myself, thank you ;)
msg350882 - (view) Author: Marco Sulla (Marco Sulla) Date: 2019-08-30 14:41
@vstinner Note that I wrote about os.fdopen(), not os.open().
History
Date User Action Args
2019-08-30 14:41:27Marco Sullasetmessages: + msg350882
2019-08-30 14:39:42Marco Sullasetmessages: + msg350881
2019-08-30 14:21:15serhiy.storchakasetstatus: open -> closed

nosy: + serhiy.storchaka
messages: + msg350879

resolution: rejected
2019-08-30 10:53:49vstinnersetmessages: + msg350866
2019-08-29 20:41:08Marco Sullasetstatus: closed -> open
resolution: not a bug -> (no value)
messages: + msg350828
2019-08-28 23:57:11vstinnersetstatus: open -> closed

nosy: + vstinner
messages: + msg350697

resolution: not a bug
stage: resolved
2019-08-28 14:59:57Marco Sullasetmessages: + msg350664
2019-08-22 17:48:41brett.cannonsetpriority: normal -> low
type: enhancement
2019-08-22 15:54:09Marco Sullacreate