Paul Moore wrote:
> On 4/7/06, Eli Stevens (WG.c) <[EMAIL PROTECTED]> wrote:
>> It seems to me that now to get a duck-typed list, not only do you have
>> to implement all of special methods that define "listy-ness," you also
>> have to find the overloaded functions that are specialized for lists,
>
At 12:58 PM 4/7/2006 -0700, "Eli Stevens (WG.c)" <[EMAIL PROTECTED]>
wrote:
>Guido van Rossum wrote:
> > Did you forget duck typing? Something can be a sequence without
> > subclassing a common base class.
>
>
>
>I'm curious what effect overloaded functions will have on duck typing; a
>Something c
On 4/7/06, Eli Stevens (WG.c) <[EMAIL PROTECTED]> wrote:
> I'm curious what effect overloaded functions will have on duck typing; a
> Something can act like a list, but from my understanding of the
> discussion* it won't end up matching:
>
> @pprint.register(list)
> def pprint_list(obj):
> pas
On 4/7/06, Eli Stevens (WG.c) <[EMAIL PROTECTED]> wrote:
> It seems to me that now to get a duck-typed list, not only do you have
> to implement all of special methods that define "listy-ness," you also
> have to find the overloaded functions that are specialized for lists,
> and register your own
Guido van Rossum wrote:
> On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> An Interface is an abstract class that you subclass to make it a
>> concrete implementation.
>
> That's not the view of most people who use the word interface these
> days. Not in Zope (see Fred Drake's post), not in
Guido van Rossum sagte:
> On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> An Interface is an abstract class that you subclass to make it a concrete
>> implementation.
>
> That's not the view of most people who use the word interface these days. Not
> in Zope (see Fred Drake's post), not i
On Friday 07 April 2006 14:43, Walter Dörwald wrote:
> You use the int() protocol to get an int from a string:
> int("42"), the same way as you use the Sequence() protocol to get a
> Sequence. (And if you're passing a long string, (i.e. int(100*"42")) you
> don't even get an int.
Not all singl
On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> An Interface is an abstract class that you subclass to make it a
> concrete implementation.
That's not the view of most people who use the word interface these
days. Not in Zope (see Fred Drake's post), not in Java.
> If you have an adapter t
Guido van Rossum wrote:
> On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>> Using @overloaded functions I would create an explicit class variable
>>> which is the @overloaded adapter rather than trying to make the
>>> interface also *be* the adapter. I would define the Interface class
>>> l
On 4/7/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Friday 07 April 2006 14:33, Guido van Rossum wrote:
> > OTOH if you really like to express implementing an interface as
> > inheriting from that interface, what's the problem with inheriting the
> > adapter?
>
> Ugh! Inheritance shou
Jim Jewett wrote:
> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>
>> class Sequence(Interface):
>> def getitem(self, index): pass
>> def len(self): pass
>
>> class PythonSeqAsSequence(Sequence):
>> def __init__(self, obj):
>>self.obj = obj
>
>> def getitem(self,
Walter Dörwald wrote:
>Guido van Rossum wrote:
>
>
>
>>On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>
>>
>>>But might closes off one route we could take if we're adapting to
>>>something that must provide more than one function/method (i.e. an
>>>interface) and we'd like to have the
On Friday 07 April 2006 14:33, Guido van Rossum wrote:
> OTOH if you really like to express implementing an interface as
> inheriting from that interface, what's the problem with inheriting the
> adapter?
Ugh! Inheritance should only be done to get implementation. If there's value
in default
On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> > Using @overloaded functions I would create an explicit class variable
> > which is the @overloaded adapter rather than trying to make the
> > interface also *be* the adapter. I would define the Interface class
> > like this:
> >
> > class Int
Guido van Rossum wrote:
> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> But might closes off one route we could take if we're adapting to
>> something that must provide more than one function/method (i.e. an
>> interface) and we'd like to have the interface and the adaption registry
>> b
On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> class Sequence(Interface):
> def getitem(self, index): pass
> def len(self): pass
> class PythonSeqAsSequence(Sequence):
> def __init__(self, obj):
>self.obj = obj
> def getitem(self, index):
>return self.obj[
On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> But might closes off one route we could take if we're adapting to
> something that must provide more than one function/method (i.e. an
> interface) and we'd like to have the interface and the adaption registry
> be identical. Suppose we're desi
Nick Coghlan wrote:
> [...]
> So your example would become:
>
> class MetaInterface(type):
> def __new__(mcl, name, bases, dict):
> # Give each class it's own registry
> cls = type.__new__(mcl, name, bases, dict)
> cls.registry = {}
> return cls
>
>
Walter Dörwald wrote:
> But if adapting is done via __call__() we have a problem: Sequence
> already provides a __call__, the constructor. Of course if this worked
>
> print Sequence([1,2,3]).len()
>
> would look much better than
>
> print Sequence.adapt([1,2,3]).len()
>
> but I'm not sure if
Guido van Rossum wrote:
> On 4/4/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> [...]
>> def __init__(self, name, doc=''):
>> self.name = name
>> self.registry = {}
>> self.__doc__ = doc
>> self.all_protocols.add(self)
>> def __repr__(self):
>> retur
Guido van Rossum wrote:
>On 4/4/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
>(Could you not change the subject each time? Or if you do, could you
>assume the reader hasn't necessarily read your previous posts? For
>gmail users like me, each subject change starts a new thread -- like
>in newsgrou
On Apr 4, 2006, at 9:03 PM, Guido van Rossum wrote:
...
> It would be useful to compare this to adaptation built on top of
> generic functions. Alex seems to be convinced that adaptation is more
> powerful than generic functions; but he hadn't considered the
> possibility of having a generic f
On 4/4/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
(Could you not change the subject each time? Or if you do, could you
assume the reader hasn't necessarily read your previous posts? For
gmail users like me, each subject change starts a new thread -- like
in newsgroups -- and having so far ignored
Considering generic function in combination adaption led to one more
small change in the Protocol implementation that I'm playing with, and
all of the sudden I'm left with something that I could actually use.
What I realized was that you could factor out the part that potentially
has a lot of
24 matches
Mail list logo
