Talin wrote:
>> 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 you consider yourself so much smarter
>> than the people involved that you don't even care about what
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.
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
Bill Janssen wrote:
>> 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?
what makes you so sure that Python's current design isn't "right" ?
_
Greg Ewing wrote:
> Just as a matter of interest, how far do you
> think these principles apply or don't apply
> to more recent things like iter.next() that
> don't follow this pattern?
this has been discussed before, I think. googling for __next__ might
bring up some python-dev discussions.
Guido van Rossum wrote:
> 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
On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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
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
On 11/23/06, Talin <[EMAIL PROTECTED]> wrote:
> 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 wit
> 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
> > 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
> 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
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
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
> 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
Barry Warsaw wrote:
>> 2) for convenience, extend print to treat a format object as a format
>> specifier for the following arguments:
>>
>> print (x, y, z, fmt="My X: %s, Your Y: %s, His Z: %s")
>>
>> becomes
>>
>> print(format("My X: %s, Your Y: %s, His Z: %s"), x, y ,z)
>>
>> 3) get r
Guido van Rossum wrote:
> Hm. While not as obviously from a different universe as Barry's
> proposal, this still pretty weird, probably at least from a different
> planet (much farther than Iceland anyway :-)
it's inspired by
http://online.effbot.org/2006_11_01_archive.htm#et-builder
which
George Sakkis wrote:
> a. Will print have to do an isinstance(args[0], format) to decide what
> to do ? If so, don't the usual arguments for duck typing and against
> type checking apply here ?
isinstance (or an equivalent mechanism) would be more robust, in this
specific case.
> b. print(a,b,c)
On Wed, Nov 22, 2006, Talin wrote:
>
> While I wouldn't say it quite so strongly, I do think that there is a
> great deal of subjectivity in HCI discussions. One person's 'intuitive'
> may be another person's 'orange smoke', as we've seen in the current
> discussion.
But the whole point of maki
On 11/23/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 22, 2006, Talin wrote:
> >
> > While I wouldn't say it quite so strongly, I do think that there is a
> > great deal of subjectivity in HCI discussions. One person's 'intuitive'
> > may be another person's 'orange smoke', as we've seen in t
On 11/22/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Not sure I like this better. My spelling of "operator::XXX" is
> > "__XXX__" and I like that just fine -- no new syntax needed.
>
> Well, that might be a spelling of `operator::XXX
Let me just say -1 on this idea so we can close the thread. None of
that convinces me. I don't think that print(a, b) failing when b has a
certain unexpected type can be considered consistent. The
ElementBuilder example doesn't apply because it takes very limited
argument types (string, dict, E; e
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 -
I'm reposting this under a different subject because the other subject
seems to have gone off on a tangent. The rest are Phillip's words.
--Guido
-- Forwarded message --
From: Phillip J. Eby <[EMAIL PROTECTED]>
Date: Nov 22, 2006 10:01 PM
Subject: Re: [Python-3000] Special methods
On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm reposting this under a different subject because the other subject
> seems to have gone off on a tangent. The rest are Phillip's words.
[...]
OK, I've read and tried to digest this. It looks good. The one thing
I'm still not getting, a
> > 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.
I'll still drop off a copy (of Common Lisp the Language, version 2),
but there's no need to wait. It's on the Web at
http://www.supelec.fr/docs/
At 05:55 PM 11/23/2006 +, Paul Moore wrote:
>On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I'm reposting this under a different subject because the other subject
> > seems to have gone off on a tangent. The rest are Phillip's words.
>[...]
>
>OK, I've read and tried to digest thi
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
> Bill Janssen wrote:
>
> >> 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?
>
> what makes you so sure that Python's current design isn't "right" ?
On 11/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:55 PM 11/23/2006 +, Paul Moore wrote:
> >On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I'm reposting this under a different subject because the other subject
> > > seems to have gone off on a tangent. The rest are P
I have a working optional argument syntax implementation, I'm hoping
to get some direction on
the implementation decisions so far please see below.
Python 3.0x (p3yk:52824M, Nov 23 2006, 09:22:23)
[GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2
Type "help", "copyright", "credits" or "licens
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: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
At 10:00 AM 11/23/2006 -0800, Tony Lownds wrote:
>I have a working optional argument syntax implementation, I'm hoping
>to get some direction on
>the implementation decisions so far please see below.
Why not just have the generated bytecode construct the annotation
dictionary directly and ass
At 10:43 AM 11/23/2006 -0800, Guido van Rossum wrote:
>Changing the class can't add fields to the C struct that represent the
>object (since that would mean realloc()'ing the object and hence
>potentially changing its address). So why not make this a capability
>of the base function type, rather th
> 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.
>
(...)
> A few important points here:
>
> 1. A basic interface mechanism is extemely simple to implement, given
> generic functions
(...)
All of these points are completely true for interfaces implemented
without generic functions.
In fact, I fail to recognize in your mail a reason why generic
fu
On Nov 23, 2006, at 11:21 AM, Phillip J. Eby wrote:
> Why not just have the generated bytecode construct the annotation
> dictionary directly and assign it to the returned function's
> func_annotations, and the same for func_return if needed? Then
> there'd be no need to change the MAKE_FU
Guido van Rossum wrote:
> Your presence here has been entirely a distraction. That's a troll to me.
Steady on, Guido. Trolling is making deliberately
inflammatory statements with the intention of
stirring up controversy. That's a pretty heavy
accusation to make. You're effectively saying
he's sett
At 06:14 PM 11/23/2006 -0200, Gustavo Niemeyer wrote:
>(...)
> > A few important points here:
> >
> > 1. A basic interface mechanism is extemely simple to implement, given
> > generic functions
>(...)
>
>All of these points are completely true for interfaces implemented
>without generic functions.
At 03:54 PM 11/23/2006 -0500, Phillip J. Eby wrote:
>5. Generic functions are easily grasped as a dynamic version of overloading
>as seen in other languages (including C#, Java, C++, etc., where there's no
>built-in notion of "adaptation")
Oh, and I forgot: they're also easily understood as generi
On 11/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:55 PM 11/23/2006 +, Paul Moore wrote:
> >On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I'm reposting this under a different subject because the other subject
> > > seems to have gone off on a tangent. The rest are P
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 09:53 PM 11/23/2006 +, Paul Moore wrote:
>OK. So under your proposal, all Python functions are (potentially)
>generic, and addmethod is how you add extra overloads? (And hasmethod
>is pretty obvious, and defop AFAICT is a syntax for addmethod, is that
>right?)
>
>Did I get that right?
Yes,
> 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:
> 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
Guido van Rossum wrote:
> I fear I will miss the class as a convenient focus for
> related functionality.
I have the same feeling. I get the impression that
generic functions work okay in a language designed
around them from the beginning. But adding them
belatedly to a language built around class
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
On 11/23/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
> I have a working optional argument syntax implementation, I'm hoping
> to get some direction on
> the implementation decisions so far please see below.
Wow!
> Python 3.0x (p3yk:52824M, Nov 23 2006, 09:22:23)
> [GCC 3.4.4 20050721 (Red Hat
On 11/23/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > 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.
>
> I'll still drop off a copy (of Common Lisp the Language, version 2),
> but there's
I'll give you that it may not have been intentional. But the effect is
the same. And I felt rather offended by his offhand rejection of "most
HCI arguments" -- in my view sarcasm is quite a bit more acceptable
than insult. I stick to my point that he is lacking essential social
skills for effective
Phillip J. Eby wrote:
> 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'
Bill Janssen wrote:
> I think method namespaces are already OK; the question is
> whether to move these specially-named (for whatever reason)
> methods to a real namespace (a dict somewhere)
where "somewhere" is exactly where? how do I add things to
that namespace? how do I specify what names
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
54 matches
Mail list logo
