[Python-3000] Argument Decorators (was Re: my take on "typeclasses")
Bill Birch
birchb at tpg.com.au
Thu May 11 14:45:32 CEST 2006
On Thu, 11 May 2006 03:30 pm, Guido van Rossum wrote:
>
> Bill Janssen is proposing that the specific thing a type must do is
> inherit from some abstract base class.
>
> Phillip Eby is countering that that isn't sufficient because he wants
> to be able to make up his own categories and apply these to existing
> types defined by 3rd party libraries.
>
> It would be great if we had a solution that allowed either approach!
Sorry if the following has already been suggested, almost everything has:
Perhaps is we refactor the compiler-generation of annotations slightly so that
the Type is responsable for handling the annotation, then developers can
implement their own approaches? Given the blog [1] code:
def foo(x: t1, y: t2) -> t3:
...body...
# is more or less equivalent to this:
def foo__(x, y): # original function
...body...
def foo(x, y): # wrapper function
x = adapt(x, t1)
y = adapt(y, t2)
r = foo__(x, y)
return adapt(r, t3)
Refactored to push adapt into the type:
def foo(x, y): # wrapper function
x = t1.adapt(x)
y = t2.adapt(y)
r = foo__(x, y)
return t3.adapt(r)
Refactor again because even adapt is now in the types.
def foo(x, y): # wrapper function
x = t1.decorateArg(x)
y = t2.decorateArg(y)
r = foo__(x, y)
return t3.decorateReturn(r)
Every Type has decorateArg and decorateReturn methods. They would be different
for contravariance and covarience reasons. The Python standard types would
behave as 80% of people expect, whatever that is. People with particular
ideas about types would supply their own type classes. i.e.
def foo(x: StrictlyT1, y: StrictlyT2) ->StrictlyT3: # Java fans ;-)
...
def foo(x: AdaptT1, y: AdaptT2) ->AdaptT3: # For fans of PEP 246
...
So a library might supply its own type classes consistent with the library
authors' requirements.
Again, sorry if this is old hat.
----------------References:
[1] http://www.artima.com/weblogs/viewpost.jsp?thread=87182
More information about the Python-3000
mailing list