> 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 :-)
It seems to me that that's where Python has a real advantage. With
real support
On 11/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Andrew Koenig wrote:
>
> > That's a nice general sentiment, but not always feasible -- especially if
> > you're writing library code.
>
> I've written a fair bit of library code, and I've never
> found a pressing need to test for an abstract inte
On 11/19/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> PEPs aren't only for difficult discussions. :-) They are also there
> for reference and to record agreement. Referring to an email isn't
> really a very good answer when someone asks (as happened here) "what
> is the
> 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 sh
Andrew Koenig wrote:
> That's a nice general sentiment, but not always feasible -- especially if
> you're writing library code.
I've written a fair bit of library code, and I've never
found a pressing need to test for an abstract interface.
In the rare cases where I've used type testing in an
AP
Antoine Pitrou wrote:
> So to know if "deferred" was correctly used, I had to devise a test to
> know if "timeout" is a number
Another solution might have been to require it to
be passed as a keyword (which will become easier
if the proposal for keyword-only arguments gets
in).
--
Greg
_
Guido van Rossum wrote:
> PEPs aren't only for difficult discussions. :-) They are also there
> for reference and to record agreement. Referring to an email isn't
> really a very good answer when someone asks (as happened here) "what
> is the spec"? A PEP may also discourage attempts to add more
On 11/19/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 11/19/06, James Thiele <[EMAIL PROTECTED]> wrote:
> >> The BDFL has said that print will change from a statement to a function in
> >> Python 3.
> >>
> >> I haven't found anything describing what parameters it wil
Guido van Rossum wrote:
> On 11/19/06, James Thiele <[EMAIL PROTECTED]> wrote:
>> The BDFL has said that print will change from a statement to a function in
>> Python 3.
>>
>> I haven't found anything describing what parameters it will take and what it
>> will return. Has this been decided?
>
> No
On 11/19/06, James Thiele <[EMAIL PROTECTED]> wrote:
> The BDFL has said that print will change from a statement to a function in
> Python 3.
>
> I haven't found anything describing what parameters it will take and what it
> will return. Has this been decided?
Not really, I'm hoping someone would
Le dimanche 19 novembre 2006 à 12:44 -0500, George Sakkis a écrit :
> I understand this is not the point you're trying to make, but in such
> cases I usually prefer to make @decorator be equivalent to
> @decorator() by something like:
I could do that, but it's not very clean. Also it doesn't inva
On 11/19/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> That's perhaps one of the top gotchas in Python today; thankfully it
> will change in 3.0. Until then, I can't see how one can avoid an
> explicit check, either by testing with isinstance() or trying to call
> an arbitrary method of the expect
On 11/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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()
>
>
The BDFL has said that print will change from a statement to a function in
Python 3.
I haven't found anything describing what parameters it will take and what it
will return. Has this been decided?
___
Python-3000 mailing list
Python-3000@python.org
htt
On 11/19/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> I had the problem recently when I wrote a decorator which took an
> optional number as an argument. The decorator declaration goes like
> this:
>
> def deferred(timeout=None):
> def decorate(func):
> blah blah...
> return dec
> It strikes me that one aspect of "being Pythonic" is a strong reliance
> on politeness: that's what duck-typing is all about.
Part of my motivation for entering this discussion is that C++ templates use
duck-typing, and the C++ community has for several years been thinking about
how to add more
> I'm not sure I said anything Guido didn't already say, but I wanted to
> make the distinction between *enforcing* correct behavior and
> *communicating* correct behavior. Java (and Zope, apparently) simply
> have a more formal way of doing this. Stock Python doesn't.
What he said!
___
> This looks like you're rediscovering or reinventing Java- or
> Zope-style interfaces: those are not passed on via inheritance but via
> a separate "implements" clause.
I don't think I'm quite reinventing Java interfaces. In Java, where just
about everything is a method, it's temptingly easy to
> The only completely accurate semantic check is to run
> the program and see if it produces the right result.
If that were possible, we could solve the halting problem :-)
> In other words, don't LBYL, but Just Do It, and use
> unit tests.
A fine idea when it's possible. Unfortunately, it's no
> That's not what I would say. I would say that you
> should design your code so that you don't *need*
> to find out whether it's an iterator or not. Instead,
> you just require an iterator, always, and trust that
> the calling code will give you one. If it doesn't,
> your unit tests will catch tha
On Sat, 18 Nov 2006, Neil Toronto wrote:
> 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
> > interface
On Sat, 18 Nov 2006, Andrew Koenig wrote:
> Now, suppose that every type that signals the presence of an ability
> inherits from "ability". Then we've just broken the whole ability system.
> Because if "iterator" inherits from "ability" and every iterator type
> inherits from "iterator", then eve
Le samedi 18 novembre 2006 à 22:42 -0700, Neil Toronto a écrit :
> Actually, plenty of people would dream of it and even do it. I've seen
> some pretty evil implementations of Java interfaces. All they can
> enforce is static types and method signatures.
But protecting against erroneous use (ra
23 matches
Mail list logo
