[Python-3000] pep 3124 plans (original) (raw)

Phillip J. Eby pje at telecommunity.com
Tue Jul 24 02:51:09 CEST 2007

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.

More information about the Python-3000 mailing list