, 2007 12:31 PM
To: Collin Winter
Cc: Python Mailing List
Subject: Re: [Python-Dev] New Super PEP
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote:
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote:
What if the instance
Being able to access the calling frame from IronPython would be really
useful...
We do have a -X:Frames option but it's going to hurt your performance, but for
example:
IronPython 1.0.60816 on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
def f():
... x =
.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Spealman
Sent: Sunday, April 29, 2007 12:31 PM
To: Collin Winter
Cc: Python Mailing List
Subject: Re: [Python-Dev] New Super PEP
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote:
On 4/29/07, Calvin Spealman
On 29/04/2007 17.04, Guido van Rossum wrote:
This is only a halfway fix to DRY, and it really only fixes the less
important half. The important problem with super is that it
encourages people to write incorrect code by requiring that you
explicitly specify an argument list. Since calling
Giovanni Bajo [EMAIL PROTECTED] wrote:
On 29/04/2007 17.04, Guido van Rossum wrote:
Nearly always wrong? You must be kidding. There are tons of reasons to
call your super method with modified arguments. E.g. clipping,
transforming, ...
Really?
http://fuhm.net/super-harmful/
Hmmm.
On 02/05/2007 12.00, Christian Tanzer wrote:
Nearly always wrong? You must be kidding. There are tons of reasons to
call your super method with modified arguments. E.g. clipping,
transforming, ...
Really?
http://fuhm.net/super-harmful/
Hmmm.
I've just counted more than 1600 usages of
Please stop arguing about an opinionated piece of anti-super PR.
On 5/2/07, Giovanni Bajo [EMAIL PROTECTED] wrote:
On 02/05/2007 12.00, Christian Tanzer wrote:
Nearly always wrong? You must be kidding. There are tons of reasons to
call your super method with modified arguments. E.g.
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
Draft Attempt Number Duo:
PEP: XXX
Title: New Super
Checked in as PEP 3133.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
Georg Brandl has just checked this PEP in as 367. I had submitted it
to the [EMAIL PROTECTED] address, per the policy documentation. Sorry if
I subverted some policy order, or was non-vocal about it. I didn't
realize anyone else would check it in.
On 5/1/07, Guido van Rossum [EMAIL PROTECTED]
Totally my screwup. I'll discard 3133.
On 5/1/07, Calvin Spealman [EMAIL PROTECTED] wrote:
Georg Brandl has just checked this PEP in as 367. I had submitted it
to the [EMAIL PROTECTED] address, per the policy documentation. Sorry if
I subverted some policy order, or was non-vocal about it. I
James I did not intend to imply that it should be impossible to pass
James different arguments, only that passing the same ones should be
James foolproof and not require repeating yourself.
Then some other argument syntax than () is needed which clearly means,
pass no arguments.
On 4/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
James I did not intend to imply that it should be impossible to pass
James different arguments, only that passing the same ones should be
James foolproof and not require repeating yourself.
Then some other argument syntax
Hi Calvin,
On Mon, Apr 30, 2007 at 08:34:56AM -0400, Calvin Spealman wrote:
If you want, you can also grab the reference
implementation from my blog: http://ironfroggy-code.blogspot.com/
This reference implementation is broken. It doesn't pass the following
test, for example:
class
On 4/30/07, Armin Rigo [EMAIL PROTECTED] wrote:
Hi Calvin,
On Mon, Apr 30, 2007 at 08:34:56AM -0400, Calvin Spealman wrote:
If you want, you can also grab the reference
implementation from my blog: http://ironfroggy-code.blogspot.com/
This reference implementation is broken. It doesn't
Calvin Spealman wrote:
Comments welcome, of course. Bare with my first attempt at crafting a PEP.
See below for comments; In general, I'm having problems understanding
some of the terms used. I don't have any comments on the technical
merits of the PEP yet, since I don't completely understand
On 29/04/07, James Y Knight [EMAIL PROTECTED] wrote:
On Apr 28, 2007, at 10:43 PM, Calvin Spealman wrote:
Abstract
The PEP defines the proposal to enhance the super builtin to work
implicitly
upon the class within which it is used and upon the instance the
current
function was
2007/4/29, Gustavo Carneiro [EMAIL PROTECTED]:
On 29/04/07, James Y Knight [EMAIL PROTECTED] wrote:
Since calling super with any
arguments other than the exact same arguments you have received is
nearly always wrong,
Erm. Excuse me, but are you saying this code is wrong?
class
James This is only a halfway fix to DRY, and it really only fixes the
James less important half. The important problem with super is that it
James encourages people to write incorrect code by requiring that you
James explicitly specify an argument list. Since calling super with
Since calling super with any
arguments other than the exact same arguments you have received is
nearly always wrong,
Erm. Excuse me, but are you saying this code is wrong?
class Rectangle:
def __init__(self, width, height):
self.width = width
Yes, I bad wordly things did. Fix will I.
On 4/29/07, Talin [EMAIL PROTECTED] wrote:
Calvin Spealman wrote:
Comments welcome, of course. Bare with my first attempt at crafting a PEP.
See below for comments; In general, I'm having problems understanding
some of the terms used. I don't have
On 4/28/07, James Y Knight [EMAIL PROTECTED] wrote:
This is only a halfway fix to DRY, and it really only fixes the less
important half. The important problem with super is that it
encourages people to write incorrect code by requiring that you
explicitly specify an argument list. Since
On 4/28/07, Calvin Spealman [EMAIL PROTECTED] wrote:
[snip]
The PEP defines the proposal to enhance the super builtin to work implicitly
upon the class within which it is used and upon the instance the current
function was called on. The premise of the new super usage suggested is as
follows:
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote:
What if the instance isn't called self? PEP 3099 states that self
will not become implicit; it's talking about method signatures, but I
think that dictum applies equally well in this case.
I don't use the name self. I use whatever the first
Draft Attempt Number Duo:
PEP: XXX
Title: New Super
Version: $Revision$
Last-Modified: $Date$
Author: Calvin Spealman [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Apr-2007
Python-Version: 2.6
Post-History: 28-Apr-2007, 29-Apr-2007
Abstract
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
Draft Attempt Number Duo:
PEP: XXX
Title: New Super
Version: $Revision$
Last-Modified: $Date$
Author: Calvin Spealman [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Apr-2007
Python-Version:
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
[snip]
I still wasn't really aware of any alternative suggestions that need
to be included in this.
Here are two off the top of my head:
http://mail.python.org/pipermail/python-3000/2007-April/006805.html
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote:
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
[snip]
I still wasn't really aware of any alternative suggestions that need
to be included in this.
Here are two off the top of my head:
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote:
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
[snip]
I still wasn't really aware of any alternative suggestions that need
to be included in this.
Here are two off the top
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
The PEP defines the proposal to enhance the super builtin to work implicitly
upon the class within which it is used and upon the instance the current
function was called on. The premise of the new super usage suggested is as
follows:
Hi Calvin,
On Sat, Apr 28, 2007 at 10:43:04PM -0400, Calvin Spealman wrote:
The proposal adds a dynamic attribute lookup to the super type, which will
automatically determine the proper class and instance parameters.
Can you describe how you intend the dynamic attribute lookup to find the
On 4/29/07, Armin Rigo [EMAIL PROTECTED] wrote:
Hi Calvin,
On Sat, Apr 28, 2007 at 10:43:04PM -0400, Calvin Spealman wrote:
The proposal adds a dynamic attribute lookup to the super type, which will
automatically determine the proper class and instance parameters.
Can you describe how you
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote:
What if the instance isn't called self? PEP 3099 states that self
will not become implicit; it's talking about method signatures, but I
think that dictum applies equally well in this
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote:
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
The PEP defines the proposal to enhance the super builtin to work implicitly
upon the class within which it is used and upon the instance the current
function was called on. The premise
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote:
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote:
What if the instance isn't called self? PEP 3099 states that self
will not become implicit; it's talking about method signatures, but
At 01:19 PM 4/29/2007 -0400, Calvin Spealman wrote:
Backward compatability of the super type API raises some issues. Names, the
lookup of the __call__ of the super type itself, which means a conflict with
doing an actual super lookup of the __call__ attribute. Namely, the following
is ambiguous in
Hi Calvin,
On Sun, Apr 29, 2007 at 02:53:58PM -0400, Calvin Spealman wrote:
Yes, it is highly dependent on the new __super__ attribute. See the
reference implementation for the how.
Ah, there is a reference implementation. There is no link to it in the
PEP you posted, hence my confusion.
Gustavo Carneiro wrote:
Erm. Excuse me, but are you saying this code is wrong?
class Rectangle:
def __init__(self, width, height):
self.width = width
self.height = height
class Square:
def __init__(self, side):
Rectangle.__init__(self, side, side)
[EMAIL PROTECTED] wrote:
Since the language doesn't require that a subclassed method take the same
parameters as the base class method, you can't assume that it does.
The argument is that in the special case of a cooperative
super call, it doesn't make sense for the parameter list
to be
Guido van Rossum wrote:
Nearly always wrong? You must be kidding. There are tons of reasons to
call your super method with modified arguments. E.g. clipping,
transforming, ...
That's a good point. Just because the *signature* is the
same doesn't mean the *values* of the parameters need
to be
On Apr 29, 2007, at 9:07 PM, Greg Ewing wrote:
Guido van Rossum wrote:
Nearly always wrong? You must be kidding. There are tons of
reasons to
call your super method with modified arguments. E.g. clipping,
transforming, ...
That's a good point. Just because the *signature* is the
same
On 4/28/07, Calvin Spealman [EMAIL PROTECTED] wrote:
Comments welcome, of course. Bare with my first attempt at crafting a PEP.
PEP: XXX
Title: Super As A Keyword
Version: $Revision$
Last-Modified: $Date$
Author: Calvin Spealman [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
On 4/28/07, Calvin Spealman [EMAIL PROTECTED] wrote:
Comments welcome, of course. Bare with my first attempt at crafting a PEP.
PEP: XXX
Title: Super As A Keyword
Version: $Revision$
Last-Modified: $Date$
Author: Calvin Spealman [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
On Apr 28, 2007, at 10:43 PM, Calvin Spealman wrote:
Abstract
The PEP defines the proposal to enhance the super builtin to work
implicitly
upon the class within which it is used and upon the instance the
current
function was called on. The premise of the new super usage
43 matches
Mail list logo
