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
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 warnin
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
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%2
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 attr
On Apr 29, 2007, at 9:07 PM, Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> Nearly always wrong? You must be kidding. There are tons of
>> reasons to
>> call your super method with modified arguments. E.g. clipping,
>> transforming, ...
>
> That's a good point. Just because the *signature* is t
* Guido van Rossum <[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 differ
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 t
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 rec
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
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 keywo
* 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
Guido van Rossum wrote:
> Nearly always wrong? You must be kidding. There are tons of reasons to
> call your super method with modified arguments. E.g. clipping,
> transforming, ...
That's a good point. Just because the *signature* is the
same doesn't mean the *values* of the parameters need
to b
[EMAIL PROTECTED] wrote:
> Since the language doesn't require that a subclassed method take the same
> parameters as the base class method, you can't assume that it does.
The argument is that in the special case of a cooperative
super call, it doesn't make sense for the parameter list
to be differ
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
> se
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,
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
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
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 objec
(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 implicit
Hi Calvin,
On Sun, Apr 29, 2007 at 02:53:58PM -0400, Calvin Spealman wrote:
> Yes, it is highly dependent on the new __super__ attribute. See the
> reference implementation for the how.
Ah, there is a reference implementation. There is no link to it in the
PEP you posted, hence my confusion. Wh
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 could
At 01:19 PM 4/29/2007 -0400, Calvin Spealman wrote:
>Backward compatability of the super type API raises some issues. Names, the
>lookup of the __call__ of the super type itself, which means a conflict with
>doing an actual super lookup of the __call__ attribute. Namely, the following
>is ambiguous
On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > What if the instance isn't called "self"? PEP 3099 states that "self
> > > will not become implicit"; it's talking about metho
On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > The PEP defines the proposal to enhance the super builtin to work implicitly
> > upon the class within which it is used and upon the instance the current
> > function was called on. The
On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > What if the instance isn't called "self"? PEP 3099 states that "self
> > will not become implicit"; it's talking about method signatures, but I
> > think that dictum applies equally wel
On 4/29/07, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Calvin,
>
> On Sat, Apr 28, 2007 at 10:43:04PM -0400, Calvin Spealman wrote:
> > The proposal adds a dynamic attribute lookup to the super type, which will
> > automatically determine the proper class and instance parameters.
>
> Can you descri
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 o
Hi Calvin,
On Sat, Apr 28, 2007 at 10:43:04PM -0400, Calvin Spealman wrote:
> The proposal adds a dynamic attribute lookup to the super type, which will
> automatically determine the proper class and instance parameters.
Can you describe how you intend the dynamic attribute lookup to find the
pro
On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> The PEP defines the proposal to enhance the super builtin to work implicitly
> upon the class within which it is used and upon the instance the current
> function was called on. The premise of the new super usage suggested is as
> follows:
>
On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > [snip]
> > > I still wasn't really aware of any alternative suggestions that need
> > > to be included in this.
> >
> > Here a
On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> [snip]
> > I still wasn't really aware of any alternative suggestions that need
> > to be included in this.
>
> Here are two off the top of my head:
> http://mail.python.org/pipermail/pyt
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 m
On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
[snip]
> I still wasn't really aware of any alternative suggestions that need
> to be included in this.
Here are two off the top of my head:
http://mail.python.org/pipermail/python-3000/2007-April/006805.html
http://mail.python.org/pipermail/p
On 4/29/07, "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.Test
>> > 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, an
On 4/29/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> Draft Attempt Number Duo:
>
> PEP: XXX
> Title: New Super
> Version: $Revision$
> Last-Modified: $Date$
> Author: Calvin Spealman <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 28-Apr-2007
>
Draft Attempt Number Duo:
PEP: XXX
Title: New Super
Version: $Revision$
Last-Modified: $Date$
Author: Calvin Spealman <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Apr-2007
Python-Version: 2.6
Post-History: 28-Apr-2007, 29-Apr-2007
Abstract
On 4/29/07, "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 t
On 4/29/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> What if the instance isn't called "self"? PEP 3099 states that "self
> will not become implicit"; it's talking about method signatures, but I
> think that dictum applies equally well in this case.
I don't use the name self. I use whatever the
On 4/28/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
[snip]
> The PEP defines the proposal to enhance the super builtin to work implicitly
> upon the class within which it is used and upon the instance the current
> function was called on. The premise of the new super usage suggested is as
> foll
>> 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 s
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 wi
On 4/28/07, James Y Knight <[EMAIL PROTECTED]> wrote:
> This is only a halfway fix to DRY, and it really only fixes the less
> important half. The important problem with super is that it
> encourages people to write incorrect code by requiring that you
> explicitly specify an argument list. Since c
Yes, I bad wordly things did. Fix will I.
On 4/29/07, Talin <[EMAIL PROTECTED]> wrote:
> Calvin Spealman wrote:
> > Comments welcome, of course. Bare with my first attempt at crafting a PEP.
>
> See below for comments; In general, I'm having problems understanding
> some of the terms used. I don't
> Since calling super with any
> arguments other than the exact same arguments you have received is
> nearly always wrong,
>
>
> Erm. Excuse me, but are you saying this code is wrong?
>
> class Rectangle:
> def __init__(self, width, height):
> self.width = width
>
>> 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
> 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
__
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
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, whic
James> This is only a halfway fix to DRY, and it really only fixes the
James> less important half. The important problem with super is that it
James> encourages people to write incorrect code by requiring that you
James> explicitly specify an argument list. Since calling super with
2007/4/29, Gustavo Carneiro <[EMAIL PROTECTED]>:
> On 29/04/07, James Y Knight <[EMAIL PROTECTED]> wrote:
> > Since calling super with any
> > arguments other than the exact same arguments you have received is
> > nearly always wrong,
>
> Erm. Excuse me, but are you saying this code is wrong?
>
On 29/04/07, James Y Knight <[EMAIL PROTECTED]> wrote:
On Apr 28, 2007, at 10:43 PM, Calvin Spealman wrote:
> Abstract
>
>
> The PEP defines the proposal to enhance the super builtin to work
> implicitly
> upon the class within which it is used and upon the instance the
> current
> fun
> 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
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
> ex
> 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 ex
> 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 tha
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
58 matches
Mail list logo
