Nick Coghlan wrote:
> Aaron Bingham wrote:
>
>> Bill Janssen wrote:
>>
Java interfaces are very useful, however. Java programming seems to
be less and less about inheritance and more and more about
implementing interfaces; at least it does amongst Java programmers
with taste
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
Fredrik Lundh wrote:
> George Sakkis wrote:
>
>> First off, I never implied someone's stupid just because we don't
>> happen to agree on everything.
>
> brushing off a carefully thought out design and the process that led
> up to it with "it's just like picking between two random colors" is a
>
George Sakkis wrote:
> First off, I never implied someone's stupid just because we don't
> happen to agree on everything.
brushing off a carefully thought out design and the process that led
up to it with "it's just like picking between two random colors" is a
pretty direct way of saying that yo
I need to move away from the GMail client for lists or they need to
fix it. Sorry Guido, forwarding to the list as GMail should be doing
in the first place!
-- Forwarded message --
From: Calvin Spealman <[EMAIL PROTECTED]>
Date: Nov 23, 2006 2:10 AM
Subject: Re: [Python-3000] defop
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's world, many things become func
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, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> This whole thing seems a bit off from start to finish. A seperate
> definition syntax with a special name/expression weirdo thingy, etc.
I have the same gut feelings but find it hard to explain why.
But I've learned to trust my gut -- even
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
At 10:59 PM 11/22/2006 -0500, Calvin Spealman wrote:
>Perhaps we could allow a special type of key in __dict__'s (and
>__slots__'s ?) that was more than a simple string name but included a
>namespace or context in which the name was to be understood. Even a
>simple 2-tuple would be enough. (operato
On 11/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I chose len(x) over x.len() for HCI reasons
> >
> > (a) For some operations, prefix notation just reads better than
> > postfix
> > (b) When I read code that says len(x) I *know* that it is asking for
> > the length of
Feel free to ignore it if you find it trivial/stupid/irrelevant; many
other apparently didn't.
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It could have been a much shorter thread without you.
>
> On 11/22/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > If you consider distraction
It could have been a much shorter thread without you.
On 11/22/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> If you consider distraction a thread that drew more than 100 replies,
> many of them very insightful (including Andrew Koenig's about
> abilities that has spawned 3-4 new threads), please
If you consider distraction a thread that drew more than 100 replies,
many of them very insightful (including Andrew Koenig's about
abilities that has spawned 3-4 new threads), please allow me to
disagree.
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Your presence here has been enti
This whole thing seems a bit off from start to finish. A seperate
definition syntax with a special name/expression weirdo thingy, etc.
Anyway, we need something that handles this but isnt specific to this.
There are other situations it may be useful. Essentially we want to
have names that are known
Your presence here has been entirely a distraction. That's a troll to me.
On 11/22/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 11/22/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > > Although I don't necessarily agree with the arg
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
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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
Guido van Rossum wrote:
> I chose len(x) over x.len() for HCI reasons
>
> (a) For some operations, prefix notation just reads better than
> postfix
> (b) When I read code that says len(x) I *know* that it is asking for
> the length of something.
Just as a matter of interest, how far do you
think
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, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> 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 r
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
> I don't know anything by CLOS.
I'll drop off a copy of the book on Monday. Lord knows we have
zillions of extra copies floating around PARC.
Bill
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
> > 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 your c
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
> 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
Python-3000@python.org
http://mail
> 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
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
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
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
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
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
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()'.)
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
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
Python-3000@python.org
http://mail.python.org/mailman/list
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 ;-)
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
> 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
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
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
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
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
> 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, 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
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 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 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, 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
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
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
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
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
> 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
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, 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
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
[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
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
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
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
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 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
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
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
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
1 - 100 of 127 matches
Mail list logo
