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 <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
