I like the idea of having these functions, but I don't like overloading the argument to a function with "filename or file-like object" as is common in libraries like Pandas. I think there are a few places the standard library does it, but the separation seems better to me.
I don't LOVE the names dumpf() and loadf(), but I don't have an obviously better choice. I guess probably I'd want fromfile() and tofile() as more "modern" names.
While separating the methods to avoid method overloading feels much cleaner (and I also think of it that way), w have to look at the
other side of it:
If .load and .dump are super-charged, people coding with these methods in mind have _one_ less_ thing to worry about:
if the method accepts a path or an open file becomes irrelevant. On th othr hand, with two extra methods,
anyone coding the samething have one _extra_ thing to worry about, even more things than they have today!
Nowadays, one learn that 'ok, so load takes an open file", and that's it. With two new methods it becomes
"ok, was it dump or dumpf which took an openfile? Or was it the other way around?" - and that is bad.
Parameter overloading has been around from O.O. inception, it is used in other parts of Python, and
permissive signatures are part of what made Python so atractive along the years.
So, this is "the other side".
--
The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WOTLFRSGGRGVIYEIOCTGQJAWA2KK5PPJ/
Code of Conduct: http://python.org/psf/codeofconduct/