[Python-Dev] Maybe, just maybe, pathlib doesn't belong.

[Sven R. Kunze]

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
> anything?

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 
built-in semantics.

Furthermore, if os, io and shutils are changed, we allow code like the 
following:


my_path.touch()
os.remove(my_path)


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.

Best,
Sven