Jim Jewett wrote:
> On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>> While this is more verbose than sticking an 'if' into the original
>> sendmail(), note that it can also be added by a third party, via:
>
>> overload smtpblib.SMTP.sendmail(
>> self, from_addr, to_addrs:
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> While this is more verbose than sticking an 'if' into the original
> sendmail(), note that it can also be added by a third party, via:
> overload smtpblib.SMTP.sendmail(
> self, from_addr, to_addrs:str, msg,
> mail_op
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 09:24 AM 11/22/2006 -0800, Bill Janssen wrote:
> > In Java, SMTP.sendmail would be something like this (using Python-like
> > syntax 'cause my Java is rusty):
> > def sendm
On 11/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/25/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Personally, I stand by my assessment that they can make metaclasses
> > look straightforward -- but that is partly because metaclasses have
> > had their roughest edges worn off already
> It may also be that only a good unified solution to "A" is needed in order to
> allow library and user code to be written "easier" to address "B","C" and
> "D".
> It may even be just doing "A" is a good enough 95% solution (works well
> enough
> for 95% of actual use cases) and nothing more
On 11/25/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Personally, I stand by my assessment that they can make metaclasses
> look straightforward -- but that is partly because metaclasses have
> had their roughest edges worn off already. (For example, they no
> longer require compiling a C class so
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'd much rather have a few "big" interfaces (Number,
> RealNumber, Integer) than lots of small ones
> Pedroni-style (number-that-support-exponentiation,
> number-that-supports-bitwise-and,
> number-that-supports-left-shift, ...?).
My under
At 04:52 PM 11/26/2006 -0500, Jim Jewett wrote:
>On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 08:36 AM 11/22/2006 -0500, Benji York wrote:
> > >It seems to me that not all interfaces coincide with
> > >something the object can _do_. ...
>
> > Aren't these also *operations* being p
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:36 AM 11/22/2006 -0500, Benji York wrote:
> >It seems to me that not all interfaces coincide with
> >something the object can _do_. ...
> Aren't these also *operations* being performed?
ISafeForThreading may boil down to certain oper
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/22/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> > Another effect of __special__ methods is that they divide
> > the class namespace into two parts: The __special__ names
> > are those that have to be implemented to support core
> >
Jim Jewett wrote:
>> Sorry, but that was about as informative as a "+1" vote.
>
> I found it a bit more specific on two points:
>
> What I (mis?)read was:
>
> (1)
> PJE: Interfaces rely on buyin; they end up accidentally creating
> walled gardens. Generic Functions make fewer demands, so they st
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/22/06, Jonathan LaCour <[EMAIL PROTECTED]> wrote:
> > Phillip J. Eby wrote:
> > > In essence, interfaces turn libraries into "frameworks", but generic
> > > functions turn frameworks into libraries. I didn't really discover
> > > th
On 11/23/06, Dave Anderson <[EMAIL PROTECTED]> wrote:
> Interfaces
> ==
> iter_interface = interface(iter) # class-based interface
> file_open_close_inter = interface(file.open, file.close) # method interface
[ strings were also treated differently ]
Are you keying off the dot in the nam
"Kay Schluehr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Seems like we need more formal procedures for writing test than
> application code. This also solves the problem of expense of
> "verification" of typeclasses/concepts/abilities that need to be done
> just once for a cla
Greg Ewing schrieb:
>Gustavo Niemeyer wrote:
>
>
>>Are you arguing that
>>pretty much every approach being discussed is bad and
>>we should instead implement something magically
>>transforming types?
>>
>>
>
>No, I'm questioning the need to do anything at all.
>I don't see a big problem that
Greg Ewing wrote:
> Gustavo Niemeyer wrote:
>> Are you arguing that
>> pretty much every approach being discussed is bad and
>> we should instead implement something magically
>> transforming types?
>
> No, I'm questioning the need to do anything at all.
> I don't see a big problem that merits a h
Phillip J. Eby wrote:
> Calling people names isn't particularly conducive to a technical
> discussion...
Sorry, I didn't mean it to sound that way. I was just
making reference to a concept elucidated elsewhere --
invoking an "argument pattern", so to speak.-)
What I'm saying is that, because th
Gustavo Niemeyer wrote:
> Are you arguing that
> pretty much every approach being discussed is bad and
> we should instead implement something magically
> transforming types?
No, I'm questioning the need to do anything at all.
I don't see a big problem that merits a heavyweight
solution like a for
> Yes, and that's where it falls down, as far as I can
> see. It's not just that it's "not quite" automatic,
> it's almost completely *non*-automatic. Given that,
> I see little benefit in having a formal mechanism
> for it.
I don't see your point here. Are you arguing that
pretty much every appr
Gustavo Niemeyer wrote:
> If you have an adapter from Apple to IFruit, any user
> requiring an IFruit interface for an object will be
> able to obtain it from Apple instances. The "automatically"
> part is not quite true, as adaptation must be explicitly
> requested.
Yes, and that's where it fal
At 10:53 AM 11/23/2006 -0800, Guido van Rossum wrote:
>On 11/22/06, Thomas Lotze <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> >
> > >> I'm sure you're aware about it, but in Zope 3 terminology, these are
> > >> 'provide' and 'implement', respectively.
> > >
> > > I like provide, but I'm
On 11/22/06, Thomas Lotze <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >> I'm sure you're aware about it, but in Zope 3 terminology, these are
> >> 'provide' and 'implement', respectively.
> >
> > I like provide, but I'm not so sure about implement, since it is awfully
> > ambiguous --
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.
You've got
Smells a bit like the rejected PEP 245 doesn't it? You should at least
explain how it differs in a summary or rationale.
Anyway, it's Thanksgiving day here, and I'm unlikely to be able to
spend much time on this collection of threads until Monday or so...
And even then I'll have other work to do -
> IMO the difference between ABCs and interfaces/abilities is that
> inserting a new ABC into an existing class hierarchy without modifying
> its source code is considered a hack, and must be done by a helper
> routine that *actually* mucks with __bases__; while (Zope-style)
> interfaces use an ext
Proposal Summary
Add 2 new keywords: implements, implement
(alternatively, implements and implement can be implemented as object
level functions)
Add new built-in function: interface
Add new object level function: does_implement
(with minor corrections in Implementation of Inter
Proposal Summary
Add 2 new keywords: implements, implement
(alternatively, implements and implement can be implemented as object
level functions)
Add new built-in function: interface
Add new object level function: does_implement
Interfaces
==
There is a fight between u
> I was under the impression that Zope's actual use cases for
> instance-specific interfaces have mainly to do with *view* lookups and
> other types of lookups that don't really come into the current
> discussion scope as I understand it. That is, I thought that instance
> interfaces were used pri
> > Consider 'iter()', for example, which can be viewed as adapting an
> > object to the "iteration interface" and returning an object
> > supporting iteration.
>
> An architecture astronaut might view it that way, but
> I don't. To my way of thinking, iter(x) creates a new
> object that iterates
> Sure, but then there's no need for a formal framwork
> for defining interfaces and adaptation -- by making
> use of duck typing, the joint user of the two libraries
> can wrap things as needed to make it all work.
You can always do everything in another way, just like
you don't need OO to be abl
On 11/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> So, the generic function 'as_string' here functions as an "interface" or
> "ability". Of course, instead of being called 'as_string', it could live
> as an attribute of the 'str' type, e.g. 'str.cast':
OK, I think I just "clicked" with what
Guido van Rossum wrote:
>> I'm sure you're aware about it, but in Zope 3 terminology, these are
>> 'provide' and 'implement', respectively.
>
> I like provide, but I'm not so sure about implement, since it is awfully
> ambiguous -- most of the time it is the class that does the implementing.
> Th
Phillip J. Eby wrote:
>> (but I'm suspect that my view of "generics" is somewhat different from
>> Phillips, so let's focus on fully understanding his proposal first)
>
> So now I'm curious.
Me too. Let me see if I can figure out what it is, well enough to write
it down.
> Maybe it's better.
Phillip J. Eby wrote:
> That kludge, as you call it, is something called idempo... whoops, I
> almost used an architecture word there!
No, that's a mathematical term. And while Greg wasn't using that word,
he was actually talking about its CS form, where it means something
similar, but not
At 04:33 PM 11/23/2006 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > Consider 'iter()', for example, which can be viewed as adapting an object
> > to the "iteration interface" and returning an object supporting iteration.
>
>An architecture astronaut might view it that way, but
Calling peo
On 11/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > So I would have expected something like:
> >
> > str.lower[MyStringType] = MyStringType.lower
> > str.split[MyStringType] = MyStringType.split
>
> But that would only work if everyone switched to
> writing str.lo
Phillip J. Eby wrote:
> Consider 'iter()', for example, which can be viewed as adapting an object
> to the "iteration interface" and returning an object supporting iteration.
An architecture astronaut might view it that way, but
I don't. To my way of thinking, iter(x) creates a new
object that i
Steven Bethard wrote:
> So I would have expected something like:
>
> str.lower[MyStringType] = MyStringType.lower
> str.split[MyStringType] = MyStringType.split
But that would only work if everyone switched to
writing str.lower(s) everywhere instead of s.lower(),
etc. In other words, abol
Gustavo Niemeyer wrote:
> The user of both libraries may define how Apple adapts to
> IFruit.
Sure, but then there's no need for a formal framwork
for defining interfaces and adaptation -- by making
use of duck typing, the joint user of the two libraries
can wrap things as needed to make it all w
Bill Janssen wrote:
> Typically, they're values that I've gotten back from other people's
> APIs
Can you give an example? I'm having a hard time
trying to think of an API that I've used which
returns unpredictable types.
Maybe it's those other APIs that need to be
redesigned?
--
Greg
__
On 11/22/06, Jonathan LaCour <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
>
> > In essence, interfaces turn libraries into "frameworks", but generic
> > functions turn frameworks into libraries. I didn't really discover
> > this until January of last year, though, when I did some experiments
Phillip J. Eby wrote:
> In essence, interfaces turn libraries into "frameworks", but generic
> functions turn frameworks into libraries. I didn't really discover
> this until January of last year, though, when I did some experiments
> in replacing various PEAK interfaces with generic functions.
> Bill Janssen wrote:
>
> > I seem to spend a lot of time inside functions looking over values and
> > figuring out what to do do with them,
>
> If you're really spending that much time doing
> things like that, I'd strongly suggest you take
> a step back and re-think your APIs.
>
> --
> Greg
T
> I don't quite see how that works. Where exactly is
> the adaptation supposed to be done? It can't be done
> in libapple, because libfruit didn't exist when it
> was written. Is libfruit supposed to adapt everything
> it's given to IFruit just in case it's necessary?
> That seems like a lot of ext
Bill Janssen wrote:
> I seem to spend a lot of time inside functions looking over values and
> figuring out what to do do with them,
If you're really spending that much time doing
things like that, I'd strongly suggest you take
a step back and re-think your APIs.
--
Greg
Gustavo Niemeyer wrote:
> With interfaces, all you need to do is define an adapter from Apple
> to IFruit, and instantly all the widely available frameworks will
> be handling apples just fine.
I don't quite see how that works. Where exactly is
the adaptation supposed to be done? It can't be done
Andrew Koenig wrote:
> it feels natural to me to speak
> of a class as "having the totally ordered ability".
That doesn't sound natural to me at all.
If you were speaking about a person with brown
eyes, would you say that they "had the brown
eyes ability"?
--
Greg
___
At 04:14 PM 11/22/2006 -0800, Guido van Rossum wrote:
>But that's a limitation of Java interfaces (and perhaps of Zope
>interfaces); it doesn't have to be a limitation of Python 3000
>abilities.
Agreed -- but some people made statements that implied this was their
prototypical vision of "interfac
I was trying to make it so that the factory is part of library 1 and
really returns As, which however can be turned into Bs without adding
new functionality, merely by marking them as such -- but the
assumption is that we don't have a convenient way to modify the
factory so that it marks the object
At 03:30 PM 11/22/2006 -0800, Guido van Rossum wrote:
>Oh, it would all be so much easier if we could all be in the same room
>for a day...
Well, there's always Skype/Gtalk et al... :)
>The problem often seems to be that I don't have the imagination to
>come up with a suitable implementation for
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> My point is that I'm not trying to create a "bad rep", I'm just emphasizing
> that it's easier/more useful to define interfaces as collections of generic
> operations, because it makes the simple cases simple and powerful, and the
> complex o
> I'm concerned about the additional wrinkle where there is a library
> that calls the factory to produce A's and then turns around and passes
> them on to *another* library. Now the other can deal with A's but has
> recently been upgraded so that it works much better with B's; but it
> doesn't kno
At 12:36 AM 11/23/2006 +0100, Fredrik Lundh wrote:
>well, if it looks nice, what's keeping us from having that? ;-)
Hear hear. ;)
>(but I'm suspect that my view of "generics" is somewhat different from
>Phillips, so let's focus on fully understanding his proposal first)
So now I'm curious. Wh
Touche.
I think what I was trying to argue is that I probably wouldn't have
written it using function overloading, but I would have liked to write
the if-test using has_ability(to_addrs, String) instead of
isinstance(to_addrs, basestring). (The fact that I even wrote
basestring suggests that I was
I'm concerned about the additional wrinkle where there is a library
that calls the factory to produce A's and then turns around and passes
them on to *another* library. Now the other can deal with A's but has
recently been upgraded so that it works much better with B's; but it
doesn't know that A's
At 03:19 PM 11/22/2006 -0800, Guido van Rossum wrote:
>I consider it a waste of time since the if-version works and there's
>no reason for it to be extensible.
But if that's true, then there's no reason for it to use interfaces,
either, is there? :) It seems like a double standard to say, "well
Guido van Rossum wrote:
> Now if we had the nice syntax you propose I probably would have used
> it.
well, if it looks nice, what's keeping us from having that? ;-)
(but I'm suspect that my view of "generics" is somewhat different from
Phillips, so let's focus on fully understanding his proposa
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> The problem I have sometimes in making my proposals clear to you is that,
> at the level of abstraction I think on, there are often multiple ways to
> carry out a useful/usable implementation, but you seem to want to
> understand one *particu
> On 11/22/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Something like
> >
> > class MyNewClass (ExistingClass,
> > OtherInterfaceIJustNoticedExistingClassImplements):
> > pass
>
> No, unless you can also patch up all code that creates ExistingClass
> instances. You alluded to this befor
I consider it a waste of time since the if-version works and there's
no reason for it to be extensible. There's only so much time we can
spend on each program before we move on; perfection isn't always
desirable, just working well enough.
Now if we had the nice syntax you propose I probably would
Bill Janssen a écrit :
>
> I see nothing wrong with defining "empty" ABCs to indicate abilities
> rather than interfaces.
>
>class WellTested (Ability):
> """Indicates that the type has passed the QA process"""
> pass
>
>class TestedNumber (Number, WellTested):
> ...
>
An
Guido van Rossum wrote:
> Examples that keep recurring are things like
> the smtplib.SMTP.sendmail() method, whose second argument is either a
> string or a list of strings. The optimal way of writing this, IMO, is
> a single method that typechecks its 2nd argument. It currently uses
> "if isinsta
On 11/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > as was the case for ABC, Python's ill-fated predecessor which invented
> > "optimal" terminology in a vacuum
>
> optimal? I've always thought it was just odd translations from dutch?
No, dutch was not involved
Guido van Rossum wrote:
> as was the case for ABC, Python's ill-fated predecessor which invented
> "optimal" terminology in a vacuum
optimal? I've always thought it was just odd translations from dutch?
(but please, cannot we get the trains back in Python 3.0? my son would
*love* that ;-)
Phillip J. Eby wrote:
> Perhaps I should try giving implementations explicitly labelled as
> prototypes
tends to work.
> and stating that there are other ways to do the same thing?
that's kind of implied in any proposal posted to this list, isn't it?
___
> Well, this assumes automatic adaptation (which is off the table), *or*
> everything that uses IFruits must always explicitly invoke some
(...)
> You've lost me here. A less abstract example might work better.
Sorry.. I should have provided a good concrete example in
the first place. Here it goe
At 01:00 PM 11/22/2006 -0800, Guido van Rossum wrote:
>On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>The first statement creates a function called 'sendmail', and the
>>subsequent statement overloads it. Of course, I suppose 'defop' could also
>>be spelled differently to emphasize the d
On Wed, 22 Nov 2006, Guido van Rossum wrote:
> On 11/22/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > > Hm, I would think it extends very naturally to instance variables, and
> > > I see no reason why it's a particularly bad idea to also extend it
> > > (mostly in our minds anyway, I expect) to
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:43 AM 11/22/2006 -0800, Guido van Rossum wrote:
> >There is a dangerous amount of content-free rhetoric in this thread.
>
> Actually, I think that some of my statements are being misunderstood as
> such, when I'm intending only to descr
At 06:29 PM 11/22/2006 -0200, Gustavo Niemeyer wrote:
>Without interfaces, we won't be able to say "in all places, use the
>generic method registered for an IFruit whenever an Apple is seen".
...for some definition of "interface". :)
Dylan has "protocols", Haskell has "typeclasses", and they do
At 12:28 PM 11/22/2006 -0800, Guido van Rossum wrote:
>So maybe there are even less differences between the different POVs.
Yep.
>I'm not arguing that generics aren't strictly more powerful than
>interfaces -- I just think that interfaces don't necessarily deserve
>the bad rep you're creating fo
At 10:43 AM 11/22/2006 -0800, Guido van Rossum wrote:
>There is a dangerous amount of content-free rhetoric in this thread.
Actually, I think that some of my statements are being misunderstood as
such, when I'm intending only to describe *how* interfaces (or inspection)
can be *derived* from gen
On 11/22/06, Gustavo Niemeyer <[EMAIL PROTECTED]> wrote:
> > 2. Do we need interfaces if we have generic functions?
> >
> > Phillip Eby argues that we don't need interfaces, because the right
> > API for generic functions makes it easy to do what we do with
> > interfaces. Let me paraphrase his arg
> 2. Do we need interfaces if we have generic functions?
>
> Phillip Eby argues that we don't need interfaces, because the right
> API for generic functions makes it easy to do what we do with
> interfaces. Let me paraphrase his argument.
I agree that we don't *need* interfaces to have generic fu
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> In other words, this isn't some sort of moral judgment regarding the
> "purity" of interfaces or inspection, it's merely a comment about how best
> to *construct* them. Building interfaces in the Java/Zope style (as mere
> collections of met
At 11:16 AM 11/22/2006 -0800, Robert Brewer wrote:
>Phillip J. Eby wrote:
> > The real problem here is that type inspection violates
> > encapsulation and the whole point of being "object-oriented"
> > in the first place. The point of OO is that it lets you
> > *hide* the implementation. If you p
At 10:31 AM 11/22/2006 -0800, Guido van Rossum wrote:
>In *my* notion of abilities, this part being inspired by Zope
>interfaces, you can state after the fact that a particular class
>(which you didn't write) provides a given ability (which you didn't
>write either). I think it would also be great
Phillip J. Eby wrote:
> The real problem here is that type inspection violates
> encapsulation and the whole point of being "object-oriented"
> in the first place. The point of OO is that it lets you
> *hide* the implementation. If you put the implementation
> in an if-then branch, you've just l
On 11/22/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Something like
>
> class MyNewClass (ExistingClass,
> OtherInterfaceIJustNoticedExistingClassImplements):
> pass
No, unless you can also patch up all code that creates ExistingClass
instances. You alluded to this before and it sounded l
> More of a tagging approach, then?
>
> Something like
>
> class MyNewClass (ExistingClass,
> OtherInterfaceIJustNoticedExistingClassImplements):
> pass
>
> ?
Maybe, maybe not. I'm not sure. I'm thinking that it may be useful to be
able somehow to assert that pre-existing class C has pr
On 11/22/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > I think this deviates from Haskell, which seems to be big on
> > structural type equivalence (?).
I may be mistaken, but I thought that in Haskell, if there's a
typeclass composed of methods X and Y (with appropriate signatures),
every obje
> > Andrew Koenig writes:
> > > For example, I can imagine a single interface having multiple
> > > abilities.
>
> > Perhaps because it inherits from multiple sub-interfaces?
>
> Or perhaps because after the interface was defined, someone noticed that it
> happened to have those abilities and wan
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:24 AM 11/22/2006 -0800, Bill Janssen wrote:
> >I seem to spend a lot of time inside functions looking over values and
> >figuring out what to do do with them, actions which don't involve
> >invoking further functions, but rather operati
> I think it would also be great if we had "ability
> algebra" whereby you could state that a given ability A is composed of
> existing abilities A1 and A2, and every object or class that already
> has A1 and A2 will automatically be considered to have A.
Yes!
> However, I do *not* want to go the
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:42 AM 11/22/2006 -0700, Steven Bethard wrote:
> >Yeah, it certainly seems like in both this case and the string case,
> >there needs to be some shorthand for saying "implements all the basic
> >String/Number/whatever methods".
>
> But w
> Andrew Koenig writes:
> > For example, I can imagine a single interface having multiple
> > abilities.
> Perhaps because it inherits from multiple sub-interfaces?
Or perhaps because after the interface was defined, someone noticed that it
happened to have those abilities and wanted to be able t
At 09:24 AM 11/22/2006 -0800, Bill Janssen wrote:
>I seem to spend a lot of time inside functions looking over values and
>figuring out what to do do with them, actions which don't involve
>invoking further functions, but rather operating directly on those
>values in different ways.
Whereas to me,
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:42 AM 11/22/2006 -0700, Steven Bethard wrote:
> >Yeah, it certainly seems like in both this case and the string case,
> >there needs to be some shorthand for saying "implements all the basic
> >String/Number/whatever methods".
>
> But w
At 09:42 AM 11/22/2006 -0700, Steven Bethard wrote:
>Yeah, it certainly seems like in both this case and the string case,
>there needs to be some shorthand for saying "implements all the basic
>String/Number/whatever methods".
But we are probably better off composing such a concept *from* the meth
Guido wrote:
> On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Actually "ability" is more general than "interface", because interface
> > implies two things talking to one another. Some Zope uses of "interfaces"
> > don't include any actual "interfacing" at all, so to me your examples
>
> At 07:53 PM 11/21/2006 -0800, Bill Janssen wrote:
> >I don't mind having both, but generic functions (interface-based
> >method dispatch) is really only one aspect of the issue.
>
> How so?
>
I think Guido answered this better than I could in
<[EMAIL PROTECTED]>.
I seem to spend a lot of time
Andrew Koenig writes:
> For example, I can imagine a single interface having multiple
> abilities.
Perhaps because it inherits from multiple sub-interfaces?
Bill
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo
> What does it add to have to declare a class as being "Iterable", if it
> already implements __iter__? What does the notion of "Iterable" add
> to the execution *or* understanding of the code?
If you take a standard method which has a well documented meaning,
it's of course non-useful.
Now, let
At 07:53 AM 11/22/2006 -0800, Guido van Rossum wrote:
> If there were an
>interface that means "Behaves like a string" then those few brave
>souls who write their own string implementation from scratch could
>just claim to implement it and their string objects would be welcome
>everywhere.
Okay,
At 11:41 AM 11/22/2006 -0500, Andrew Koenig wrote:
> > What does it add to have to declare a class as being "Iterable", if it
> > already implements __iter__? What does the notion of "Iterable" add to
> > the execution *or* understanding of the code?
>
>Let's suppose for the sake of argument that
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Examples that keep recurring are things like the
> smtplib.SMTP.sendmail() method, whose second argument
> is either a string or a list of strings.
[snip]
> Rewriting this as a generic method
[snip]
> sounds like a total waste of time and c
> What does it add to have to declare a class as being "Iterable", if it
> already implements __iter__? What does the notion of "Iterable" add to
> the execution *or* understanding of the code?
Let's suppose for the sake of argument that declaring a class as being
"Iterable" adds nothing. What d
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Actually "ability" is more general than "interface", because interface
> implies two things talking to one another. Some Zope uses of "interfaces"
> don't include any actual "interfacing" at all, so to me your examples
> actually support cal
At 08:36 AM 11/22/2006 -0500, Benji York wrote:
>It seems to me that not all interfaces coincide with something the object
>can _do_. Some speak to what can be done _to_ an object:
>
>class IAttributeAnnotatable(IAnnotatable):
> """Marker indicating that annotations can be stored on an attrib
On 11/22/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > Hm, I would think it extends very naturally to instance variables, and
> > I see no reason why it's a particularly bad idea to also extend it
> > (mostly in our minds anyway, I expect) to describe certain behaviors
> > that cannot be express
1 - 100 of 125 matches
Mail list logo
