[Python-3000] Discussions with no PEPs (original) (raw)

Phillip J. Eby pje at telecommunity.com
Tue Mar 13 17:05:10 CET 2007

At 07:16 AM 3/13/2007 -0400, Benji York wrote:

Phillip J. Eby wrote: > In short, the very idea of 'isfile()' is wrong, wrong, wrong. At least, > if your goal is to make libraries more robust and reusable.

First a note: I personally hope a generic function system (with multiple dispatch) makes it into 3.0 and I don't particularly like the ABC proposal. Having said that, the origin of this discussion was (paraphrased) "instead of doing ABCs, let's just do interfaces". Which seems reasonably to me. It would seem that the same arguments against isfile (or any other check of that ilk) would apply to the ABCs proposed (http://wiki.python.org/moin/AbstractBaseClasses) as well, but I don't recall much argument about the idea that ability to check for a few basic types should be included in the language.

I'm not as opposed to that, because subclassing is more of a commitment and 'isinstance()' tests still "smell" enough that people can (probably) be convinced they're bad.

However, more people are under the impression that interface testing is safe and pure and smell-free, so there's more of a barrier to overcome for them to learn why it's wrong, without them first getting bitten -- either by their own code or somebody else's.

If that idea isn't widely accepted, I would have expected more vigorous argument (from many corners) now that it seems ABCs are destined to appear in 3.0.

Mainly, my argument about the ABC effort is that it's doomed to non-usefulness, in part because of the too-high granularity, but also because it's the receivers who need to declare the interfaces they require, and these are inevitably a mismatch with the interfaces that objects (especially generic containers) want to declare.

Libraries and applications generally don't care about something being "a sequence" - they care about say, a priority-ordered sequence of things that can be notified about a socket event. Or a postcode-ordered sequence of things that can have shipping labels printed for them.

In a nutshell, this is why most "type system" efforts in Python arrive with much fanfare and then gradually fade into the background -- they're attacking the wrong end of the problem.

Java, ironically, avoids this problem by forcing you to have new types for every single damn thing. The idiomatic way to have a priority-ordered sequence of socket event listeners is to make a new base class or interface just for that purpose -- so you end up with receiver-oriented interfaces as a side effect! (In addition, Java has just enough overloading support that a lot of the common cases for what would be type tests in Python, are done using overloads in Java.)

Whereas in Python, the idiomatic way to do things like that is to just use a list object, unless you absolutely need something like a database or a btree or something fancy, or you want to create a list that automatically maintains the ordering.

Even then, you're probably not going to subclass 'list', since you'd have to override all the manipulation methods.

Anyway, I don't think the ABC effort is a bad thing in itself. In fact, there may be some benefit to documenting what Python's type concepts are. But I think it'll mostly be a waste of time and effort with respect to practical libraries and applciations -- including the stdlib itself.

Basically, all of the past efforts at producing such things (including zope.interface and my own PyProtocols) were an attempt to transplant a Java idea of interfaces into a language where they really don't fit. If we had Java-style overloading and didn't have truly generic container protocols (iter, getitem, slices, mappings), they might make sense.

But the reality is that Python's built-in types and protocols are far superior to what's in Java, and it simply makes a mess of things to try to shoehorn them into a Java-oriented way of defining interfaces.

If 3.0 /is/ going to give the "typecheck" ability to basic types,

We have this now - it's called isinstance(). :)

then the argument is: should it be ABCs, interfaces, generic functions, or something else.

Of these, ABCs are the least problematic because they don't introduce a new kind of type checking that's lauded as safe when in fact it's pure evil.

More information about the Python-3000 mailing list