Phillip J. Eby wrote:
> At 02:15 PM 4/6/2006, Guido van Rossum wrote:
>> On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> > I don't want to discourage people from working out their own ideas,
>> > but a lot of the stuff that's being discussed here about protocol
>> > adaptation is already implemented in PyProtocols.
>>
>> That's great. I believe that if we derive things from first principles
>> here and arrive at the same choices as PyProtocols, we haven't wasted
>> anybody's time;
>
> I agree; that's why I said "I don't want to discourage people from
> working out ... ideas". I just wanted to point out that for those who
> prefer to learn from worked-out examples, there are some available. One
> reason I like to steal designs from *built* systems is that making
> something real forces lots of tradeoffs into the open, that don't come
> up when you're just brainstorming.
>
> That having been said, please consider this a "spoiler warning": the
> rest of this message reveals where I think you're all going to
> eventually end up. If it'll spoil anyone's fun and/or learning to know
> this ahead of time, don't read the rest of this message. :)
>
> Hint: premature optimization is the root of all evil. I was actually
> trying to hint in my previous message that it would be valuable to learn
> from PyProtocols' example by *not* repeating it! I was not suggesting
> that PyProtocols is a model to which you should all aspire, but rather
> consider why I wish I hadn't bothered to do it in the first place!
I've been stealing liberally from PyProtocols all along, usually trying to
grasp ways to take *concepts* from it that I liked, and turn them into
something that seemed *usable* (with aesthetics playing a large part in that).
That's why one of the first things I hit on in rereading PEP 246 was "hang on,
why are we use a pair of ad hoc protocols to build an adaptation system"? And
lo and behold, PyProtocols had a much easier to use system based on concrete
protocol objects, where you manipulated the target protocol directly.
And my last message about adaptation, which was a (massively) simplified
version of some of the ideas in PyProtocols, let me understand how
transitivity would apply in a generic function context: you have function_A
with a certain signature, and existing operations and function_B that can be
implemented in terms of function_A. All there then needs to be is a way to
tell function_B about it:
@function_A.when_specialized
def notify_function_B(signature, specialization):
# Give function B a new specialization
# based on the specialization in A
# If the signatures are the same, then
# we can just pass the info along
function_B.specialize(signature)(specialization)
I have no idea whether providing a mechanism for that is a good idea or not,
but the important point is that it covers the last thing that I understood how
to do with protocols, but not with generic functions. And given that *normal*
functions are already in the language as a fundamental building block, then it
makes a lot of sense to explore how to make them generic.
I like being able to use 'signature' and 'specialization' as the terms, too,
as they describe exactly what's going on. Further, if all builtin function
objects (including C function descriptors and method wrappers) were
potentially generic, then it would be possible to write:
@specialize(str).for_signature(SomeClass)
def str_SomeClass(obj):
return obj.stringify()
The use of the "specialize" function (rather than invoking the method
directly) then means that arbitrary callables can support specialization by
defining it as something like:
def specialize(obj):
return obj.__call__
@specialize.for_signature(type(specialize))
def specialize_function(func):
return func
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
