[Python-Dev] The path module PEP (original) (raw)

Thomas Wouters thomas at xs4all.net
Thu Jan 26 14:26:41 CET 2006

On Thu, Jan 26, 2006 at 09:26:27AM +0000, Michael Hoffman wrote:

[Thomas Wouters] > [Subclassing string] is my only problem with the PEP. It's all very nice > that subclassing from string makes it easier not to break things, but > subclassing implies a certain relationship.

This is the soul of arguing for purity's sake when practicality would dictate something else.

If we're going to argue that point, I don't believe this is the practicality that the 'zen of python' talks about. Practicality is the argument for 'print', and for requiring the ':' before suites, and for some of the special cases in the Python syntax and module behaviour. It isn't about the implementation. The argument to subclass string is, as far as I can tell, only the ease of implementation and the ease of transition. Nothing in the old thread convinced me otherwise, either. I've never seen Guido go for an implementation-practical solution just because he couldn't be arsed to do the work to get a conceptually-practical solution. And subclassing string isn't conceptually-practical at all.

If you remove the basestring superclass, then you remove the ability to use path objects as a drop-in replacement for any path string right now. You will either have to use str(pathobj) or carefully check that the function/framework you are passing the path to does not use isinstance() or any of the string methods that are now gone.

More to the point, you will have to carefully check whether the function/framework will use the Path object in a way the Path object can handle. There's already discussion about whether certain methods should be 'disabled', in Path objects, or whether they should be doing something conceptually different. And subclassing string is not going to solve all these issues anyway. Even in the standard library there's a scary amount of 'type(x) == type("")' checks, most noteably in exactly the type of function that takes both a filename and a file-like object.

I don't believe going out of your way to cater to these kind of typechecks is the right way to solve the problem. I believe the problem is more that there isn't a unified, obvious, 'one-way' to do the typechecks -- or rather, to avoid the typechecks. Parts of Python do duck-typing and nothing else; this usually works fine, and is quite flexible. Other parts, especially (but not exclusively) the parts written in C and Python code that directly deals with those C parts, need to care more about actual types. Python offers no standard or accepted or even vaguely preferred way of doing that. The standard library doesn't even do this uniformly, so how can we expect anyone to ever get this 'right'? Especially since the 'right' way depends on what you want to do with the result. This problem pops up most visibly in treating-as-int (indexing) and in treating-as-string (open() and friends), but I'm sure there are more.

You could see this as an argument for formal interfaces. Perhaps it is. It could also be an argument for just a few more hooks. Guido already suggested index, which would mean 'treat me as this int for indexing and other such operations' -- which is not the same thing as int. Likewise, treating-as-string would require a different hook than str or repr, and should explicitly not be defined for most objects, only those that actually want to be treated as a string. And there should probably be more.

Or, maybe, we could do it all in one hook. Say, equivalent. obj.equivalent(cls) would return the instance of 'cls' that represents 'obj', or raise an appropriate error. I say 'instance of 'cls'', which means it could be an instance of a subclass, too. It isn't duck-typing and it doesn't replace interfaces, not by far, since it actually returns a new type (and thus can't be a proxy-type; I don't think changing the equivalent should change the original, anyway.) Rather, it'd be the standard way to glue duck-typing (and formal interfaces, if you use those) with strict typing mechanisms (like C's.)

-- Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

More information about the Python-Dev mailing list