Do you expect many people to prefer
with open('pathname', exclusive_create_and_update_binary) as f
with open('pathname', 'x+b') as f
The first one is much more explicit and readable. Explicit is better than implicit, and readability matters…
But do they have sixteen enums for this?
Java is an
enum with 10 elements. And you have to write
StandardOpenOption every flag you want to add, instead of simply
I think it would more acceptable and easier to remember (at least for
me) to have just six named modes that you can combine with the
# Named in uppercase for CONSTANTS.
APPEND # Equivalent to 'a'.
BINARY # Equivalent to 'b'.
EXCLUSIVE # Equivalent to 'x', exclusive create.
READ # Equivalent to 'r'.
UPDATE # Equivalent to '+'.
WRITE # Equivalent to 'x', creates or truncates.
rather than sixteen named modes.
I say they are equivalent to the string file modes, not necessarily
strings. I don’t require READ == ‘r’ to return true, but str(READ)
should return ‘r’.
Then if you want to exclusively create and update a binary file, you
BINARY & EXCLUSIVE & UPDATE , without caring about the order.
& operator rather than
+ because we’re not concatenating
the modes in order, but taking the union in arbitrary order.
I agree this is the optimal solution, but unluckily I don’t see a way to implement this without changing the existing functions in such a way that they can accept a flag instead of a string as
mode parameter, because you’re describing a numeric flag.
The best you can do currently (after changing update, _update and _binary) is:
OpenMode.exclusive_create + OpenMode.update + OpenMode.binary
that could be more simple to remember that
Another (ugly) option is to abandon the
enum and make
OpenMode a module and the six “constants” variables of the
OpenMode, so you can do
from OpenMode import *
with open(filepath, exclusive_create + update + binary):
Of course I do not like this solution at all, since even if it’s more compact, the variables will be not part of a standard enum, and they are not constant.