[Python-3000] Abilities / Interfaces

Jim Jewett jimjjewett at gmail.com
Mon Nov 27 14:30:07 CET 2006


On 11/26/06, Guido van Rossum <guido at python.org> wrote:
> On 11/25/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> > Personally, I stand by my assessment that they can make metaclasses
> > look straightforward -- but that is partly because metaclasses have
> > had their roughest edges worn off already.  (For example, they no
> > longer require compiling a C class so odd that the pattern gets named
> > after someone.)  If GF explanations start to come from several
> > different people, the same process should eventually simplify them.
> > If that happened quickly enough, it would change the tradeoffs.
>
> Did you read my blog post where I give my own interpretation and implementation?
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=155514


Yes, and also the comments.

If overloaded functions were proposed as an optional 3rd party module
(a possibility you did mention), they would be interesting.

When they are proposed as a fundamental part of the language itself,
it is crucial that there be a quick, easy explanation available as
soon as people need to work with them.  For metaclasses, people don't
need to work with them for quite a while.  For something like print or
len ... they need it sooner.  (And 3rd party registration means that
someone else's misunderstanding can cause bugs in your code.)

I felt that there was still too much confusion for something that is
proposed as a fundamental building block.

I expect that the confusion would get worse once you have to start
debugging multiple 3rd-party overloads.   The "TypeError: hex()
argument can't be converted to hex" is a hint at the problems, but I
expect them to be worse when the chosen function is a match -- just
not the one you expected.

-jJ


More information about the Python-3000 mailing list