I don't normally start threads, but I wasn't sure who to post this as a reply
to. This thought or direction of discussion, seems like it may be a useful
viewpoint in the type/interface topics.
Python's syntax interacts strongly with a number of basic types. For example
(and in general) a
on 12/7/2006 6:40 PM Greg Ewing wrote:
> Dave Anderson wrote:
>
>> def get_name(arg: AnyClass.name):# AnyClass will magically have
>> return arg.name()# a reference to any method name
>> # somehow
>
> What if you want to say that arg has more
> than one such m
Dave Anderson wrote:
> def get_name(arg: AnyClass.name): # AnyClass will magically have
> return arg.name() # a reference to any method name
> # somehow
What if you want to say that arg has more
than one such method?
--
Greg Ewing, C
On 12/7/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Let me throw out an examples of how this could look.
>
>@implements(sequence.__getitem__, sequence.__len__)
>class MySequence:
>#
>
>@implements(mapping.__getitem__, mapping.keys, mapping.__len__)
>class MyMapping:
>
Tim Hochberg a écrit :
>
> Here goes: to the extent that the semantics aren't clear from the
> methods it is sufficient, and preferable, to attach the semantic
> information to the methods rather their associated class.
>
which imho is the whole of the question: which level of granularity is
d
Talin wrote:
> Phillip J. Eby wrote:
>> At 09:59 AM 12/5/2006 -0600, Guido van Rossum wrote:
>>> My point is that an interface can *document* (at least in English) a
>>> "contract" about the invariants between operations. While I'm not into
>>> enforcing or verifying such contracts, I'm very intere
Guido van Rossum wrote:
> That sounds like a reasonable summary to me. One nit below.
>
Ditto. It was nice to see all the ambiguity cleared up in one fell
swoop. Nicely done.
> On 12/7/06, Talin <[EMAIL PROTECTED]> wrote:
>
>> [2] The reason I think 'interface' are misleading is due to its
That sounds like a reasonable summary to me. One nit below.
On 12/7/06, Talin <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > At 09:59 AM 12/5/2006 -0600, Guido van Rossum wrote:
> >> My point is that an interface can *document* (at least in English) a
> >> "contract" about the invariants b
Phillip J. Eby wrote:
> At 09:59 AM 12/5/2006 -0600, Guido van Rossum wrote:
>> My point is that an interface can *document* (at least in English) a
>> "contract" about the invariants between operations. While I'm not into
>> enforcing or verifying such contracts, I'm very interested in
>> document
Fredrik Lundh wrote:
> Talin wrote:
>
>> OK. Its easy to implement either way. I coded up a string-based version,
>> but if you guys want integer constants that's fine with me; probably
>> best to let Fredrik & Larry tweak their patch rather than me continuing
>> along this path since their stuff
> But, looking
> at the ABC page right now, to implement Dict, I'll need to inherit
> Mapping and MutableContainer.
Dave, I completely feel your pain. I think dict is overly complex
(and Mapping). Almost nobody needs a whole "dict" -- it's become a
grab bag for handy tricks to perform with map
on 12/7/2006 11:25 AM Bill Janssen wrote:
>> To me, even if Car happens to represent a dict by being able to be used
>> as a dict, the expression of this fact feels better expressed as merely
>> implementing dict.
>>
>> compare:
>>
>> class Car(dict): # car... is a dict? hmm, a bad ring to
Dave, thanks.
> To me, even if Car happens to represent a dict by being able to be used
> as a dict, the expression of this fact feels better expressed as merely
> implementing dict.
>
> compare:
>
> class Car(dict): # car... is a dict? hmm, a bad ring to it
> ...
>
> class Car:
>
on 12/7/2006 10:57 AM Hasan Diwan wrote:
> On 07/12/06, Dave Anderson <[EMAIL PROTECTED]> wrote:
>>
>>
>> I feel on a different page from you.
>>
>> My best guess it is that
>>
>> def typeOfSuper(self):
>> pass(subclass)
>>
>> is ceding its implementation to its subclasses, kind of like wh
On 07/12/06, Dave Anderson <[EMAIL PROTECTED]> wrote:
>
>
> I feel on a different page from you.
>
> My best guess it is that
>
> def typeOfSuper(self):
> pass(subclass)
>
> is ceding its implementation to its subclasses, kind of like what an
> abstract class or interface would do
>
> but I
on 12/7/2006 10:06 AM Hasan Diwan wrote:
> The parametrized version of the pass keyword could be used to indicate a
> formal interface.
>
> I may be missing something here, but we already have a mechanism for
> defining that a object defines certain methods. Could we not keep it
> orthogonal
Talin wrote:
> OK. Its easy to implement either way. I coded up a string-based version,
> but if you guys want integer constants that's fine with me; probably
> best to let Fredrik & Larry tweak their patch rather than me continuing
> along this path since their stuff is further along.
wouldn't i
The parametrized version of the pass keyword could be used to indicate a
formal interface.
On 07/12/06, Dave Anderson <[EMAIL PROTECTED]> wrote:
Has-Method Contracts
The first thing I loved about python (coming from java), was this
realization that I was no longer need be
18 matches
Mail list logo
