[Python-3000] pep 3124 plans

[Phillip J. Eby]

At 11:58 AM 7/24/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > In order to follow things through with normal method calls, you have to
> > know where a class is in the program, implying that you either search
> > for it, or have read enough of the program to figure it out.
> >
> > Which of these two things is different with generic functions?
>
>A class is defined in just one place, or a limited number
>of places if it has base classes.

...and may be subclassed in an unlimited number of places.

A generic function is defined in just one place, with a limited 
number of "generic" methods typically adjoining it, and may be 
extended in an unlimited number of places.

Where's the difference?


>It also provides a convenient mental chunk under which to
>group all the operations that it implements. With GFs, there
>is no such obvious mental grouping.

The function itself is the grouping, in the same way that Python's 
operator.* functions are, or its built-in generics like len() and 
iter().  len() encapsulates the concept of "sequence", just as iter() 
encapsulates "iterable", and operator.add encapsulates "addition".

These are conceptual categories that can't be defined by classes, 
except by conventions like ABCs -- and ISTR the ABCs PEP ran into 
trouble dealing with n-ary operators where n>1.


> > if you're going to be
> > grepping for 'foo', it doesn't matter whether it's a method name or a
> > generic function name -- you're still going to find all the definitions.
>
>No, you're going to find every function whose name is 'foo',
>whether it's a method of the particular GF you have in mind
>or not.

And this doesn't apply to normal methods?  Come on.  This is far 
*more* likely to be a problem with normal methods than it is with 
generic functions.  For one thing, you can isolate your search to 
modules that import the function being overridden -- something you 
can't do with normal methods.


> > Since they make my world simpler,
>
>Are you talking about code that you've written yourself here,
>or do you find they make code written by others easier to
>understand as well?

Yes, I find code written using generics to be generally easier to 
understand, because it's possible to grasp a generic operator without 
needing to understand all the classes it can be applied to.

For example, the generic function operator.add in Python defines the 
concept of addition, without me needing to understand all possible 
types that might be added together.

And since all non-trivial Python code already uses generic functions, 
I find that they do in fact make all Python code simpler to 
understand.  Indeed, they're a significant contributor to Python's 
ease-of-use.  PEP 3124 seeks to expand that ease by allowing people 
to easily add their own generic functions, without needing to use 
workarounds like interfaces and adapters.


>I'd have to disagree with such a blanket statement.

The thing that you seem to keep missing in your analysis is that 
Python already *has* generic functions in the language specification, 
and has had them for what, 10, 15 years?  If any of these problems 
you're talking about actually existed, I think we'd already know about them.

Or are you arguing that functions like len() and iter() make progams 
harder to understand in all the same ways that you're saying that 
adding a standard GF library will?


>  > Grep (or whatever global search tool your
> > editor provides) is your friend.  It ain't perfect, but it's just as
> > much required (and equally imperfect) for global analysis of a
> > traditionally-OO program.
>
>Most of the time I find that I don't need to perform global
>analysis of a traditionally-OO paradigm. The conceptual
>encapsulation provided by classes makes that unnecessary.
>GF breaks that encapsulation, or at least to my mind it
>seems to, and that makes me uncomfortable.

That's because you're ignoring the GFs (and operators implemented as 
GF's) that you use all day long in even the most trivial of Python 
programs, let alone ones that use pickle or copy or pprint.  Even 
computing a sum such as 2+2 involves a generic function in Python!

All PEP 3124 proposes to do is have a standard API for 
programmatically adding methods to generic functions, irrespective of 
how those functions are internally implemented.  Its decorators are 
to generic functions what 'setattr()' is to objects: i.e., a generic 
function for manipulating their contents.

It doesn't really "add generic functions to Python", because Python 
already had them.