Terry Reedy schrieb:
> "Brett Cannon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> Why can't the fallback usage just pass the return value from __len__ to
> bool() (forget the C function name) and return that result? It's just like
> doing::
>
> def bool(obj):
> t
Guido van Rossum wrote:
> On 11/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> [...]
>> That's because some generic functions use if-isinstance checks (bad), while
>> others use custom __special__ methods (not bad, but not great), registries
>> (good), adaptation (okay), or generic function lib
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:57 PM 11/21/2006 -0800, Guido van Rossum wrote:
> >Phillip, please shorten your posts. You're hogging all the bandwidth I
> >have for thinking about this. Please!
>
> Er, that *was* the shortened version; I actually spent about an hour
Hello Phillip,
> If we're basing GF's on types, then certainly marker mixins are
> feasible to *use*. I only contend that mixin markers (and other pure
> interfaces devoid of execution effect) are unnecessary and shouldn't
> be encouraged, not that they are or should be impossible.
I don't see a
> 2. a 'defop' syntax as shorthand for 'addmethod()', such that e.g.:
>
> import operator
>
> class Foo:
> defop iter(self):
> ...
> defop len(self):
> ...
> defop operator.getitem(self, key):
> ...
Is "defop" useful?
Why
Antoine wrote:
> Is "defop" useful?
>
> Why wouldn't it be possible to enable special method lookup with this kind
> of syntax:
>
> iter = generic_function()
> iter.lookup_special_method("__iter__")
>
> And then the classical:
>
> class Foo:
> def __iter__(self):
> pass
A major ben
Guido van Rossum wrote:
> 1. Naming and general ideas. Should we call these Abilities or
> Interfaces?
I'll try to make an argument for "Interface" over "Ability" using
examples from Zope.
It seems to me that not all interfaces coincide with something the
object can _do_. Some speak to what ca
> I believe Ka-Ping once proposed something similar. This also jives
> nicely with the "verify" functionality that I mentioned. However, I
> don't know how easy it will be to write such compliance tests given
> that typically the constructor signature is not part of the ability.
> It may be more pr
> Both 'ability' and 'interface' imply (to me, anyway) that the class
> being inspected is an actor, that it 'does something' rather than being
> operated on.
I chose 'ability' because to me it doesn't require that the class being
inspected is active by itself. For example, it feels natural to me
> I'll try to make an argument for "Interface" over "Ability" using
> examples from Zope.
> 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:
When I see the word "interface", I think of the collection of method ca
On 11/22/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > I'll try to make an argument for "Interface" over "Ability" using
> > examples from Zope.
>
> > 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:
>
> When
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 Python interfaces, and the methods
> without underscores are those t
On 11/22/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > Both 'ability' and 'interface' imply (to me, anyway) that the class
> > being inspected is an actor, that it 'does something' rather than being
> > operated on.
>
> I chose 'ability' because to me it doesn't require that the class being
> in
> 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 expressed (easily) in code.
I think of an ability as a property of a
At 11:16 AM 11/22/2006 -0200, Gustavo Niemeyer wrote:
>I've lost you here. As I understand interfaces, their most important
>feature is indeed being a "comment in the form of code", and I hope
>they continue to be that way.
What does it add to have to declare a class as being "Iterable", if it
a
On 11/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:57 PM 11/21/2006 -0800, Guido van Rossum wrote:
> >Phillip, please shorten your posts. You're hogging all the bandwidth I
> >have for thinking about this. Please!
>
> Er, that *was* the shortened version; I actually spent about an hour
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
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, 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
> 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, 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
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
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,
> 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
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
[email protected]
http://mail.python.org/mailman/listinfo
> 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
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 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
On 11/21/06, tomer filiba <[EMAIL PROTECTED]> wrote:
i read the references fredrik posted several days back, and it got
me thinking: why not add a "co_ast" attribute to code objects?
i.e., since (virtually) all code objects are constructed from source
code by compilation, the compiler could jus
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: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,
> 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
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
On Wed, Nov 22, 2006 at 09:36:09AM +0100, Georg Brandl wrote:
> Terry Reedy schrieb:
> > "Brett Cannon" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >
> > Why can't the fallback usage just pass the return value from __len__ to
> > bool() (forget the C function name) and retu
> 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: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
> > 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, 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
> 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, 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
Talking about the Abilities/Interfaces made me think about some of our
"rogue" special method names. In the Language Reference, it says, "A
class can implement certain operations that are invoked by special
syntax (such as arithmetic operations or subscripting and slicing) by
defining methods with
Jack Diederich wrote:
> On Wed, Nov 22, 2006 at 09:36:09AM +0100, Georg Brandl wrote:
>> Terry Reedy schrieb:
>>> "Brett Cannon" <[EMAIL PROTECTED]> wrote in message
>>> news:[EMAIL PROTECTED]
>>>
>>> Why can't the fallback usage just pass the return value from __len__ to
>>> bool() (forget the
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
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
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
[Side remark: I'm sure we would reach understanding and agreement much
quicker if we were all in the same room for a day. Maybe we could try
to have a day at the next PyCon where we hash this out?]
One of the problems that I still have with defop is that it is
presented as pure magic.
On the one
Bill Janssen wrote:
> Though, thinking about it some more, I don't see why *all* syntactic
> operations wouldn't just invoke the appropriate normally-named method
> on a specific ABC. "<", for instance, would presumably invoke
> "object.lessthan" (or perhaps "comparable.lessthan").
Because it's
On 11/22/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Talking about the Abilities/Interfaces made me think about some of our
> "rogue" special method names. In the Language Reference, it says, "A
> class can implement certain operations that are invoked by special
> syntax (such as arithmetic ope
Once all who care agree on the patch, feel free to check it in without
my review.
On 11/22/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> Jack Diederich wrote:
>
> > On Wed, Nov 22, 2006 at 09:36:09AM +0100, Georg Brandl wrote:
> >> Terry Reedy schrieb:
> >>> "Brett Cannon" <[EMAIL PROTECTED]> wr
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
> 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
Guido van Rossum wrote:
> Ivan Krstić explained this more concise in his message, which arrived
> after I'd written all this up.
which is a good thing, because your post is a much better version of
the corresponding FAQ entry than what we came up with when this was last
discussed in this threa
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
Le mercredi 22 novembre 2006 à 11:52 -0800, Guido van Rossum a écrit :
> but how on earth is the defop syntax of the @defop decorator going to
> generate this? I can't see any way to implement it without having
> access to the class object, but that doesn't exist yet at the time
> defop or @defop
You're welcome.
It did occur to me that writing up that particular piece of rationale
would be of value outside this thread -- I had no idea it would be
picked up so quickly. :-)
On 11/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Ivan Krstić explained this more
On 11/22/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Le mercredi 22 novembre 2006 à 11:52 -0800, Guido van Rossum a écrit :
> > but how on earth is the defop syntax of the @defop decorator going to
> > generate this? I can't see any way to implement it without having
> > access to the class ob
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
At 11:52 AM 11/22/2006 -0800, Guido van Rossum wrote:
>Do I understand correctly that the syntax is more like
>
> 'defop' '(' ')' ':'
>
>than like
>
> 'defop' NAME '(' ')' ':'
>
>? (That would need some kind of limitation on the syntax for so
>that it can't contain a call, or else it woul
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 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
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
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
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 11/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Ivan Krstić explained this more concise in his message, which arrived
> > after I'd written all this up.
>
> which is a good thing, because your post is a much better version of
> the corresponding FAQ entry tha
> Saying the same thing in another way, I see 'len' as a built-in
> *operation*. I'd hate to lose that. I can't say for sure whether you
> meant that or not, but 'def len(self): ...' certainly sounds like you
> want to demote it to an ordinary method. I'm strongly -1 on that.
OK, I can see that.
On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> The defop statement (and its decorators if any) would translate to this code:
>
> @
> def ():
>
>
> addmethod(, , enclosing_class_or_None)
Where is it gonna get the enclosing class? That object hasn't been
created ye
Bill Janssen wrote:
> This seems kind of a weak rationale to me, but OK.
yeah, namespaces are such a useless thing. let's put everything in one
big flat namespace, so we don't have to wonder where things are.
___
Python-3000 mailing list
Python-30
George Sakkis wrote:
> After all, HCI-based arguments are usually a fancier way of
> saying "it's a matter of taste"
It would be easier to take you seriously if you gave up that "I don't
understand their arguments; therefore I'm right and they're stupid"
style of argumentation. Mike and others
> 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
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?
___
> Bill Janssen wrote:
>
> > This seems kind of a weak rationale to me, but OK.
>
> yeah, namespaces are such a useless thing. let's put everything in one
> big flat namespace, so we don't have to wonder where things are.
>
>
Pardon me? That's what we've got now, isn't it? That's why we ha
Le mercredi 22 novembre 2006 à 12:47 -0800, Guido van Rossum a écrit :
> > class DefOpDescriptor:
> > def __init__(self, genfunc, implfunc):
> > self.genfunc = genfunc
> > self.implfunc = implfunc
> > def __call__(self, *args, **kargs):
> > # Directly call the implem
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 ;-)
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
Bill Janssen wrote:
> Pardon me? That's what we've got now, isn't it?
no. names of the form "__name__" are distinctly different from names of
the form "name".
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/list
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
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
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
> 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
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
At 02:06 PM 11/22/2006 -0800, Guido van Rossum wrote:
> > (The 'decorate_class' function applies its argument as a class decorator
> > for the class its caller is invoked from. This is the same mechanism (and
> > actual code!) that Zope uses to do in-body class decorators like
> > 'implements()'.)
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
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
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
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
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
On 11/22/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> Although I don't necessarily agree with the arguments from a puristic
> point of view ("then why not make keys(), values(), items(), read(),
> write(), ... builtin GFs ?"), they are indeed a better answer to the
> FAQ entry. After all, HCI-bas
On 11/22/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> 2) But also, if Python was built with interfaces, "special" methods
> would each be in their own namespace. That is, a user wouldn't have
> to worry about accidentally overriding a method; they'd have to
> explicitly override the "len" method
> 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
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
Bill Janssen wrote:
> 1) Mainly, all methods are special to someone.
But some, such as those that have special meaning to the language
itself, are more special than others.
__methods__ are not just plain old methods with funny names. You write
regular methods to express functionality you wish
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
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 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
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
___
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
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
> 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
> Ow, that's the first time you describe this particular wrinkle.
Yep. I hesitated to bring it up, but if there's a need for separate
namespaces for method names, why not do it right?
Bill
___
Python-3000 mailing list
[email protected]
http://mail
> 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
1 - 100 of 127 matches
Mail list logo
