I've updated the page to reflect more of Jim Jewett's comments. And
to reflect more of the underlying "special methods". "Container", for
instance, now has "get" (for __getattr__), as well as "len" (for
__len__).
By the way, all these interfaces are already in Python; they just
aren't written do
I've updated the page to answer a few questions Jim Jewett posed, and
to expand a few more interfaces. I haven't tried to explain the
implementation types, like Code or Frame. I'm hoping someone else
will do that. I've broken up the File type into a set of types which
attempt to capture (1) the
Guido van Rossum wrote:
> I wonder if a bunch of well thought-out standard ABCs, applied to the
> standard data types, and perhaps more support for setting __bases__,
> wouldn't address most concerns.
I think it would, but I don't know if we're going to get anywhere
without getting more concrete.
At 02:34 PM 11/27/2006 -0500, Jim Jewett wrote:
>I'm not sure that adding it to the builtin (but in a new name) would
>really buy much over an adapter (x in MyProto("asdf") ), but the
>interface fans may feel differently.
For what it's worth, in Chandler there is a system called Annotations that
On 11/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Thinking about my own example some more, I think it would actually
> work just as well using ABCs instead of abilities. ... It seems the use
> case for making abilities/interfaces separate from ABCs hinges on
> the assumption that there are
[With apologies for having a monologue with myself here.]
On 11/24/06, I wrote:
> I'd like to take the opportunity to present another example of what
> I'd like to be able to do with abilities and generic functions.
[...]
Thinking about my own example some more, I think it would actually
work jus
> I believe this example captures an important requirement that has been
> expressed both by Bill Janssen and by Andrew Koenig (needless to say I
> agree): abilities should be able to imply contracts that go beyond a
> collection of methods (without necessarily being able to express those
> contrac
I'd like to take the opportunity to present another example of what
I'd like to be able to do with abilities and generic functions. It's
short on implementation and I don't want to emphasize syntax, but it's
high on concepts. The baseline assumption is that most built-in
operations, especially bina
on 11/24/2006 12:34 AM Guido van Rossum wrote:
> I would like to end up in a world where, in order to claim that a
> class is a standard mapping class, the class definition would
> (normally) explicitly claim to implement StandardMapping (using as yet
> unspecified syntax)
Guido,
In my world
htt
> Let's see your implementation. Zope's interface system fails on at
> least points 3 and 5. And regarding #1, Zope's implementation of the
> basic features I described is an order of magnitude more complex, even
> if you compare *just* its code that implements adaptation and
> interface inherita
Phillip J. Eby wrote:
> At 08:29 PM 11/22/2006 -0800, Guido van Rossum wrote:
> >One thing that rubs me the wrong way about generic functions is that
> >it appears to go against OO. Now I'm not someone to take OO as
> >religion, but there's something uncomfortable (for me) about how, in
> >Phillip'
At 09:53 PM 11/23/2006 +, Paul Moore wrote:
>OK. So under your proposal, all Python functions are (potentially)
>generic, and addmethod is how you add extra overloads? (And hasmethod
>is pretty obvious, and defop AFAICT is a syntax for addmethod, is that
>right?)
>
>Did I get that right?
Yes,
On 11/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:55 PM 11/23/2006 +, Paul Moore wrote:
> >On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I'm reposting this under a different subject because the other subject
> > > seems to have gone off on a tangent. The rest are P
At 03:54 PM 11/23/2006 -0500, Phillip J. Eby wrote:
>5. Generic functions are easily grasped as a dynamic version of overloading
>as seen in other languages (including C#, Java, C++, etc., where there's no
>built-in notion of "adaptation")
Oh, and I forgot: they're also easily understood as generi
At 06:14 PM 11/23/2006 -0200, Gustavo Niemeyer wrote:
>(...)
> > A few important points here:
> >
> > 1. A basic interface mechanism is extemely simple to implement, given
> > generic functions
>(...)
>
>All of these points are completely true for interfaces implemented
>without generic functions.
(...)
> A few important points here:
>
> 1. A basic interface mechanism is extemely simple to implement, given
> generic functions
(...)
All of these points are completely true for interfaces implemented
without generic functions.
In fact, I fail to recognize in your mail a reason why generic
fu
> At 10:14 AM 11/23/2006 -0200, Gustavo Niemeyer wrote:
> >This is true for generic functions as well, except that
> >instead of using an IFruit interface, you have a fruit()
> >generic function which handles the adaptation. Unfortunately,
> >this model doesn't work with more complex hierachies.
>
At 10:43 AM 11/23/2006 -0800, Guido van Rossum wrote:
>Changing the class can't add fields to the C struct that represent the
>object (since that would mean realloc()'ing the object and hence
>potentially changing its address). So why not make this a capability
>of the base function type, rather th
On 11/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:55 PM 11/23/2006 +, Paul Moore wrote:
> >On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I'm reposting this under a different subject because the other subject
> > > seems to have gone off on a tangent. The rest are P
At 05:55 PM 11/23/2006 +, Paul Moore wrote:
>On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I'm reposting this under a different subject because the other subject
> > seems to have gone off on a tangent. The rest are Phillip's words.
>[...]
>
>OK, I've read and tried to digest thi
On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm reposting this under a different subject because the other subject
> seems to have gone off on a tangent. The rest are Phillip's words.
[...]
OK, I've read and tried to digest this. It looks good. The one thing
I'm still not getting, a
I'm reposting this under a different subject because the other subject
seems to have gone off on a tangent. The rest are Phillip's words.
--Guido
-- Forwarded message --
From: Phillip J. Eby <[EMAIL PROTECTED]>
Date: Nov 22, 2006 10:01 PM
Subject: Re: [Python-3000] Special methods
Ian Bicking wrote:
> Walter Dörwald wrote:
>> What happens, if I do the following
>>
>> @PrettyPrinter.pformat.when(object=list)
>> def foo(...):
>>...
>>
>> @PrettyPrinter.pformat.when(object=object)
>> def foo(...):
>>...
>>
>> How does it know which isinstance() check to do first?
>
>
Nick Coghlan wrote:
>Unfortunately the rules for choosing *which* implementation to dispatch to,
>even if restricting things to concrete types only, are necessarily complex.
>
>As Walter pointed out, the deliberately simplistic sample code elsewhere in
>this thread dispatches to a different method
Tim Hochberg wrote:
> Rewriting this using "distributed" adapters looks like this:
>
> >>> pprint = Protocol('pprint')
I suppose this means that Protocol('pprint') implies an interface like:
class IPprint(Interface):
def __call__(object):
"""print the pretty representation of the
Walter Dörwald wrote:
> What happens, if I do the following
>
> @PrettyPrinter.pformat.when(object=list)
> def foo(...):
>...
>
> @PrettyPrinter.pformat.when(object=object)
> def foo(...):
>...
>
> How does it know which isinstance() check to do first?
It can see that isinstance(list, o
Phillip J. Eby wrote:
> At 11:03 PM 4/3/2006, Ian Bicking wrote:
>
>>Guido van Rossum wrote:
>>
>>>On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>>
As an alternative to adaptation, I'd like to propose generic functions.
I think they play much the same role, except they are much simp
At 11:03 PM 4/3/2006, Ian Bicking wrote:
>Guido van Rossum wrote:
>>On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>>As an alternative to adaptation, I'd like to propose generic functions.
>>> I think they play much the same role, except they are much simpler to
>>>use and think about.
>>Give
Ian Bicking wrote:
> As an alternative to adaptation, I'd like to propose generic functions.
> I think they play much the same role, except they are much simpler to
> use and think about.
Unfortunately the rules for choosing *which* implementation to dispatch to,
even if restricting things t
On 4/4/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> > Perhaps. The import-for-side-effect requirement sounds like a
> > showstopper though.
>
> There's a bunch of places where this is a problem. This is a problem
> anywhere you want to add functionality to something that doesn't belong
> to you.
Ian Bicking wrote:
> Guido van Rossum wrote:
>
>[...]
>> What does when(object=list) mean? Does it do an isinstance() check?
>
> Yes; I think RuleDispatch has a form (though I can't remember what the
> form is -- it isn't .when()).
What happens, if I do the following
@PrettyPrinter.pformat.w
Guido van Rossum wrote:
> On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>> As an alternative to adaptation, I'd like to propose generic functions.
>> I think they play much the same role, except they are much simpler to
>> use and think about.
>
> Given that Phillip Eby is another proponent
On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> As an alternative to adaptation, I'd like to propose generic functions.
> I think they play much the same role, except they are much simpler to
> use and think about.
Given that Phillip Eby is another proponent of generic functions I
seriously
As an alternative to adaptation, I'd like to propose generic functions.
I think they play much the same role, except they are much simpler to
use and think about.
Though RuleDispatch offers considerably more features through predicate
dispatch, it would probably be best to just consider type
34 matches
Mail list logo
