Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> One of the comments made on Georg's initial attempt at implementing
>> these features was that it would be nice to avoid the function call
>> overhead in the listcomp & setcomp case ... I tried to do that and
>> essentially failed outright
>
> Not h
On 3/7/07, Talin <[EMAIL PROTECTED]> wrote:
> I would like to know, what is the current status of the
> following issues:
>-- Generic Functions
>-- Interfaces
These two were heavily tied to annotations; one option would have been
to introduce them at the same time as an example use.
Give
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 8, 2007, at 12:15 PM, Jim Jewett wrote:
>>-- Generic Functions
>>-- Interfaces
>
> These two were heavily tied to annotations; one option would have been
> to introduce them at the same time as an example use.
>
> Given that annotations
On 3/8/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
On Mar 8, 2007, at 12:15 PM, Jim Jewett wrote:
[Guido]
>>-- Generic Functions
>>-- Interfaces
>
> These two were heavily tied to annotations; one option would have been
> to introduce them at the same time as an example use.
>
> Given t
> In any case, I would like to know, what is the current status of the
> following issues:
>
>-- Generic Functions
>-- Interfaces
>-- Metaclass syntax
>
> It's not my intention to start a big thread about these
I don't see how you can avoid it -- that's the reason there's no PEP.
I
At 11:49 PM 3/7/2007 -0800, Talin wrote:
>Function decorators + argument decorators already provide everything
>needed for a third-party developer to implement generic functions on
>their own. In other words - you could create an add-on module that
>provides the proper function decorators that woul
Bill Janssen wrote:
>> In any case, I would like to know, what is the current status of the
>> following issues:
>>
>>-- Generic Functions
>>-- Interfaces
>>-- Metaclass syntax
>>
>> It's not my intention to start a big thread about these
>
> I don't see how you can avoid it -- that's
Guido van Rossum wrote:
> I don't think a consensus has been reached on any of these.
>
> My votes:
>
> - generic functions: no
> - interfaces: no, but I'd like to work on ABCs instead
> - metaclass syntax: I'd like to see your PEP
I've gone back and read all of the threads on Metaclasses, and h
> This is distinct from duck typing in the
> general case, where you are calling a method on an object, not
> introspecting it. The latter is an essential part of Python, and any
> attempt to deprecate it is not only likely to fail, but will probably
> elicit enough of a defensive reaction as t
At 11:54 AM 3/8/2007 -0800, Bill Janssen wrote:
>I further believe that relying on so-called "duck typing" runtime
>partial information probes is a fragile and error-prone way to build
>software, and that it should be deprecated in favor of "supports this
>interface" tests.
And I believe that "sup
Guido's Py3K presentation of February 14th (available on Google Video at
this URL: http://video.google.com/videoplay?docid=1189446823303316785)
contains the following statement:
"It is unlikely that you will be able to write both code that is both
valid Python 2.6 source code and valid Python 3
Barry Warsaw wrote:
> We already have an established, community accepted implementation of
> interfaces,
Really? Which one is that?
--
Greg
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubs
On 09/03/2007 0.18, Talin wrote:
> Guido's Py3K presentation of February 14th (available on Google Video at
> this URL: http://video.google.com/videoplay?docid=1189446823303316785)
> contains the following statement:
>
> "It is unlikely that you will be able to write both code that is both
> v
Bill Janssen wrote:
> Calling a method on an object doesn't seem like duck-typing to
> me, though.
It's duck typing in the sense that you don't have to
formally declare the object as conforming to some
interface before you can call the method.
--
Greg
_
I was revisiting my patch on SF to remove sys.exitfunc (per PEP 3100),
and I found some usages in the stdlib I had missed the first time
around. One of these, I was surprised to learn, is atexit.py; in fact,
atexit is implemented in terms of sys.exitfunc. This was especially
shocking because PEP 31
Rename it to sys._exitfunc?
On 3/8/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> I was revisiting my patch on SF to remove sys.exitfunc (per PEP 3100),
> and I found some usages in the stdlib I had missed the first time
> around. One of these, I was surprised to learn, is atexit.py; in fact,
> at
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Barry Warsaw wrote:
|
| > We already have an established, community accepted implementation of
| > interfaces,
|
| Really? Which one is that?
I was wondering too. Has there been a concrete PEPed proposal that I
missed?
17 matches
Mail list logo
