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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4