[Python-3000] Discussions with no PEPs

[Phillip J. Eby]

At 07:16 AM 3/13/2007 -0400, Benji York wrote:
>Phillip J. Eby wrote:
> > In short, the very idea of 'is_file()' 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 is_file (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.