At 04:06 PM 11/21/2006 -0800, Guido van Rossum wrote:
>On 11/21/06, Nestor <[EMAIL PROTECTED]> wrote:
> > Do these aproaches allow to do something like the
> > java.util.RandomAccess interface that is just used as a marker?
>
>Zope interfaces certainly do. I don't know about Phillip's
>counter-prop
"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):
try:
return obj.__bool__()
On 11/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:06 PM 11/21/2006 -0800, Guido van Rossum wrote:
> >On 11/21/06, Nestor <[EMAIL PROTECTED]> wrote:
> > > Do these aproaches allow to do something like the
> > > java.util.RandomAccess interface that is just used as a marker?
> >
> >Zope
Terry Reedy wrote:
> If an object without __bool__ returned itself as its length, this
> would be
> an infinite loop, at least in this Python version. Do we worry about
> something so crazy?
Doesn't len() have a requirement that __len__ return an integer? If so,
perhaps it would be better if th
On 11/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:16 AM 11/21/2006 -0800, Guido van Rossum wrote:
> >Phillip then argues that he doesn't want to encourage introspectable
> >interfaces. I think others have use cases for those though.
>
> Examples?
I'll wait for others to speak up, but
> Bill Janssen seems to be in favor of just using ABCs. Pro: less new
> infrastructure. Con: hard to add a new ABC on the fly to an existing
> 3rd party class (mucking with __bases__ is too much of a hack to
> seriously propose).
Don't get me wrong, I think having optional interface-based method
d
> If we have to have interfaces, I think we'd be far better off
> implementing the spec as-is first, and worry about changing the spec
> later (even if if only seems to be an "implied spec" at the moment).
Sure. But we could factor the present spec into pieces.
Bill
_
> I just want a minimal
> core that blesses what the language and stdlib *already* do (special
> methods and single-dispatch __mro__ lookups)
Well, this *is* Py3K. We can fix things that the language doesn't do
but should.
Bill
___
Python-3000 mailin
> I'm asking for a committee to lay this to rest by defining the one
> true hierarchy for containers. Other languages have succeeded in doing
> so (even Java).
Well, I don't think Java has really done this yet. But it's a good
idea. Someone should try to re-describe the standard set of Python
bu
Before delving into any specific points, let me attempt to explain my
assumptions, briefly, because I suspect that you and I do not mean the same
thing by the words "generic function", and thus you perceive me to be
proposing to change things that I am in fact proposing we *not* change.
To me,
Phillip, please shorten your posts. You're hogging all the bandwidth I
have for thinking about this. Please!
On 11/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> The only things I propose to *add*, would be:
>
> 1. functions like 'addmethod()' and 'hasmethod()', themselves to be
> generics in
Guido van Rossum wrote:
> 1. Naming and general ideas. Should we call these Abilities or
> Interfaces? Abilities, the term proposed by Andrew Koenig, have less
> baggage, but possibly they're just an isomorphic relabeling of
> interfaces. From Zope comes the important question: Do we want to
> disc
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 *just*
on shortening it.
I tried to write a short reply to you
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?
___
Python-3000 mailing list
[email protected]
http://mail.python.
14 matches
Mail list logo
