[Python-3000] pep 3124 plans
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
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