Re: [Python-Dev] New Super PEP
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 what is being said. > PEP: XXX > Title: Super As A Keyword > Version: $Revision$ > Last-Modified: $Date$ > Author: Calvin Spealman <[EMAIL PROTECTED]> > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 30-Apr-2007 > Python-Version: 2.6 > Post-History: > > > 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 suggested is as > follows: > > super.foo(1, 2) > > to replace the old: > > super(Foo, self).foo(1, 2) > > > Rationale > = > > The current usage of super requires an explicit passing of both the class and > instance it must operate from, requiring a breaking of the DRY (Don't Repeat > Yourself) rule. This hinders any change in class name, and is often considered > a wart by many. > > > Specification > = > > Replacing the old usage of super, calls to the next class in the MRO (method > resolution order) will be made without an explicit super object creation, > by simply accessing an attribute on the super type directly, which will > automatically apply the class and instance to perform the proper lookup. The > following example demonstrates the use of this. I don't understand the phrase 'by simply accessing an attribute on the super type directly'. See below for for more detail. > :: > > class A(object): > def f(self): > return 'A' > > class B(A): > def f(self): > return 'B' + super.f() > > class C(A): > def f(self): > return 'C' + super.f() > > class D(B, C): > def f(self): > return 'D' + super.f() > > assert D().f() == 'DBCA' > The example is clear enough. > The proposal adds a dynamic attribute lookup to the super type, which will > automatically determine the proper class and instance parameters. Each super > attribute lookup identifies these parameters and performs the super lookup on > the instance, as the current super implementation does with the explicit > invokation of a super object upon a class and instance. When you say 'the super type' I'm not sure what you mean. Do you mean the next class in the MRO, or the base class in which the super method is defined? Or something else? What defines the 'proper' class? Can we have a definition of what a "super object" is? > The enhancements to the super type will define a new __getattr__ classmethod > of the super type, which must look backwards to the previous frame and locate > the instance object. This can be naively determined by located the local named > by the first argument to the function. Using super outside of a function where > this is a valid lookup for the instance can be considered undocumented in its > behavior. As I am reading this I get the impression that the phrase 'the super type' is actually referring to the 'super' keyword itself - for example, you say that the super type has a new __getattr__ classmethod, which I read as saying that you can now say "super.x". > Every class will gain a new special attribute, __super__, which is a super > object instansiated only with the class it is an attribute of. In this > capacity, the new super also acts as its own descriptor, create an instance- > specific super upon lookup. I'm trying to parse that first sentence. How about "Every class will gain a new special attribute, __super__, which refers to an instance of the associated super object for that class". What does the phrase 'the new super' refer to - they keyword 'super', the super type, or the super object? > Much of this was discussed in the thread of the python-dev list, "Fixing super > anyone?" [1]_. > > Open Issues > --- > > __call__ methods > > > 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 the current proposal: > > :: > > super.__call__(arg) > > Which means the backward compatible API, which involves instansiating the > super > type, will either not be possible, because it will actually do a super lookup > on the __call__ attribute, or there will be no way to perform a super lookup > on > the __call__ attribute. Both seem unacceptable, so any suggestions are > welcome. > > super type's new getattr > > > To give the behavior needed,
Re: [Python-Dev] Python 2.5.1
> I'm sorry, but somehow I could not parse this. My understanding was > that the unittest was meant to make sure an os.stat call would be > successful on an open file, and that pagefile.sys was simply used as a > known open file, which is no longer correct. No. The unit test was meant to test that os.stat is successful on an open file on which 2.5 reported ERROR_SHARING_VIOLATION. I believe it was not the case that it would report ERROR_SHARING_VIOLATION when stat'ing arbitrary open files, but just open files where some additional conditions must be met. I might be misremembering - I *think* I tried to write the test case just like you did, and it could not trigger the bug. I then concluded that I could not figure out what these additional conditions were, and that it *had* to be the pagefile. So please verify that your new test indeed breaks on 2.5.0 (or undo r54686). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
> After some googling it seems to me that this could > likely be a User Rights Assignment issue of a systems > file not an open file stat one, hence the Access > denied error message (winerror 5) that I got in WinXP, > as opposed to the File not found windows error > (winerror 2) which one might expect if the > pagefile.sys did not exist. Ah - I didn't check what the error number is. If you can get ERROR_ACCESS_DENIED, then most likely we need to check for ERROR_FILE_NOT_FOUND as well (as your original patch did) - it would be good if somebody confirmed that the modified test indeed passes/gets skipped when the pagefile is not on C: > And therefore if the point of the test is just to test > stating an open file then the temporary file approach > makes sense. If modifying a systems file with or > without User Rights Assignment is a requirement then > we may need a new test altogether. The test should ideally verify that you can stat all open files in 2.5 that you could also stat in 2.4. If you get ERROR_ACCESS_DENIED when stat'ing c:\pagefile.sys in 2.5, I would *hope* that you get a similar error from 2.4. If 2.4 could stat c:\pagefile.sys and 2.5 gives ERROR_ACCESS_DENIED, then the bug still isn't fixed. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
Khalid A. Bakr schrieb: > For reference, this is the result of running the > regression tests of the official Python 2.5.1 (final) > on Win98. I think I saw it in the installtion screen > that Python 2.5 is the last release to support Win98. > > Even though the unicode tests failing might be > expected, what interested me was the fact that > test_1565150 of test_os failed. Details follow. Ah, ok. This means that the test is bogus. On Win95 (and, strictly speaking, NT+ installed on FAT), the test will certainly fail, because FAT has no subsecond resolution for file modification times (it doesn't even have second resolution - the granularity is 2s). This failure does not bother me much - os.stat itself works just fine on this system. If you want to contribute a patch to skip the test on W9x, please go ahead - but IMO, there is no harm done having this test fail on W9x for the rest of 2.5.x. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
> On Windows there is no guarantee that there will be a pagefile.sys on
> the C drive, or even that there exists a C drive. The test checking for
> the result of os.stat('C:\\pagefile.sys') is broken. Create a temporary
> file, open it with Python, then stat it (like you later suggest).
> Either that or use sys.executable . Either one would likely be fine.
As I said - I'm not convinced that is indeed correct. Before accepting
a replacement test I would like confirmation that this test will fail
on 2.5.0. You might not get ERROR_SHARING_VIOLATION in all cases of
open files with 2.5.0.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 called on. The premise of the new super usage > suggested is as > follows: > > super.foo(1, 2) > > to replace the old: > > super(Foo, self).foo(1, 2) > > > Rationale > = > > The current usage of super requires an explicit passing of both the > class and > instance it must operate from, requiring a breaking of the DRY > (Don't Repeat > Yourself) rule. This hinders any change in class name, and is often > considered > a wart by many. 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 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 self.height = height class Square: def __init__(self, side): Rectangle.__init__(self, side, side) Or are you even saying this type of code is rare? I would disagree with both statements, therefore I also disagree with your recommendation. -- Gustavo J. A. M. Carneiro "The universe is always one step beyond logic." -- Frank Herbert ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 Rectangle: > def __init__(self, width, height): > self.width = width > self.height = height > > class Square: > def __init__(self, side): > Rectangle.__init__(self, side, side) You probably mean "class Square(Rectangle):". Anyway it's not wrong, but it isn't multiple-inheritance-friendly either. -- Lino Mastrodomenico E-mail: [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 any James> arguments other than the exact same arguments you have received James> is nearly always wrong, requiring that the arglist be specified James> is an attractive nuisance. 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. super() should simply mean "call with no arguments". ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I'm sorry, but somehow I could not parse this. My understanding was > > that the unittest was meant to make sure an os.stat call would be > > successful on an open file, and that pagefile.sys was simply used as a > > known open file, which is no longer correct. > > No. The unit test was meant to test that os.stat is successful on an > open file on which 2.5 reported ERROR_SHARING_VIOLATION. I believe > it was not the case that it would report ERROR_SHARING_VIOLATION > when stat'ing arbitrary open files, but just open files where some > additional conditions must be met. I might be misremembering - I > *think* I tried to write the test case just like you did, and it > could not trigger the bug. I then concluded that I could not figure > out what these additional conditions were, and that it *had* to > be the pagefile. > > So please verify that your new test indeed breaks on 2.5.0 (or > undo r54686). > > Regards, > Martin Some record of this or documentation of just what conditions the tests are expecting to test against would probably be a good idea. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > On Windows there is no guarantee that there will be a pagefile.sys on
> > the C drive, or even that there exists a C drive. The test checking for
> > the result of os.stat('C:\\pagefile.sys') is broken. Create a temporary
> > file, open it with Python, then stat it (like you later suggest).
> > Either that or use sys.executable . Either one would likely be fine.
>
> As I said - I'm not convinced that is indeed correct. Before accepting
> a replacement test I would like confirmation that this test will fail
> on 2.5.0. You might not get ERROR_SHARING_VIOLATION in all cases of
> open files with 2.5.0.
But i am running 2.5.0 during my entire writing of this patch. I've
not upgraded my laptop to 2.5.1 yet, although I verified against
another installation of 2.5.1 before publishing.
--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
> Some record of this or documentation of just what conditions the tests > are expecting to test against would probably be a good idea. There is the sourceforge tracker item. If that is insufficient, feel free to add more information. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
>> As I said - I'm not convinced that is indeed correct. Before accepting >> a replacement test I would like confirmation that this test will fail >> on 2.5.0. You might not get ERROR_SHARING_VIOLATION in all cases of >> open files with 2.5.0. > > But i am running 2.5.0 during my entire writing of this patch. I've > not upgraded my laptop to 2.5.1 yet, although I verified against > another installation of 2.5.1 before publishing. And you saw your test pass? Then it is not a valid test case for the bug being test, because the bug is present in 2.5.0, so your test case should fail there. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
> 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 > self.height = height > > class Square: > def __init__(self, side): > Rectangle.__init__(self, side, side) That's not what he said. Your code does not call super(), so the observation that it normally should pass the exact same arguments does not apply. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 any comments on the technical > merits of the PEP yet, since I don't completely understand what is being > said. > > > PEP: XXX > > Title: Super As A Keyword > > Version: $Revision$ > > Last-Modified: $Date$ > > Author: Calvin Spealman <[EMAIL PROTECTED]> > > Status: Draft > > Type: Standards Track > > Content-Type: text/x-rst > > Created: 30-Apr-2007 > > Python-Version: 2.6 > > Post-History: > > > > > > 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 suggested is as > > follows: > > > > super.foo(1, 2) > > > > to replace the old: > > > > super(Foo, self).foo(1, 2) > > > > > > Rationale > > = > > > > The current usage of super requires an explicit passing of both the class > > and > > instance it must operate from, requiring a breaking of the DRY (Don't Repeat > > Yourself) rule. This hinders any change in class name, and is often > > considered > > a wart by many. > > > > > > Specification > > = > > > > Replacing the old usage of super, calls to the next class in the MRO (method > > resolution order) will be made without an explicit super object creation, > > by simply accessing an attribute on the super type directly, which will > > automatically apply the class and instance to perform the proper lookup. The > > following example demonstrates the use of this. > > I don't understand the phrase 'by simply accessing an attribute on the > super type directly'. See below for for more detail. > > > :: > > > > class A(object): > > def f(self): > > return 'A' > > > > class B(A): > > def f(self): > > return 'B' + super.f() > > > > class C(A): > > def f(self): > > return 'C' + super.f() > > > > class D(B, C): > > def f(self): > > return 'D' + super.f() > > > > assert D().f() == 'DBCA' > > > > The example is clear enough. > > > The proposal adds a dynamic attribute lookup to the super type, which will > > automatically determine the proper class and instance parameters. Each super > > attribute lookup identifies these parameters and performs the super lookup > > on > > the instance, as the current super implementation does with the explicit > > invokation of a super object upon a class and instance. > > When you say 'the super type' I'm not sure what you mean. Do you mean > the next class in the MRO, or the base class in which the super method > is defined? Or something else? What defines the 'proper' class? There is some ambiguous nature there that I missed. I think I used the same term for both the super type, as in the actual builtin type named "super" and to refer to the next type in the MRO order after the current type. What proper terminology would differentiate? > Can we have a definition of what a "super object" is? An instance of the builtin type named "super". Something for which isinstance(o, super) is True. > > The enhancements to the super type will define a new __getattr__ classmethod > > of the super type, which must look backwards to the previous frame and > > locate > > the instance object. This can be naively determined by located the local > > named > > by the first argument to the function. Using super outside of a function > > where > > this is a valid lookup for the instance can be considered undocumented in > > its > > behavior. > > As I am reading this I get the impression that the phrase 'the super > type' is actually referring to the 'super' keyword itself - for example, > you say that the super type has a new __getattr__ classmethod, which I > read as saying that you can now say "super.x". Yes. > > Every class will gain a new special attribute, __super__, which is a super > > object instansiated only with the class it is an attribute of. In this > > capacity, the new super also acts as its own descriptor, create an instance- > > specific super upon lookup. > > I'm trying to parse that first sentence. How about "Every class will > gain a new special attribute, __super__, which refers to an instance of > the associated super object for that class". Check. > What does the phrase 'the new super' refer to - they keyword 'super', > the super type, or the super object? "the new super" refers to the updated super type this PEP proposes. Instances of the new super type will act as their own descriptors, which is how they are bound to specific instances of the classes they are associated with. > > Much of
Re: [Python-Dev] New Super PEP
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 calling super with any > arguments other than the exact same arguments you have received is > nearly always wrong, requiring that the arglist be specified is an > attractive nuisance. Nearly always wrong? You must be kidding. There are tons of reasons to call your super method with modified arguments. E.g. clipping, transforming, ... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >> As I said - I'm not convinced that is indeed correct. Before accepting > >> a replacement test I would like confirmation that this test will fail > >> on 2.5.0. You might not get ERROR_SHARING_VIOLATION in all cases of > >> open files with 2.5.0. > > > > But i am running 2.5.0 during my entire writing of this patch. I've > > not upgraded my laptop to 2.5.1 yet, although I verified against > > another installation of 2.5.1 before publishing. > > And you saw your test pass? Then it is not a valid test case for the > bug being test, because the bug is present in 2.5.0, so your test > case should fail there. I think I'm a little confused. Are you saying the original test should fail for me or that the test I changed it to should fail for me? The original test failed, my new one does not. As for documentating the intent of these tests, I don't think tracker items are visible enough. When I'm looking at the unittest itself, am I to always search the entire tracker for any bugs still relevent and pertaining to each test I look at? That seems contorted, and easy to miss. I'll check the tracker, and I'd like to add any information to the test itself. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
>> And you saw your test pass? Then it is not a valid test case for >> the >> bug being test, because the bug is present in 2.5.0, so your >> test case should fail there. >> > > I think I'm a little confused. Are you saying the original test > should fail for me or that the test I changed it to should fail for > me? If "for me" means "in 2.5.0", then yes: both the original test and the one you modified should have failed. > The original test failed, my new one does not. Then this change is incorrect: the test should fail in 2.5.0. > As for documentating the intent of these tests, I don't think > tracker items are visible enough. Hmm. Is it asked too much to go to python.org/sf/1686475 when editing a test case named 'test_1686475'? When researching the intent of some piece of code, you actually have more information available: the set of changes that was committed together (which would include a Misc/NEWS change, and the actual change to posixmodule.c), and the log message. > When I'm looking at the unittest itself, am I to always search the > entire tracker for any bugs still relevent and pertaining to each > test I look at? That seems contorted, and easy to miss. I'll check > the tracker, and I'd like to add any information to the test > itself. Clearly, if you think some relevant information is missing in a comment, submit a patch to add that information. I was unable to add anything, because I did not know it was missing. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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: > > super.foo(1, 2) > > to replace the old: > > super(Foo, self).foo(1, 2) [snip] > The enhancements to the super type will define a new __getattr__ classmethod > of the super type, which must look backwards to the previous frame and locate > the instance object. This can be naively determined by located the local named > by the first argument to the function. Using super outside of a function where > this is a valid lookup for the instance can be considered undocumented in its > behavior. 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. Also, it's my understanding that not all Python implementations have an easy analogue to CPython's frames; have you given any thought to whether and how PyPy, IronPython, Jython, etc, will implement this? Collin Winter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 argument name is, found by this line of python code: instance_name = calling_frame.f_code.co_varnames[0] > Also, it's my understanding that not all Python implementations have > an easy analogue to CPython's frames; have you given any thought to > whether and how PyPy, IronPython, Jython, etc, will implement this? I'll bring this up for input from PyPy and IronPython people, but I don't know any Jython people. Are we yet letting the alternative implementations influence so strongly what we do in CPython? I'm not saying "screw them", just pointing out that there is always a way to implement anything, and if its some trouble for them, well, 2.6 or 3.0 targetting is far down the road for any of them yet. I'll add a reference implementation I have to the second draft of the PEP. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > The > > original test failed, my new one does not. > > Then this change is incorrect: the test should fail in 2.5.0. I think I don't get why the test _must_ fail. If it fails, I assumed something was broken. If it failed because it was testing against a non-existant file, I assumed the test itself was broken. > > As for documentating the > > intent of these tests, I don't think tracker items are visible enough. > > Hmm. Is it asked too much to go to python.org/sf/1686475 when editing > a test case named 'test_1686475'? Maybe this is my flag for "I'm dumb sometimes", but I did wonder what the number was for and completely neglected to consider it being a ticket number! > When researching the intent of some piece of code, you actually have > more information available: the set of changes that was committed > together (which would include a Misc/NEWS change, and the actual > change to posixmodule.c), and the log message. > > > When I'm looking at the unittest itself, am I to always search the > > entire tracker for any bugs still relevent and pertaining to each test > > I look at? That seems contorted, and easy to miss. I'll check the > > tracker, and I'd like to add any information to the test itself. > > Clearly, if you think some relevant information is missing in a comment, > submit a patch to add that information. I was unable to add anything, > because I did not know it was missing. I will do so. Maybe even just a link to the tracker, because of the likelihood of me not being the only person to complete miss what the number in the test name is for. ... I've read the bug report now. I see what I was missing all along. I think maybe you thought I knew of the bug report, and thus we were both confused talking on different frequencies and completely missing each other, Martin. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 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: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Rationale = The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. Specification = Within the specification section, some special terminology will be used to distinguish similar and closely related concepts. "Super type" will refer to the actual builtin type named "super". "Next Class/Type in the MRO" will refer to the class where attribute lookups will be performed by super, for example, in the following, A is the "Next class in the MRO" for the use of super. :: class A(object): def f(self): return 'A' class B(A): def f(self): super(B, self).f() # Here, A would be out "Next class in the # MRO", of course. A "super object" is simply an instance of the super type, which is associated with a class and possibly with an instance of that class. Finally, "new super" refers to the new super type, which will replace the original. Replacing the old usage of super, calls to the next class in the MRO (method resolution order) will be made without an explicit super object creation, by simply accessing an attribute on the super type directly, which will automatically apply the class and instance to perform the proper lookup. The following example demonstrates the use of this. :: class A(object): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit invokation of a super object upon a class and instance. The enhancements to the super type will define a new __getattr__ classmethod of the super type, which must look backwards to the previous frame and locate the instance object. This can be naively determined by located the local named by the first argument to the function. Using super outside of a function where this is a valid lookup for the instance can be considered undocumented in its behavior. This special method will actually be invoked on attribute lookups to the super type itself, as opposed to super objects, as the current implementation works. This may pose open issues, which are detailed below. "Every class will gain a new special attribute, __super__, which refers to an instance of the associated super object for that class" In this capacity, the new super also acts as its own descriptor, create an instance-specific super upon lookup. Much of this was discussed in the thread of the python-dev list, "Fixing super anyone?" [1]_. Open Issues --- __call__ methods 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 the current proposal: :: super.__call__(arg) Which means the backward compatible API, which involves instansiating the super type, will either not be possible, because it will actually do a super lookup on the __call__ attribute, or there will be no way to perform a super lookup on the __call__ attribute. Both seem unacceptable, so any suggestions are welcome. Actually keeping the old super around in 2.x and creating a completely new super type seperately may be the best option. A future import or even a simple import in 2.x of the new super type from some builtin module may offer a way to choose which each module uses, even mixing uses by binding to different names. Such a builtin module might be called 'newsuper'. This module is also the reference implementation, which I will present below. super type's new getattr
Re: [Python-Dev] New Super PEP
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: 2.6 > Post-History: 28-Apr-2007, 29-Apr-2007 > > > 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 suggested is as > follows: > > super.foo(1, 2) > > to replace the old: > > super(Foo, self).foo(1, 2) > > > Rationale > = > > The current usage of super requires an explicit passing of both the class and > instance it must operate from, requiring a breaking of the DRY (Don't Repeat > Yourself) rule. This hinders any change in class name, and is often considered > a wart by many. > > > Specification > = > > Within the specification section, some special terminology will be used to > distinguish similar and closely related concepts. "Super type" will refer to > the actual builtin type named "super". "Next Class/Type in the MRO" will refer > to the class where attribute lookups will be performed by super, for example, > in the following, A is the "Next class in the MRO" for the use of super. > > :: > > class A(object): > def f(self): > return 'A' > > class B(A): > def f(self): > super(B, self).f() # Here, A would be out "Next class in the ># MRO", of course. > > A "super object" is simply an instance of the super type, which is associated > with a class and possibly with an instance of that class. Finally, "new super" > refers to the new super type, which will replace the original. > > Replacing the old usage of super, calls to the next class in the MRO (method > resolution order) will be made without an explicit super object creation, > by simply accessing an attribute on the super type directly, which will > automatically apply the class and instance to perform the proper lookup. The > following example demonstrates the use of this. > > :: > > class A(object): > def f(self): > return 'A' > > class B(A): > def f(self): > return 'B' + super.f() > > class C(A): > def f(self): > return 'C' + super.f() > > class D(B, C): > def f(self): > return 'D' + super.f() > > assert D().f() == 'DBCA' > > The proposal adds a dynamic attribute lookup to the super type, which will > automatically determine the proper class and instance parameters. Each super > attribute lookup identifies these parameters and performs the super lookup on > the instance, as the current super implementation does with the explicit > invokation of a super object upon a class and instance. > > The enhancements to the super type will define a new __getattr__ classmethod > of the super type, which must look backwards to the previous frame and locate > the instance object. This can be naively determined by located the local named > by the first argument to the function. Using super outside of a function where > this is a valid lookup for the instance can be considered undocumented in its > behavior. This special method will actually be invoked on attribute lookups to > the super type itself, as opposed to super objects, as the current > implementation works. This may pose open issues, which are detailed below. > > "Every class will gain a new special attribute, __super__, which refers to an > instance of the associated super object for that class" In this capacity, the > new super also acts as its own descriptor, create an instance-specific super > upon lookup. > > Much of this was discussed in the thread of the python-dev list, "Fixing super > anyone?" [1]_. > > Open Issues > --- > > __call__ methods > > > 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 the current proposal: > > :: > > super.__call__(arg) > > Which means the backward compatible API, which involves instansiating the > super > type, will either not be possible, because it will actually do a super lookup > on the __call__ attribute, or there will be no way to perform a super lookup > on > the __call__ attribute. Both seem unacceptable, so any suggestions are > welcome. > > Actually keeping the old super around in 2.x and creating a completely new > super > type seperately may be the best option. A future import or even a simple > import > in 2.x of the new super t
Re: [Python-Dev] Python 2.5.1
>> > The >> > original test failed, my new one does not. >> >> Then this change is incorrect: the test should fail in 2.5.0. > > I think I don't get why the test _must_ fail. If it fails, I assumed > something was broken. Correct. That is the whole point of this patch: It fixes a bug in 2.5.0, and provides a test case to show that the bug was fixed. The interesting change here is *not* the test case, but the change to posixmodule.c. > If it failed because it was testing against a > non-existant file, I assumed the test itself was broken. Right. It shouldn't fail if the file is absent (it shouldn't pass in that case, either, but regrtest has no support for INCONCLUSIVE test outcomes). > I will do so. Maybe even just a link to the tracker, because of the > likelihood of me not being the only person to complete miss what the > number in the test name is for. Ok. However, this pattern is quite common in the Python test suite (62 test cases, with prefixes such as test_, test_bug_, test_sf_, test_bug, test_patch_), so adding it just to this single test case may be a drop in the ocean for people unfamiliar with that convention. > I've read the bug report now. I see what I was missing all along. I > think maybe you thought I knew of the bug report, and thus we were > both confused talking on different frequencies and completely missing > each other, Martin. Ok! When you come up with a way to test this problem "stand-alone" (i.e. without relying on the pagefile), please submit a patch. I'll let this sit for some time, and if nothing happens, I go for Khalid's patch before 2.5.2 is released (which is still months ahead). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Right. It shouldn't fail if the file is absent (it shouldn't > pass in that case, either, but regrtest has no support for INCONCLUSIVE > test outcomes). Perhaps that could become part of the improvements made through test.test_support.TestCase? > Ok. However, this pattern is quite common in the Python test suite > (62 test cases, with prefixes such as test_, test_bug_, test_sf_, > test_bug, test_patch_), so adding it just to this single test case > may be a drop in the ocean for people unfamiliar with that convention. Very true, but maybe more tests could have the more descriptive names, then. For example, I would have known what it meant if the test name prefix was test_sf_ instead of just test_. Changing the names shouldn't interfere with anything else, so if I rename them in an effort to help the next guy, would that be accepted? > Ok! When you come up with a way to test this problem "stand-alone" > (i.e. without relying on the pagefile), please submit a patch. I'll > let this sit for some time, and if nothing happens, I go for > Khalid's patch before 2.5.2 is released (which is still months > ahead). Now that I have the full picture, I have less motivation about it. Although, I am curious what is different about the situation where pagefile.sys could not be stat'ed in 2.5.0 but other open files could. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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/python-3000/2007-April/006811.html More generally, you're ignoring all the proposals along the line of "let's fix the super type without making it a keyword". Collin Winter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
Calvin Spealman schrieb: > On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Right. It shouldn't fail if the file is absent (it shouldn't >> pass in that case, either, but regrtest has no support for INCONCLUSIVE >> test outcomes). > > Perhaps that could become part of the improvements made through > test.test_support.TestCase? Sure. I think this is PEP material - I would like to declare "expected failure" as well. > Very true, but maybe more tests could have the more descriptive names, > then. For example, I would have known what it meant if the test name > prefix was test_sf_ instead of just test_. Changing the names > shouldn't interfere with anything else, so if I rename them in an > effort to help the next guy, would that be accepted? That would be fine (of course, we move away from SF, so these method names, at some point, will trigger synapses only for old-timers that still remember sourceforge; the bug IDs will remain constant in the next tracker). > Now that I have the full picture, I have less motivation about it. > Although, I am curious what is different about the situation where > pagefile.sys could not be stat'ed in 2.5.0 but other open files could. The error Windows reports is ERROR_SHARING_VIOLATION. I never understood sharing fully, but it may be that if the file is opened in "exclusive sharing", stat'ing it may fail. I personally consider it a bug in Windows that you cannot get file attributes if some other process has opened it. Exclusive access should only restrict access to file contents, but not file attributes. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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/python-3000/2007-April/006805.html > http://mail.python.org/pipermail/python-3000/2007-April/006811.html > > More generally, you're ignoring all the proposals along the line of > "let's fix the super type without making it a keyword". > > Collin Winter > I'll add both of these, but neither had much support in the original thread. Also, I don't see that I'm ignoring anything along the line of "let's fix the super type without making it a keyword", because I am not advocating it become an actual keyword. I was always under the impression that was never meant literally. We have no where else where a keyword looks like an object. At the absolutely most I could almost see how super may become a constant, a'la None, in 3.0, but never a keyword. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 of my head: > > http://mail.python.org/pipermail/python-3000/2007-April/006805.html > > http://mail.python.org/pipermail/python-3000/2007-April/006811.html > > > > More generally, you're ignoring all the proposals along the line of > > "let's fix the super type without making it a keyword". > > > > Collin Winter > > > > I'll add both of these, but neither had much support in the original > thread. Also, I don't see that I'm ignoring anything along the line of > "let's fix the super type without making it a keyword", because I am > not advocating it become an actual keyword. Sorry, I was thrown off by the original title of your PEP. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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: > > super.foo(1, 2) > > to replace the old: > > super(Foo, self).foo(1, 2) Now that I think about it, your proposal seems to address only one of super()'s three forms (http://docs.python.org/lib/built-in-funcs.html#l2h-72): 1. super(type) 2. super(type, instance) 3. super(type, type) If your intention is to remove the first and third forms from the language, please justify their removal in your PEP, including your proposed work-around for their use-cases. Collin Winter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 proper class? Is it related to your proposal to add a new attribute '__super__' to each class? If so, I don't see how... and if not, can you explain why you need '__super__' then? A bientot, Armin. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1
On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Calvin Spealman schrieb: > > On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >> Right. It shouldn't fail if the file is absent (it shouldn't > >> pass in that case, either, but regrtest has no support for INCONCLUSIVE > >> test outcomes). > > > > Perhaps that could become part of the improvements made through > > test.test_support.TestCase? > > Sure. I think this is PEP material - I would like to declare > "expected failure" as well. I would second that. Twisted's trial system does a lot of this, already. I suppose that this conversation would end inside this thread now; it is officially off topic of the thread. But, yes, I would love to see it. test_support could definately act as a testbed for new things before moving to unittest or the unittest replacement. > > Very true, but maybe more tests could have the more descriptive names, > > then. For example, I would have known what it meant if the test name > > prefix was test_sf_ instead of just test_. Changing the names > > shouldn't interfere with anything else, so if I rename them in an > > effort to help the next guy, would that be accepted? > > That would be fine (of course, we move away from SF, so these method > names, at some point, will trigger synapses only for old-timers > that still remember sourceforge; the bug IDs will remain constant in > the next tracker). So test_bug_ then. > > Now that I have the full picture, I have less motivation about it. > > Although, I am curious what is different about the situation where > > pagefile.sys could not be stat'ed in 2.5.0 but other open files could. > > The error Windows reports is ERROR_SHARING_VIOLATION. I never > understood sharing fully, but it may be that if the file is opened > in "exclusive sharing", stat'ing it may fail. > > I personally consider it a bug in Windows that you cannot get file > attributes if some other process has opened it. Exclusive access > should only restrict access to file contents, but not file attributes. Perhaps there are things about the implementation of file operations in "exclusive sharing" mode of files that can not guarantee consistant, reliable, or correct results of a stat call during that time, and the decision was simply "If it can't be correct, it can't be at all." -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 intend the dynamic attribute lookup to find the > proper class? Is it related to your proposal to add a new attribute > '__super__' to each class? If so, I don't see how... and if not, can > you explain why you need '__super__' then? Yes, it is highly dependent on the new __super__ attribute. See the reference implementation for the how. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 case. > > I don't use the name self. I use whatever the first argument name is, > found by this line of python code: > > instance_name = calling_frame.f_code.co_varnames[0] So I can't use super with anything but the method's invocant? That seems arbitrary. > > Also, it's my understanding that not all Python implementations have > > an easy analogue to CPython's frames; have you given any thought to > > whether and how PyPy, IronPython, Jython, etc, will implement this? > > I'll bring this up for input from PyPy and IronPython people, but I > don't know any Jython people. Are we yet letting the alternative > implementations influence so strongly what we do in CPython? I'm not > saying "screw them", just pointing out that there is always a way to > implement anything, and if its some trouble for them, well, 2.6 or 3.0 > targetting is far down the road for any of them yet. It's a smell test: if a given proposal is unduly difficult for anything but CPython to implement, it's probably a bad idea. The language shouldn't go down the Perl 5 road, where python (the C interpreter) becomes the only thing that can implement Python (the language). Collin Winter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 of the new super usage suggested is as > > follows: > > > > super.foo(1, 2) > > > > to replace the old: > > > > super(Foo, self).foo(1, 2) > > Now that I think about it, your proposal seems to address only one of > super()'s three forms > (http://docs.python.org/lib/built-in-funcs.html#l2h-72): > > 1. super(type) > 2. super(type, instance) > 3. super(type, type) > > If your intention is to remove the first and third forms from the > language, please justify their removal in your PEP, including your > proposed work-around for their use-cases. The first is not removed, but actually utilized by the proposal itself. That is what the __super__ attributes are: super objects associated only with a type, but no instance. As for the third form, I wasn't even aware of it, I thought. I didn't consider the cases like how super is used in __new__ methods, but I tested it with the reference implementation, and it works just fine. If there are any cases I'm missing, there is no reason not to support it. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 argument name is, > > found by this line of python code: > > > > instance_name = calling_frame.f_code.co_varnames[0] > > So I can't use super with anything but the method's invocant? That > seems arbitrary. This will be added to the open issues, but it comes back to the problem with allow the exact same super implementation both operate in the super(Class, Object).foo() form and also the super.__call__() form in the new version. Any suggestions are welcome for how to solve this. > > > Also, it's my understanding that not all Python implementations have > > > an easy analogue to CPython's frames; have you given any thought to > > > whether and how PyPy, IronPython, Jython, etc, will implement this? > > > > I'll bring this up for input from PyPy and IronPython people, but I > > don't know any Jython people. Are we yet letting the alternative > > implementations influence so strongly what we do in CPython? I'm not > > saying "screw them", just pointing out that there is always a way to > > implement anything, and if its some trouble for them, well, 2.6 or 3.0 > > targetting is far down the road for any of them yet. > > It's a smell test: if a given proposal is unduly difficult for > anything but CPython to implement, it's probably a bad idea. The > language shouldn't go down the Perl 5 road, where python (the C > interpreter) becomes the only thing that can implement Python (the > language). Understandable. I still haven't contacted anyone about it on in the PyPy or IronPython worlds, and anyone familiar with Jython who can comment would be appreciated. Ditto for PyPy and IronPython, even though I should be able to find some information there myself. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 the current proposal: > > :: > > super.__call__(arg) > >Which means the backward compatible API, which involves instansiating the >super >type, will either not be possible, because it will actually do a super lookup >on the __call__ attribute, or there will be no way to perform a super >lookup on >the __call__ attribute. Both seem unacceptable, so any suggestions are >welcome. Note that if you have a class with a __call__ method, it will still be called, even if you override __getattribute__ to return something else when asked for the __call__ attribute, e.g.: >>> class DoubleCall(object): ... def __call__(self): ... return "called!" ... def __getattribute__(self, attr): ... if attr=='__call__': ... return lambda: "attribute" >>> dc = DoubleCall() >>> dc() 'called!' >>> dc.__call__() 'attribute' ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New Super PEP
Phillip J. Eby wrote: > a __call__ method, it will still be > called, even if you override __getattribute__ to return something else >>> dc = DoubleCall() >>> dc() 'called!' >>> dc.__call__() 'attribute' That is sufficiently fragile that I would be uncomfortable with a feature that couldn't be supplied otherwise. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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. Where is it? A bientot, Armin. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New Super PEP - draft 2
(Adding python-3000 to the Cc, since that is where much of the recent discussion occurred) Calvin's full proposal is archived at: http://mail.python.org/pipermail/python-dev/2007-April/072835.html > 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 suggested is as > follows: > super.foo(1, 2) > to replace the old: > super(Foo, self).foo(1, 2) The alternatives section needs to explain why "super.foo(*args)" is the right level of simplification. Alternatives include (1)No changes Con: fragility in name binding (2)super(__this_class__, self).foo(*args) Con: The "(__this_class__, self)" is boilerplate. Note that the __this_class__ PEP should be referenced, if only as a possible explanation for what is happening under the covers. (3)self.__super__.foo(*args) # or super.foo(*args) Con: Shouldn't need a __double_underscore_name__ in normal functions. Con: __super__ (even if renamed super) is not a simple attribute; it is a property representing a partially applied function (that gets further applied by the "self") (4) super(self, *args)# ? or __super__(self, *args) Actually, I sort of like this one, as it allows the upcall signature to exactly match the method definition signature. Con: super is still not a simple attribute. Con: changing the method name becomes a hassle. (5) super.foo(self, *args)# ? or __super__.foo(self, *args) Con: self isn't really an argument just to super.foo -- it is an argument to super which is used to find/instantiate foo in the first place. (Plus the objections to partially applied function attributes.) (6) super # ? or super() Pro: matches java; doesn't require a repeat of *args Con: doesn't match anything else in python, needs to be a keyword (and would still need object support). In the first example: class A(object): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' You should probably include tests that fail with some of the more obvious (but wrong) solutions, such as class A(object): def f(self): return 'A' class Bempty(A): # Make sure it doesn't call the A or B method twice pass class B(Bempty): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' class E(C, B):# Show that B can point to C as next or vice versa def f(self): return 'E' + super.f() assert E().f() == 'ECBA' class F(D):# show that the instance may not be a direct instance pass assert D().f() == 'DBCA' > The enhancements to the super type will define a new __getattr__ classmethod > of the super type, Did you really mean, it gets the class of builtin.super, but no info on which class is using super? If not, it isn't a classmethod of the super type. It may be a classmethod of the currently-being-defined-type (__this_class__). > which must look backwards to the previous frame and locate > the instance object. frame manipulation is fragile. Even if it didn't cause problems for other implementations, it causes problems for nested functions and callbacks. def f(self, button, *args): def callback(*args): super(__this_class__, self).f(*args) button.callback=callback When this gets called, the appropriate self won't be in the frame, except as a lexically scoped variable (which might have a different name). Also, note that this fails on most of Thomas Wouters' advanced usages. While you say that super shouldn't be called outside a method, you can't really keep the super object itself from getting returned. > "Every class will gain a new special attribute, __super__, which refers to an > instance of the associated super object for that class" In this capacity, the > new super also acts as its own descriptor, create an instance-specific super > upon lookup. If you didn't say instance-specific, this would be equivalent to a class decorator, translating class A(object): ... into class A(object): ... A.__super__=super(A) As is, it gets a bit trickier, since you need to I think the translation is closer to class A(object):... @property def __super__(self): return __this_class__.__supermaker() A.__supermaker=super(A) I
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
On 4/29/07, Tim Delaney <[EMAIL PROTECTED]> wrote: > I've been intending to write up a PEP for fixing super, but I haven't had > time to get to it. Calvin Spealman has the most recent draft. I hope he will incorporate this into his draft. > 1. 'super' becomes a keyword, that returns a super object for the instance > method currently being executed. So it is a "keyword" in the sense that None is a keyword; not in the stronger sense that "if" is a keyword? > 4. super objects are callable, and calling them will execute the super > method with the same name as the instance method currently being executed. > Lookup of this method occurs when the instance method is entered. > > class A(object): > def f(self): > pass > > class B(A): > def f(self): > super() # Calls A.f(self) > If you want name lookup to occur at the time of the call, you can explicitly > specify the method name (just like with any other super attribute): > > class A(object): > def f(self): > pass > > class B(A): > def f(self): > super.f() # Calls A.f(self) As long as you can be explicit, should the shortcut be a full shortcut? That is, def f(self, a, b=c, *args, **kwargs): super()# passes the exact arglist that f got vs def __init__(self, myvar, passed_var): super.__init__(self, passed_var)# flags that you are changing the args -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 4/29/07, Tim Delaney <[EMAIL PROTECTED]> wrote: > > I've been intending to write up a PEP for fixing super, but I haven't had > > time to get to it. > > Calvin Spealman has the most recent draft. I hope he will incorporate > this into his draft. I will incorporate this into my draft, particularly taking care of the issue with inner functions. > > 1. 'super' becomes a keyword, that returns a super object for the instance > > method currently being executed. > > So it is a "keyword" in the sense that None is a keyword; not in the > stronger sense that "if" is a keyword? I would like to say super becomes a constant in the way that None is a constant, and if there is some reason the implementation today or tomorrow can benefit from actually making it a keyword, that won't break anything if its already constant. One problem with an actual keyword, is there is no other part of Python where an actual keyword evaluates to something. > > 4. super objects are callable, and calling them will execute the super > > method with the same name as the instance method currently being executed. > > Lookup of this method occurs when the instance method is entered. > > > > class A(object): > > def f(self): > > pass > > > > class B(A): > > def f(self): > > super() # Calls A.f(self) This might run into the same issue I had to cover, where you get an ambiguous situation trying to distinguish between calling super and calling the __call__ method of the next class in the MRO. We should absolutely avoid a situation in python now where X() differs from X.__call__() > > If you want name lookup to occur at the time of the call, you can explicitly > > specify the method name (just like with any other super attribute): > > > > class A(object): > > def f(self): > > pass > > > > class B(A): > > def f(self): > > super.f() # Calls A.f(self) > > As long as you can be explicit, should the shortcut be a full > shortcut? That is, > > def f(self, a, b=c, *args, **kwargs): > super()# passes the exact arglist that f got I sure wish my previous complaints didn't hinder this, because I really love the idea of being able to this, which would really encourage more compatible method signatures, so you can use the shortcut! I'm desperate for a solution that satisfies all the sides of the equation. > vs > > def __init__(self, myvar, passed_var): > super.__init__(self, passed_var)# flags that you are > changing the args > > -jJ > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > So it is a "keyword" in the sense that None is a keyword; not in the > stronger sense that "if" is a keyword? Um, how do you see those two differ? Is 'if' a keyword in the same sense as 'or', or in a different sense? I realize that in Python 2.5, None is not a full-fledged keyword but cannot be used as an assignment target. But that's only transitional. In 3.0 I imagine it becoming a keyword in the grammar (whose only appearance would be as one of the alternatives for 'atom'). And we're talking 3.0 here. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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) The PEP is all about cooperative super calls, so it doesn't apply to this. I'd still rather see syntactic support for ordinary inherited calls before cooperative ones, as cooperative ones are used much more rarely, in my experience. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
On 4/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > > So it is a "keyword" in the sense that None is a keyword; not in the > > stronger sense that "if" is a keyword? > > Um, how do you see those two differ? Is 'if' a keyword in the same > sense as 'or', or in a different sense? > > I realize that in Python 2.5, None is not a full-fledged keyword but > cannot be used as an assignment target. But that's only transitional. > In 3.0 I imagine it becoming a keyword in the grammar (whose only > appearance would be as one of the alternatives for 'atom'). And we're > talking 3.0 here. I think any concerns about it not being fit as a keyword would fall under two catagories or varying validity: 1) Too many keywords is a valid concern, because it complicates the language. 2) It just doesn't "feel" like a keyword. Less valid, unless it _really_ doesn't feel like a keyword. It doesn't feel like a keyword. But it doesn't feel too much not like a keyword. Anyway, I tried to address the concerns laid out, and I'm more than happy to alter the PEP to actually say "Lets implement this as a keyword", and I actually meant to keep more agnostic on that point in the proposal itself. I was more interested in covering the interface, at least to begin, than the actual implementation. Although, being able to have a solid, working reference implementation based on the frame lookups and such is nice, so we can see how it will actually work in real code, and even use it to backport code using the new super to just about any recent Python version. I also checked and PyPy does implement a sys._getframe() and a IronPython currently doesn't, but seems to plan on it (there is a placeholder, at present). I am not sure if notes on this belongs in the PEP or not. Draft Three follows for all. I think I'm turning off e-mail for the rest of this evening, so I'll catch up tomorrow. --- 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 (1), 29-Apr-2007 (2) 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 suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Rationale = The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. Specification = Within the specification section, some special terminology will be used to distinguish similar and closely related concepts. "Super type" will refer to the actual builtin type named "super". "Next Class/Type in the MRO" will refer to the class where attribute lookups will be performed by super, for example, in the following, A is the "Next class in the MRO" for the use of super. :: class A(object): def f(self): return 'A' class B(A): def f(self): super(B, self).f() # Here, A would be out "Next class in the # MRO", of course. A "super object" is simply an instance of the super type, which is associated with a class and possibly with an instance of that class. Finally, "new super" refers to the new super type, which will replace the original. Replacing the old usage of super, calls to the next class in the MRO (method resolution order) will be made without an explicit super object creation, by simply accessing an attribute on the super type directly, which will automatically apply the class and instance to perform the proper lookup. The following example demonstrates the use of this. :: class A(object): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit invokation of a super object upon a class and instance. The enhancements to the super type will define a new __getattr__ classmethod of the super type, which must look backwards to the previous frame
Re: [Python-Dev] New Super PEP
[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 different, because you don't know which method you're calling, so the signature of all methods along the super chain has to be standardised. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 the same. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
* Guido van Rossum <[EMAIL PROTECTED]> [2007-04-29 16:30:18 -0700]: > On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > > So it is a "keyword" in the sense that None is a keyword; not in the > > stronger sense that "if" is a keyword? > > Um, how do you see those two differ? Is 'if' a keyword in the same > sense as 'or', or in a different sense? In my mind, 'if' and 'or' are "syntax", whereas things like 'None' or 'True' are "values"; even if None becomes an actual keyword, rather than a builtin. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
On 4/29/07, Tristan Seligmann <[EMAIL PROTECTED]> wrote: > * Guido van Rossum <[EMAIL PROTECTED]> [2007-04-29 16:30:18 -0700]: > > > On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > > > So it is a "keyword" in the sense that None is a keyword; not in the > > > stronger sense that "if" is a keyword? > > > > Um, how do you see those two differ? Is 'if' a keyword in the same > > sense as 'or', or in a different sense? > > In my mind, 'if' and 'or' are "syntax", whereas things like 'None' or > 'True' are "values"; even if None becomes an actual keyword, rather than > a builtin. I'm sorry, but that is such an incredibly subjective difference that I can't do anything with it. String literals and numeric literals are syntax too, even though they are values. A keyword, or reserved word, is simply something that looks like an identifier but is converted into a different token (by the lexer or by something sitting between the lexer and the parse) before the parser sees it. Also note that null is a keyword in Java. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.5.1
All test_os tests pass for me now on WinXP under MinGW. Please see http://.python.org/sf/1709112 for details and patches. Regards, Khalid __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
Jim Jewett wrote: > On 4/29/07, Tim Delaney <[EMAIL PROTECTED]> wrote: >> I've been intending to write up a PEP for fixing super, but I >> haven't had time to get to it. > > Calvin Spealman has the most recent draft. I hope he will incorporate > this into his draft. Sorry about this - wasn't receiving python-dev at home, so didn't realise Calvin had released the PEP. I think the current PEP draft is way too complicated - I don't think there's any need for descriptors, etc. I think we can make things work in the following way: 1. When a method is defined, the class is bound to it via an attribute (which in my version is called func_class). 2. Every non-static method has an implicit cell variable called 'super'. This would preferably not be able to be rebound. I also think it would be beneficial if the first parameter to the method couldn't be rebound (point 7 in my original email in this thread). 3. When a method is entered, the 'super' cell variable is populated by a call equivalent to: super = __builtin__.super(func_class, first_parameter) This would result in 'super' being a constant object, within the scope of the currently-executing method. 'keyword' was perhaps too strong - I was thinking this would only need to be done if 'super' were actually used, which would be easier to determine if 'super' actually were a keyword. This could still be done by not emitting the above call unless the 'super' cell variable were ever actually used. I've done bytecode-hacky stuff to do the equivalent of the above (as much as I've been able to), but a real implementation would just emit the correct bytecode (or java bytecode, or whatever) in the compiled code object. The issue of super() vs. super.__call__() ambiguity - I'll need to look at that when I get home. I'm a strong -1 against super() automatically passing the parameters that were passed to the currently-executing method. Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 30XZ: Simplified Parsing
PEP: 30xz
Title: Simplified Parsing
Version: $Revision$
Last-Modified: $Date$
Author: Jim J. Jewett <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 29-Apr-2007
Post-History: 29-Apr-2007
Abstract
Python initially inherited its parsing from C. While this has
been generally useful, there are some remnants which have been
less useful for python, and should be eliminated.
+ Implicit String concatenation
+ Line continuation with "\"
+ 034 as an octal number (== decimal 28). Note that this is
listed only for completeness; the decision to raise an
Exception for leading zeros has already been made in the
context of PEP XXX, about adding a binary literal.
Rationale for Removing Implicit String Concatenation
Implicit String concatentation can lead to confusing, or even
silent, errors. [1]
def f(arg1, arg2=None): pass
f("abc" "def") # forgot the comma, no warning ...
# silently becomes f("abcdef", None)
or, using the scons build framework,
sourceFiles = [
'foo.c',
'bar.c',
#...many lines omitted...
'q1000x.c']
It's a common mistake to leave off a comma, and then scons complains
that it can't find 'foo.cbar.c'. This is pretty bewildering behavior
even if you *are* a Python programmer, and not everyone here is.
Note that in C, the implicit concatenation is more justified; there
is no other way to join strings without (at least) a function call.
In Python, strings are objects which support the __add__ operator;
it is possible to write:
"abc" + "def"
Because these are literals, this addition can still be optimized
away by the compiler.
Guido indicated [2] that this change should be handled by PEP, because
there were a few edge cases with other string operators, such as the %.
The resolution is to treat them the same as today.
("abc %s def" + "ghi" % var) # fails like today.
# raises TypeError because of
# precedence. (% before +)
("abc" + "def %s ghi" % var) # works like today; precedence makes
# the optimization more difficult to
# recognize, but does not change the
# semantics.
("abc %s def" + "ghi") % var # works like today, because of
# precedence: () before %
# CPython compiler can already
# add the literals at compile-time.
Rationale for Removing Explicit Line Continuation
A terminal "\" indicates that the logical line is continued on the
following physical line (after whitespace).
Note that a non-terminal "\" does not have this meaning, even if the
only additional characters are invisible whitespace. (Python depends
heavily on *visible* whitespace at the beginning of a line; it does
not otherwise depend on *invisible* terminal whitespace.) Adding
whitespace after a "\" will typically cause a syntax error rather
than a silent bug, but it still isn't desirable.
The reason to keep "\" is that occasionally code looks better with
a "\" than with a () pair.
assert True, (
"This Paren is goofy")
But realistically, that paren is no worse than a "\". The only
advantage of "\" is that it is slightly more familiar to users of
C-based languages. These same languages all also support line
continuation with (), so reading code will not be a problem, and
there will be one less rule to learn for people entirely new to
programming.
Rationale for Removing Implicit Octal Literals
This decision should be covered by PEP ???, on numeric literals.
It is mentioned here only for completeness.
C treats integers beginning with "0" as octal, rather than decimal.
Historically, Python has inherited this usage. This has caused
quite a few annoying bugs for people who forgot the rule, and
tried to line up their constants.
a = 123
b = 024 # really only 20, because octal
c = 245
In Python 3.0, the second line will instead raise a SyntaxError,
because of the ambiguity. Instead, the line should be written
as in one of the following ways:
b = 24# PEP 8
b = 24 # columns line up, for quick scanning
b = 0t24 # really did want an Octal!
References
[1] Implicit String Concatenation, Jewett, Orendorff
http://mail.python.org/pipermail/python-ideas/2007-April/000397.html
[2] PEP 12, Sample reStructuredText PEP Template, Goodger, Warsaw
http://www.python.org/peps/pep-0012
[3] http://www.opencontent.org/openpub/
Copyright
This document has been pl
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
* Guido van Rossum <[EMAIL PROTECTED]> [2007-04-29 18:19:20 -0700]: > > In my mind, 'if' and 'or' are "syntax", whereas things like 'None' or > > 'True' are "values"; even if None becomes an actual keyword, rather than > > a builtin. > > I'm sorry, but that is such an incredibly subjective difference that I > can't do anything with it. String literals and numeric literals are > syntax too, even though they are values. A keyword, or reserved word, > is simply something that looks like an identifier but is converted > into a different token (by the lexer or by something sitting between > the lexer and the parse) before the parser sees it. Let me try a less subjective description. Things like None, 2.3, 'foo', True are values or "expressions"; I'm not certain exactly what the term for these is in Python's grammar, but I basically mean something that can be on the RHS of an assignment.. However, something like 'for' or 'if' is part of some other grammatical construct, generally a statement or operator of some kind, so I tend to think of those differently. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
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 doesn't mean the *values* of the parameters need > to be the same. This is quite true, and is indeed one case where it can be right to pass different arguments. Just in case there was confusion, I did not intend to imply that it should be impossible to pass different arguments, only that passing the same ones should be foolproof and not require repeating yourself. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
On 4/29/07, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote: > I think the current PEP draft is way too complicated - I don't think > there's any need for descriptors, etc. I think we can make things work > in the following way: > > 1. When a method is defined, the class is bound to it via an attribute > (which in my version is called func_class). In Py3k all the func_XXX attrs are renamed __XXX__, so this would be __class__; but that's a name reserved for something else, so it would need to be something else. E.g. __containing_class__. Also, this would have to be done when the class is defined; when the method is being defined the class doesn't exist yet. > 2. Every non-static method has an implicit cell variable called 'super'. I think you're using 'cell' in a different sense than it is normally used in Python's implementation. What you are looking for is called a local variable (I deduce this from your initialization of the "cell" with something computed from the first argument). A 'cell' (as I introduced in my original back-of-the-envelop proposal; apparently you totally missed this reference) is a special kind of object containing a reference to another object and used to implement nonlocal variable references (the Python 2 read-only nonlocals as well as the Python 3 writable nonlocals). The cell is initialized in the surrounding scope and attached to the function object (as func_closure in 2.x, or __closure__ in 3.0). When the function is called, a reference to the cell is stored in the call frame. If anything in your proposal resembles a cell (in the sense that I and other Pythonistas mean it), it's the func_class attribute. In fact, in this sense our proposals are equivalent modulo slight implementation details; I proposed using a cell because there's an existing mechanism to get these mapped into a local variable, and because cells are cheaper than function attributes -- the first function attribute requires creating a dict, which is one of the larger built-in objects. > This would preferably not be able to be rebound. I also think it would > be beneficial if the first parameter to the method couldn't be rebound > (point 7 in my original email in this thread). The latter part sounds irrelevant to me. > 3. When a method is entered, the 'super' cell variable is populated by a > call equivalent to: > > super = __builtin__.super(func_class, first_parameter) > > This would result in 'super' being a constant object, within the scope > of the currently-executing method. 'keyword' was perhaps too strong - I > was thinking this would only need to be done if 'super' were actually > used, which would be easier to determine if 'super' actually were a > keyword. This could still be done by not emitting the above call unless > the 'super' cell variable were ever actually used. This sounds about right to me, with the strong preference that super *should* be made a keyword, and the built-in of the same name renamed to __super__, as it has a somewhat similar relationship to the super keyword as the built-in __import__ has to the import keyword. > I've done bytecode-hacky stuff to do the equivalent of the above (as > much as I've been able to), but a real implementation would just emit > the correct bytecode (or java bytecode, or whatever) in the compiled > code object. Shouldn't be too hard for someone who's hacked Python/compile.c before. > The issue of super() vs. super.__call__() ambiguity - I'll need to look > at that when I get home. Sounds irrelevant -- if super is equivalent to __builtin__.__super__(, ) then super never gets called; the only thing ever done to it (in the normal course of things) is to request an attribute of it. > I'm a strong -1 against super() automatically passing the parameters > that were passed to the currently-executing method. Same here. There seems to be the remaining controversy that there are three forms of super calls currently in use: super(ThisClass, self).method(...) # in a regular method super(ThisClass, cls).method(...) # in a class method super(ThisClass).method(...) # ??? The first two are handled by your "use the first argument" approach. The third exists so that you can create an "unbound" super instance which is useful for the oft-misunderstood autosuper example in my "descrintro" essay: http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_examples . But since the latter is the hack that we're trying to replace with a proper implementation here, I suspect we can get away with only supporting the first two forms (and the third form is still supported using __builtin__.__super__). IOW I think you're on to something. Keep up the good word. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-ar
Re: [Python-Dev] test_pty fails on Sparc Solaris 10 for trunk
I was mucking about in test_pty.py not too long ago. I'll take a look. Jerry On 4/24/07, Grig Gheorghiu <[EMAIL PROTECTED]> wrote: This is happening both in the Python buildbot farm, and in the community buildbot farm. See: http://www.python.org/dev/buildbot/trunk/sparc%20solaris10%20gcc%20trunk/builds/1960/step-test/0 http://www.python.org/dev/buildbot/community/trunk/sparc%20Solaris%2010%20trunk/builds/484/step-test/0 Grig -- http://agiletesting.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jseutter%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_pty fails on Sparc Solaris 10 for trunk
No need to worry about it, I fixed the failing test. Although it would be good to review the comments and make them more accurate. Take a look at the last change to test_pty.py. n -- On 4/29/07, Jerry Seutter <[EMAIL PROTECTED]> wrote: > I was mucking about in test_pty.py not too long ago. I'll take a look. > > Jerry > > > On 4/24/07, Grig Gheorghiu < [EMAIL PROTECTED]> wrote: > > > > This is happening both in the Python buildbot farm, and in the > > community buildbot farm. > > > > See: > > > > > http://www.python.org/dev/buildbot/trunk/sparc%20solaris10%20gcc%20trunk/builds/1960/step-test/0 > > > http://www.python.org/dev/buildbot/community/trunk/sparc%20Solaris%2010%20trunk/builds/484/step-test/0 > > > > Grig > > > > -- > > http://agiletesting.blogspot.com > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jseutter%40gmail.com > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] deprecating macpath and macurl2path
PEP 11 notes that Mac OS 9 support was unsupported in 2.4. There are still quite a few places that we check for sys.platform == 'mac'. There are also (at least) 2 modules (macpath and macurl2path) that look specific to Mac OS. (OS X has sys.platform == 'darwin'.) Shall I add a deprecation warning on import to these modules or remove them? I plan to remove other mac specific code (checking sys.platform) in the stdlib unless someone beat me to it. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Pre-pre PEP for 'super' keyword
Guido van Rossum wrote: >> 1. When a method is defined, the class is bound to it via an attribute >> (which in my version is called func_class). > In Py3k all the func_XXX attrs are renamed __XXX__, so this would be > __class__; but that's a name reserved for something else, so it would > need to be something else. E.g. __containing_class__. Yep - I've just used a placeholder name. > Also, this would have to be done when the class is defined; when the > method is being defined the class doesn't exist yet. Good point. Change that to "at the first opportunity" ;) >> 2. Every non-static method has an implicit cell variable called >> 'super'. > > I think you're using 'cell' in a different sense than it is normally > used in Python's implementation. What you are looking for is called a > local variable (I deduce this from your initialization of the "cell" > with something computed from the first argument). Actually, I think I'm using the terminology correctly - I'm talking about an entry in co_cellvars. Given the following class: class A(object): def f(self): super = super_factory() def inner(): return 'A' + super.f() print inner() the use of 'super' in both A.f and A.f.inner will produce an entry in A.f.func_code.co_cellvars and A.f.inner.func_code.co_freevars. What I'm proposing is that the `super = super_factory()` line be implicit in this case, resulting in the following code behaving identically: class A(object): def f(self): def inner(): return 'A' + super.f() print inner() >> The issue of super() vs. super.__call__() ambiguity - I'll need to >> look at that when I get home. > > Sounds irrelevant -- if super is equivalent to > __builtin__.__super__(, ) then super never gets > called; the only thing ever done to it (in the normal course of > things) is to request an attribute of it. Sorry - this is related to my proposal that the following two bits of code behave the same: class A(object): def f(self, *p, **kw): super.f(*p, **kw) class A(object): def f(self, *p, **kw): super(*p, **kw) But as has been pointed out, this creates an ambiguity with: class A(object): def f(self, *p, **kw): super.__call__(*p, **kw) so I want to see if I can resolve it. > super(ThisClass).method(...) # ??? > > The third exists so that you can create an "unbound" super instance > which is useful for the oft-misunderstood autosuper example in my > "descrintro" essay: > http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_exam ples > . > > But since the latter is the hack that we're trying to replace with a > proper implementation here, I suspect we can get away with only > supporting the first two forms (and the third form is still supported > using __builtin__.__super__). Yep - that's my thought as well. I think it would be very rare to need super(ThisClass), although it makes some sense that that would be what super means in a static method ... Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
