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