[Python-Dev] Maybe, just maybe, pathlib doesn't belong.
Sven R. Kunze
srkunze at mail.de
Tue Apr 12 10:52:30 EDT 2016
On 12.04.2016 00:56, Random832 wrote:
> Fully general re-dispatch from argument types on any call to a function
> that raises TypeError or NotImplemented? [e.g. call
> Path.__missing_func__(os.open, path, mode)]
> Have pathlib monkey-patch things at import?
Implicit conversion. No, thanks.
> On Mon, Apr 11, 2016, at 17:43, Sven R. Kunze wrote:
>> So, I might add:
>> 3. add more high-level features to pathlib to prevent a downgrade to os
>> or os.path
> 3. reimplement the entire ecosystem in every walled garden so no-one has
> to leave their walled gardens.
> What's the point of batteries being included if you can't wire them to
Huh? That makes not sense to me.
> I don't get what you mean by this whole "different level of abstraction"
> thing, anyway.
Strings are strings. Paths are paths. That's were the difference is.
> The fact that there is one obvious thing to want to do
> with open and a Path strongly suggests that that should be able to be
> done by passing the Path to open.
Path(...).open() is your friend then. I don't see why you need os.open.
Refusing to upgrade it like saying, everything was better in the old
days. So let's use os.open instead of Path(...).open().
> Also, what level of abstraction is builtin open? Maybe we should _just_
> leave os alone on the grounds of some holy sacred lowest-level-itude,
> but allow io and shutils to accept Path?
os, io and shutils accept strings. Not Path objects. Why? Because the
semantics of "being a path" are applied implicitly by those modules. You
are free to use a random string as a path and later as the name of your
pet. Semantics of a string comes from usage. Path objects however have
Furthermore, if os, io and shutils are changed, we allow code like the
I don't know how to explain reasonably why my_path sometimes stays in
front of the method call and sometimes behind it to newbies.
More information about the Python-Dev