Le jeudi 06 avril 2006 à 17:10 -0700, Guido van Rossum a écrit :
> On 4/6/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> > But overloaded methods as they exist now have exactly the same
> > expression as non-overloaded methods, all the machinery (mro walking
> > etc.) being hidden from the program
Michael Chermside wrote:
> (I'm going out on a limb here, claiming that I'm right and Nick
> is wrong, but I'm going to stand by the claim anyhow. Anything
> which is machine readable "sometimes" is, by my definition, NOT
> machine readable!)
I was just being sloppy with my terminology by includin
Phillip J. Eby wrote:
> At 02:15 PM 4/6/2006, Guido van Rossum wrote:
>> On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> > I don't want to discourage people from working out their own ideas,
>> > but a lot of the stuff that's being discussed here about protocol
>> > adaptation is already im
Greg Ewing writes:
> "Multiple dispatch"
+1
How is the noun spelled? "Multiple Dispatch Function"? Too wordy perhaps? I
like it anyhow.
-- Michael Chermside
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/p
Guido van Rossum wrote:
> On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> So, when I say that "overload" has the wrong connotations, I'm not
>> talking about some abstract understanding of what it is or does, I'm
>> talking about the wrong connotations for their practical intuition of
>> ho
At 07:37 AM 4/7/2006, Jim Jewett wrote:
>On 4/7/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Guido wrote:
> > > mros = tuple(t.__mro__ for t in types)
> > > n = len(mros)
> > > candidates = [sig for sig in self.registry
> > > if len(sig) == n and
>
On 4/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I've been stealing liberally from PyProtocols all along, usually trying to
> grasp ways to take *concepts* from it that I liked, and turn them into
> something that seemed *usable* (with aesthetics playing a large part in that).
Perhaps you coul
On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> But might closes off one route we could take if we're adapting to
> something that must provide more than one function/method (i.e. an
> interface) and we'd like to have the interface and the adaption registry
> be identical. Suppose we're desi
On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Guido wrote:
> > mros = tuple(t.__mro__ for t in types)
> > n = len(mros)
> > candidates = [sig for sig in self.registry
> > if len(sig) == n and
> > all(t in mro for t, mro
On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> class Sequence(Interface):
> def getitem(self, index): pass
> def len(self): pass
> class PythonSeqAsSequence(Sequence):
> def __init__(self, obj):
>self.obj = obj
> def getitem(self, index):
>return self.obj[
Guido van Rossum wrote:
> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> But might closes off one route we could take if we're adapting to
>> something that must provide more than one function/method (i.e. an
>> interface) and we'd like to have the interface and the adaption registry
>> b
On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> > Using @overloaded functions I would create an explicit class variable
> > which is the @overloaded adapter rather than trying to make the
> > interface also *be* the adapter. I would define the Interface class
> > like this:
> >
> > class Int
On Friday 07 April 2006 14:33, Guido van Rossum wrote:
> OTOH if you really like to express implementing an interface as
> inheriting from that interface, what's the problem with inheriting the
> adapter?
Ugh! Inheritance should only be done to get implementation. If there's value
in default
Walter Dörwald wrote:
>Guido van Rossum wrote:
>
>
>
>>On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>
>>
>>>But might closes off one route we could take if we're adapting to
>>>something that must provide more than one function/method (i.e. an
>>>interface) and we'd like to have the
Jim Jewett wrote:
> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>
>> class Sequence(Interface):
>> def getitem(self, index): pass
>> def len(self): pass
>
>> class PythonSeqAsSequence(Sequence):
>> def __init__(self, obj):
>>self.obj = obj
>
>> def getitem(self,
On 4/7/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Friday 07 April 2006 14:33, Guido van Rossum wrote:
> > OTOH if you really like to express implementing an interface as
> > inheriting from that interface, what's the problem with inheriting the
> > adapter?
>
> Ugh! Inheritance shou
Guido van Rossum wrote:
> On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>> Using @overloaded functions I would create an explicit class variable
>>> which is the @overloaded adapter rather than trying to make the
>>> interface also *be* the adapter. I would define the Interface class
>>> l
On 4/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Even with the cache I put in? The hairy algorithm doesn't get invoked
> more than once per actual signature (type tuple).
OK, I timed this, and the @overloaded function (when it hits the
cache) is indeed 4-7 times slower than a handwritten d
On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> An Interface is an abstract class that you subclass to make it a
> concrete implementation.
That's not the view of most people who use the word interface these
days. Not in Zope (see Fred Drake's post), not in Java.
> If you have an adapter t
On Friday 07 April 2006 14:43, Walter Dörwald wrote:
> You use the int() protocol to get an int from a string:
> int("42"), the same way as you use the Sequence() protocol to get a
> Sequence. (And if you're passing a long string, (i.e. int(100*"42")) you
> don't even get an int.
Not all singl
On 4/4/06, Gareth McCaughan <[EMAIL PROTECTED]> wrote:
> I take no stand on how much not confusing Lispers matters
> to Python 3k.
But I do: none whatsoever.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
P
"Michael Chermside" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Greg Ewing writes:
>> "Multiple dispatch"
>
> +1
>
> How is the noun spelled? "Multiple Dispatch Function"? Too wordy perhaps?
> I
> like it anyhow.
-1
To me, multiple dispatch mean dispatching on multiple argume
Terry Reedy wrote:
> "Michael Chermside" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>Greg Ewing writes:
>>
>>>"Multiple dispatch"
>>
>>+1
>>
>>How is the noun spelled? "Multiple Dispatch Function"? Too wordy perhaps?
>>I
>>like it anyhow.
>
>
> -1
>
> To me, multiple dis
Basic idea:
[for ... in ...]+ if ...:
body
A) it should be syntatically simple to parse.
B) it establishes a nice symetry with list comprehensions.
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.com
___
Python-300
On 4/7/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> Basic idea:
>
> [for ... in ...]+ if ...:
> body
>
> A) it should be syntatically simple to parse.
> B) it establishes a nice symetry with list comprehensions.
Are you in cahoots with the person who posted the first response to my
Artima
I'm not really sure what that guy is talking about.
Sorry,
On 4/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/7/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> > Basic idea:
> >
> > [for ... in ...]+ if ...:
> > body
> >
> > A) it should be syntatically simple to parse.
> > B) it
On 4/7/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> So, for example:
>
> [ x(i) for i in range(n) if y(i) ]
>
> Could be represented as:
>
> for i in range(n) if y(i):
> x(i)
I don't think many Python users will consider that an improvement.
It's really just saving an indent level a
I'm working on an application that allows user to write models
(currently python scripts) that get run on my grid of servers. My
application is written in python, pyrex and C and I would have liked to
use python for the user scripts as well. However, given that there is no
way to run restricted
Guido van Rossum wrote:
> On 4/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> I've been stealing liberally from PyProtocols all along, usually trying to
>> grasp ways to take *concepts* from it that I liked, and turn them into
>> something that seemed *usable* (with aesthetics playing a large par
Nick Coghlan wrote:
> With a change in type.__call__() to check the class extension registry
> before calling cls.__new__(), the above would put us well on the way to
> making
> all types extensible. For example, we could make a class of our own behave
> like a dictionary, returning its keys
30 matches
Mail list logo
