>>> 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():
...
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 <[EMAIL PROTECTED]&g
en aliased.
-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/
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
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
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/
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 calli
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.
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]> wr
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.or
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
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 A(o
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
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 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 t
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 b
[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 differ
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,
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. Wh
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
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 metho
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
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 wel
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 descri
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
pro
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:
>
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 a
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:
> http://mail.python.org/pipermail/pyt
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
http://mail.python.org/pipermail/p
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
>
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, 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
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
> foll
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 c
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
> 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
>
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
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?
>
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
> fun
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 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 usag
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
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
43 matches
Mail list logo
