On 17 Nov 2006, at 8:22 PM, Bill Janssen wrote:
Greg Ewing wrote:
George Sakkis wrote:
And for two, not everyone feels comfortable with duck typing. People
who consider (for better or for worse) isinstance() safer than
hasattr()/getattr() would be accomodated too.
The trouble is that buil
On 11/17/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Bill Janssen wrote:
> > Checking for some textual attributes of a
> > type
>
> Now you're talking about LYBL, which is generally
> considered an anti-pattern in Python. APIs should
> be designed so that you don't need to test for the
> presence o
I've just come up with an idea that I think may help clarify this discussion
in a new way. I'm afraid the description is going to be a little long; but
I'd appreciate it if you would bear with me and read the whole thing.
I'd like to start by coining a usage, namely the "abilities" of a type. By
On 11/15/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
>
> > Fredrik, I am not arguing for the argument's sake, I just don't get
> > it: Python requires my class to define __len__, otherwise len() fails.
> > Why not require len() as a method instead and forget about __len__ ?
On 11/18/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> On 11/15/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > I'm convinced that it's better for people to get over that silly notion
> > that writing x.foo() is somehow always "better" than writing foo(x), in
> > a language that actually supports
Bill Janssen wrote:
> But when you do have to test, it would be nice to be able to
> test for a semantic item rather than a syntactic one.
In your own code, there's nothing to stop you from
creating your own interface classes to use in your
own tests.
But when it comes to interoperating with oth
Andrew Koenig wrote:
> Some people in this discussion have suggested that the Pythonic
> way to answer this question is to try to use it as an iterator and see if it
> raises an exception.
That's not what I would say. I would say that you
should design your code so that you don't *need*
to find ou
George Sakkis wrote:
> The end user may not have to explicitly test for it, but it happens
> anyway behind the scenes; x.foo is functionally equivalent to
> if hasattr(x,'foo'): return getattr(x,'foo')
> else: raise AttributeError()
Well, yes, but the point is that since this is being
done automa
Andrew Koenig wrote:
> In other words, whether or not we choose to define a family of types that
> stand for particular abilities, I think we should not use inheritance as the
> mechanism for specifying that a particular class has a particular ability.
> I don't know what the mechanism should be, b
On 11/18/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> (Although I will point out
> that most protocols for things like len() *do* involve checks for special
> methods by name, and the check for iterability is typically a non-destructive
> call to iter(x), rather than a destructive one to x.next()
On 11/18/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> I've just come up with an idea that I think may help clarify this discussion
> in a new way. I'm afraid the description is going to be a little long; but
> I'd appreciate it if you would bear with me and read the whole thing.
>
> I'd like to
Guido van Rossum wrote:
> I realize that Java- and Zope-style interfaces *seem* to be all about
> syntax (they define names and signatures of methods but not semantics)
> but IMO that's only a theoretical objection; in *practice* these
> interfaces have strong connotations of semantics (albeit writ
Guido van Rossum wrote:
> On 11/18/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> (Although I will point out
>> that most protocols for things like len() *do* involve checks for
>> special
>> methods by name, and the check for iterability is typically a
>> non-destructive
>> call to iter(x), rat
13 matches
Mail list logo
