[Python-Dev] type categories

[Andrew Koenig]

ark> It makes me uneasy because the behavior of programs might depend
ark> on the order in which modules are loaded.  That's why I didn't
ark> suggest a way of defining the variations on f in separate places.

David> This concern seems most un-pythonic to my eye, since there are
David> already all kinds of ways any module can change the behavior of
David> any call in another module. The moset direct way is by
David> rebinding the implementation of another module's
David> function. Python is a dynamic language, and that is usually
David> seen as a strength.

Indeed.  What concerns me is not dynamic behavior, but order-dependent
behavior that might be occurring behind the scenes.  I would really like
to be confident that if I write

        import x, y

it has the same effect as

        import y, x

I understand that there is no guarantee of that property now, but I suspect
that most people write programs in a way that does guarantee it.  I would
hate to see the language evolve in ways that makes it substantially more
difficult to avoid such order dependencies, so I am reluctant to propose
a feature that would increase that difficulty.

David> More importantly, though, forcing all the definitions to be in
David> one place prevents an important (you might even say the most
David> important) use case: the author of a new type should be able to
David> provide a a multimethod implementation corresponding to that
David> type. For example, if I write a rational number class, I should
David> be able to plug in a corresponding arctan implementation.

Yes.  I'm not saying such a feature shouldn't exist; just that I
don't know what form it should take.

David> I'm extra-surprised to see that Andy's uneasy about this, since
David> a C++ feature which (colloquially) bears his name was
David> purpose-built to make this sort of thing possible. Koenig
David> lookup raises a similar issue: that the behavior of a function
David> call can be changed depending on which headers are #included,
David> and even the order they're #included in.

The C++ #include mechanism, based as it is on copying source text,
offers almost no hope of sensible behavior without active
collaboration from programmers.

David> [I personally have many other concerns about how that feature
David> worked out in C++ - paper available on request - but the Python
David> implementation being suggested here suffers none of those
David> problems because of its explicit nature]

Which doesn't mean it can't suffer from other problems.  In
particular, if I know that modules x and y overload the same function,
and I want to be sure that x's case is tested first, one would think I
could ensure it by writing

        import x, y

But in fact I can't, because someone else may have imported y already,
in which case the second import is a no-op.

-- 
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark