[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Jim Jewett]

On 5/11/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 09:46 AM 5/11/2007 -0400, Jim Jewett wrote:
> >As much as it seems clear once you understand ... it isn't, if only
> >because it is so unexpected.  I think it needs an example, such as

> >     class A: ...
> >     class B(A): ...

> >Then register before/after/around/normal methods for each, and show
> >the execution path for a B().  As I understand it now (without
> >rereading the PEP)

> >     AroundB part 1
> >     AroundA part 1
> >     BeforeA
> >     BeforeB
> >     NormalB
> >     # NormalA gets skipped, unless NormalB calls it explicitly
> >     AfterA
> >     AfterB
> >     AroundA part 2
> >     AroundB part 2

> The above is correct, except that either AroundB or AroundA *may*
> choose to skip calling the parts they enclose.

So how is an Around method any different than a full concrete
implementation?  Just because it has higher precedence, so it can win
without being the most specific?

Could you drop the precedence stuff from the core library, and just have

"here is how to register a concrete implementation"
"here is the equivalent of super -- a way to call whatever would have
been called without your replacement"

I understand that the full version offers more functionality, but it
is also more complicated.  Maybe use that fuller version as a test
case, and mention in the module docs that it is possible to create
more powerful dispatch rules, and that there is an example
(test\test_generic_reg  ?), with even more powerful extensions
available as PEAK.rules (http:// ...)  and Zope.Interfaces
(http://...)

> >Library 1 and Library 2 both register Sage classes with Numpy, or vice
> >versa.  Library 1 and 2 don't know about each other.  Library 1 and 2
> >also go through some extra version skew pains when Sage starts
> >registering its types itself.

> Seriously though, it seems to me that registering third-party types
> in fourth-party generic functions, from *library* code (as opposed to
> application code) is unwise.  I mean, you're already talking about
> FOUR people there, *not* counting Library 2!  (i.e., Sage, Numpy,
> Library 1, and the user).

Those are all math libraries; Library 1 and Library 2 *should* both
work well with both NumPy and Sage, and can reasonably be considered
extensions of both.

Saying "You can do this with most numbers, but not NumPy numbers" is ugly.

Saying "You can do this, but sometimes it will break because the
extensions I work with don't know about each other, and I won't
translate, as a matter of policy" is ... probably not going to happen.

Ideally, NumPy and Sage would make the introductions directly, or
there would at least be a canonical mapping somewhere that Libraries 1
and 2 could agree on ... but that won't happen at any specific time.

Saying "You need to upgrade to at least version Package A version
2.3.4 and Package B version 4.3 to use my code" is unlikely to happen;
you yourself still support Python 2.2 in your own packages.

 > anyway, and the user could, if he/she had to, use multiple
> inheritance plus some additional registrations of their own to work things out.

If there are two registrations for the same selection criteria, how
can the user resolve things?  Either the first one registered wins, or
the second, or the user sees some sort of import failure, and can't
fix it without modifying somebody else's code to avoid one of those
registrations.

-jJ