[Python-Dev] When should pathlib stop being provisional?

[Steven D'Aprano]

On Tue, Apr 05, 2016 at 11:53:05PM -0700, Nathaniel Smith wrote:

> This makes me twitch slightly, because NumPy has had a whole set of
> problems due to the ancient and minimally-considered decision to
> assume a bunch of ad hoc non-namespaced method names fulfilled some
> protocol -- like all .sum methods will have a signature that's
> compatible with numpy's, and if an object has a .log method then
> surely that computes the logarithm (what else in computing could "log"
> possibly refer to?), etc. 

It's the down-side of duck-typing. It's all well and good accepting 
anything with a quack method, but not everything is that straight-
forward:

artist.draw()
gunslinger.draw()


I think that file system paths are important enough, and tricky enough, 
to justify their own protocol. I like Nick's suggestion of a special 
dunder method for converting path-like objects into paths, without the 
problems that str(x) has, or the risk of assuming that anything with a 
.path attribute refers to a file system path.

(maze.path, garden.path, career.path perhaps?)


-- 
Steve