Re: [Python-Dev] Python 2.5.1

[Calvin Spealman]

On 4/27/07, Khalid A. Bakr <[EMAIL PROTECTED]> wrote:
> Okay. It seems I mixed up WindowsError with the
> exception e in my post; at least it is now known that
> e is not a number. The patch is short and is as
> follows:
>
> Index: Lib/test/test_os.py
> ===
> --- Lib/test/test_os.py (revision 55014)
> +++ Lib/test/test_os.py (working copy)
> @@ -245,7 +245,8 @@
>  try:
>  os.stat(r"c:\pagefile.sys")
>  except WindowsError, e:
> -if e == 2: # file does not exist;
> cannot run test
> +# file may not exist, or access is
> denied; cannot run test
> +if e.winerror == 2 or e.winerror ==
> 5:
>  return
>  self.fail("Could not stat
> pagefile.sys")

I have a patch myself that creates an open file and uses that as the
test. My reasoning is that pagefile.sys was chosen as a file that
should always exist and be open, so its safe to test against, so we
should just be testing against a fixture, instead. It is here, and if
someone would reference a SF bug report, I'll attach to it, as well.

I should also point out that I got the time errors as well, but with
different incorrect results. However, I can't seem to reproduce it
this morning, but I can say that I did have the test failing for me on
VC yesterday.

Index: test_os.py
===
--- test_os.py  (revision 54982)
+++ test_os.py  (working copy)
@@ -6,6 +6,7 @@
 import unittest
 import warnings
 import sys
+import tempfile
 from test import test_support

 warnings.filterwarnings("ignore", "tempnam", RuntimeWarning, __name__)
@@ -241,13 +242,18 @@
 self.assertEquals(os.stat(self.fname).st_mtime, t1)

 def test_1686475(self):
+fn = tempfile.mktemp()
+openfile = open(fn, 'w')
 # Verify that an open file can be stat'ed
 try:
-os.stat(r"c:\pagefile.sys")
+os.stat(fn)
 except WindowsError, e:
 if e == 2: # file does not exist; cannot run test
 return
 self.fail("Could not stat pagefile.sys")
+finally:
+openfile.close()
+os.remove(fn)

 from test import mapping_tests

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
Python-Dev mailing list
Python-Dev@python.org
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

[Raghuram Devarakonda]

On 4/28/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> Index: test_os.py
> ===
> --- test_os.py  (revision 54982)
> +++ test_os.py  (working copy)
> @@ -6,6 +6,7 @@
>  import unittest
>  import warnings
>  import sys
> +import tempfile
>  from test import test_support
>
>  warnings.filterwarnings("ignore", "tempnam", RuntimeWarning, __name__)
> @@ -241,13 +242,18 @@
>  self.assertEquals(os.stat(self.fname).st_mtime, t1)
>
>  def test_1686475(self):
> +fn = tempfile.mktemp()
> +openfile = open(fn, 'w')
>  # Verify that an open file can be stat'ed
>  try:
> -os.stat(r"c:\pagefile.sys")
> +os.stat(fn)
>  except WindowsError, e:
>  if e == 2: # file does not exist; cannot run test
>  return
>  self.fail("Could not stat pagefile.sys")
> +finally:
> +openfile.close()
> +os.remove(fn)
>
>  from test import mapping_tests

mktemp() is deprecated. You may want to use mkstemp(). There will be
no need for explicit open as well as mkstemp() also returns open
descriptor.

Thanks,
Raghu.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] April 1-15, 2007 Summaries Final Draft

[Calvin Spealman]

If no one has any further comments over the weekend and Monday, I'll
post it as the final summary that evening/night.

=
Announcements
=

=
Summaries
=

---
About SSL tests
---

An open bug about missing SSL tests (#451607) was brought up to close or keep
open. Jean-Paul Calderone mentioned an improved testing method by spawning a
'openssl s_server' for testing purposes. This sparked some talk about the
terminating of subprocesses in a cross-platform manner (See `Cross-Platform
Subprocess Termination`).

Contributing thread:

- `About SSL tests
`__

-
Cross-Platform Subprocess Termination
-

Because os.kill only works on *nix and OS X platforms, leaving Windows
platforms uncovered. Although subprocess.TerminateProcess exists for Windows
platforms, it requires the use of handles and additional overhead for use.
Support was overall given for adding a UNIX-only signal() method and a cross-
platform terminate() method to Popen instances. Nothing was said of actually
incorporating these changes into the subprocess module, although code was
given.

Contributing thread:

- (This was mixed in with the `About SSL tests` thread.)


Extended buffer protocol


Updates to the buffer protocol are discussed, along with the proposal pre-PEP
documenting the updates for Python 3000, but brought to Python-Dev, due so the
plans of backporting to 2.6 afterwards.

(Note: I couldn't summarize this well enough to cover much of it do any real
degree, but it is currently a Py3k issue, so maybe that is OK. If no one wants
to add to the summary, it will stay short.)

Contributing threads:

- `Extended buffer PEP
`__
- `PEP 3118: Extended buffer protocol (new version)
`__
- `Extended Buffer Protocol - simple use examples
`__

-
function for counting items in a sequence
-

A patch was submitted by Steven Bethard (http://bugs.python.org/1696199),
implemented a discussed collections.counts() function to provide a mapping
between items in an iterable and the number of times they appear. There were
suggested names, but none overthrew the original 'counts()' and a question of
items not appearing being counted as 0 or raising a KeyError, with 0 winning
due to a just-makes-sense factor.

Contributing thread:

- `function for counting items in a sequence
`__


context manager - generator interaction?


A problem was brought up with iterator context managers and iteration inside
the with-block raising its StopIteration, but being caught by the context
manager mechanics. It was also responded that the problem would not exist
without the use of overly broad try blocks, and this lead to the addition of
a formal note in PEP 8 about keeping narrow try blocks.

Contributing thread:

- `context manager - generator interaction?
`__

-
proposed which.py replacement
-

Suggestion of replacing the which.py script in the Tools directory migrated to
its proposal for inclusion into the standard library. A patch and tests have
yet to be provided.

Contributing thread:

- `proposed which.py replacement
`_

---
minidom and DOM level 2
---

What is missing for DOM Level 2 support in minidom was highlighted and
some work jumpstarted.

Contributing thread:

- `minidom and DOM level 2
`__

--
test_pty.py hangs in verbose mode on Mac OS X?
--

Differing buffering behavior was causing test_pty to block only in verbose
mode. Solutions may include reading to clear the buffer of child processes
before a waitpid() call.

Contributing thread:

- `test_pty.py hangs in verbose mode on Mac OS X?
`__

-
HTTP Responses and Errors
-

In 2xx HTTP responses mean that the request was handled OK.  The
existing library was special-casing the most common responses and
treating others as errors.  After verifying that there wasn't a good
reason for the old behavior, Facundo Batista fixed it.

Contributing thread:

- `HTT

Re: [Python-Dev] Python 2.5.1

[Jean-Paul Calderone]

On Sat, 28 Apr 2007 09:32:57 -0400, Raghuram Devarakonda <[EMAIL PROTECTED]> 
wrote:
>On 4/28/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
>> Index: test_os.py
>> ===
>> --- test_os.py  (revision 54982)
>> +++ test_os.py  (working copy)
>> @@ -6,6 +6,7 @@
>>  import unittest
>>  import warnings
>>  import sys
>> +import tempfile
>>  from test import test_support
>>
>>  warnings.filterwarnings("ignore", "tempnam", RuntimeWarning, __name__)
>> @@ -241,13 +242,18 @@
>>  self.assertEquals(os.stat(self.fname).st_mtime, t1)
>>
>>  def test_1686475(self):
>> +fn = tempfile.mktemp()
>> +openfile = open(fn, 'w')
>>  # Verify that an open file can be stat'ed
>>  try:
>> -os.stat(r"c:\pagefile.sys")
>> +os.stat(fn)
>>  except WindowsError, e:
>>  if e == 2: # file does not exist; cannot run test
>>  return
>>  self.fail("Could not stat pagefile.sys")
>> +finally:
>> +openfile.close()
>> +os.remove(fn)
>>
>>  from test import mapping_tests
>
>mktemp() is deprecated. You may want to use mkstemp(). There will be
>no need for explicit open as well as mkstemp() also returns open
>descriptor.

You still need fdopen() though, since os.stat() won't take a file
descriptor.

The patch is incomplete though, since it should remove the ENOENT
handling and the remaining reference to pagefile.sys.

As for mktemp() being deprecated - the docstring warns users away,
but actually calling it emits no warning.  Sure, using it can lead
to insecurities, but there's hardly any worry of that here.  If the
function were actually deprecated (that is, if calling it emitted a
DeprecationWarning), that would be a good reason to avoid calling it,
though.

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
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]

On 4/28/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Sat, 28 Apr 2007 09:32:57 -0400, Raghuram Devarakonda <[EMAIL PROTECTED]> 
> wrote:
> >On 4/28/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> >> Index: test_os.py
> >> ===
> >> --- test_os.py  (revision 54982)
> >> +++ test_os.py  (working copy)
> >> @@ -6,6 +6,7 @@
> >>  import unittest
> >>  import warnings
> >>  import sys
> >> +import tempfile
> >>  from test import test_support
> >>
> >>  warnings.filterwarnings("ignore", "tempnam", RuntimeWarning, __name__)
> >> @@ -241,13 +242,18 @@
> >>  self.assertEquals(os.stat(self.fname).st_mtime, t1)
> >>
> >>  def test_1686475(self):
> >> +fn = tempfile.mktemp()
> >> +openfile = open(fn, 'w')
> >>  # Verify that an open file can be stat'ed
> >>  try:
> >> -os.stat(r"c:\pagefile.sys")
> >> +os.stat(fn)
> >>  except WindowsError, e:
> >>  if e == 2: # file does not exist; cannot run test
> >>  return
> >>  self.fail("Could not stat pagefile.sys")
> >> +finally:
> >> +openfile.close()
> >> +os.remove(fn)
> >>
> >>  from test import mapping_tests
> >
> >mktemp() is deprecated. You may want to use mkstemp(). There will be
> >no need for explicit open as well as mkstemp() also returns open
> >descriptor.
>
> You still need fdopen() though, since os.stat() won't take a file
> descriptor.
>
> The patch is incomplete though, since it should remove the ENOENT
> handling and the remaining reference to pagefile.sys.
>
> As for mktemp() being deprecated - the docstring warns users away,
> but actually calling it emits no warning.  Sure, using it can lead
> to insecurities, but there's hardly any worry of that here.  If the
> function were actually deprecated (that is, if calling it emitted a
> DeprecationWarning), that would be a good reason to avoid calling it,
> though.
>
> Jean-Paul

Yes, duh, I changed the pagefile.sys in the message, which was silly
to have left.

As for os.fdopen(), it is not needed. tempfile.mkstemp() returns both
the file descriptor and the path, so we simply ignore the file
descriptor and pass the path to os.stat().

I'll report the patch with the message fixed.


-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Tracker Issues

[Tracker]

ACTIVITY SUMMARY (04/22/07 - 04/29/07)
Tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 1649 open ( +0) /  8584 closed ( +0) / 10233 total ( +0)

Average duration of open issues: 778 days.
Median duration of open issues: 729 days.

Open Issues Breakdown
   open  1649 ( +0)
pending 0 ( +0)

___
Python-Dev mailing list
Python-Dev@python.org
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

[Martin v. Löwis]

> I have a patch myself that creates an open file and uses that as the
> test. My reasoning is that pagefile.sys was chosen as a file that
> should always exist and be open, so its safe to test against, so we
> should just be testing against a fixture, instead. It is here, and if
> someone would reference a SF bug report, I'll attach to it, as well.

There must be more to the problem than just an open file. Please undo
the change that triggered the addition of the test, and see whether you
can reproduce the original problem with an arbitrary open file (I
could trigger the problem with pagefile.sys at the time).

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
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

[Calvin Spealman]

Comments welcome, of course. Bare with my first attempt at crafting a PEP.

PEP: XXX
Title: Super As A Keyword
Version: $Revision$
Last-Modified: $Date$
Author: Calvin Spealman <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
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.

::

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.

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.

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, the super type either needs a way to do dynamic
lookup of attributes on the super type object itself or define a metaclass for
the builtin type. This author is unsure which, if either, is possible with C-
defined types.

When should we create __super__ attributes?
'''

They either need to be created on class creation or on __super__ attribute
lookup. For the second, they could be cached, of course, which seems like it
may be the best idea, if implicit creation of a super object for every class is
considered too much overhead.


References
==

.. [1] Fixing super anyone?
   (http://mail.python.org/pipermail/python-3000/2007-April/006667.html)


Copyright
=

This document has been placed in the public domain.



..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End:


-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
Python-Dev mailing list
Python-Dev@python.org
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]

On 4/28/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I have a patch myself that creates an open file and uses that as the
> > test. My reasoning is that pagefile.sys was chosen as a file that
> > should always exist and be open, so its safe to test against, so we
> > should just be testing against a fixture, instead. It is here, and if
> > someone would reference a SF bug report, I'll attach to it, as well.
>
> There must be more to the problem than just an open file. Please undo
> the change that triggered the addition of the test, and see whether you
> can reproduce the original problem with an arbitrary open file (I
> could trigger the problem with pagefile.sys at the time).
>
> Regards,
> Martin

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. If that is the case, I am
unsure what problem there is with my fix of a temporary open file to
test upon.

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
Python-Dev mailing list
Python-Dev@python.org
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

[Adam Olsen]

On 4/28/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> Comments welcome, of course. Bare with my first attempt at crafting a PEP.
>
> PEP: XXX
> Title: Super As A Keyword
> Version: $Revision$
> Last-Modified: $Date$
> Author: Calvin Spealman <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 30-Apr-2007
> Python-Version: 2.6
> Post-History:

You need a section on alternate proposals.

-- 
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
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

[Collin Winter]

On 4/28/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> Comments welcome, of course. Bare with my first attempt at crafting a PEP.
>
> PEP: XXX
> Title: Super As A Keyword
> Version: $Revision$
> Last-Modified: $Date$
> Author: Calvin Spealman <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 30-Apr-2007
> Python-Version: 2.6
[snip]
> 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.

You're offering absolutely zero backwards compatibility and you're
targeting 2.6? Um, no; absolutely not. Even if you intend this for
3.0, you'll still need to define either a backwards compatibility
solution or a migration strategy (e.g., a 2to3 fixer). Without a
clear-cut way of addressing existing code, this idea is toast.

Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
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]

--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> There must be more to the problem than just an open
> file. Please undo the change that triggered the 
> addition of the test, and see whether you
> can reproduce the original problem with an arbitrary
> open file (I
> could trigger the problem with pagefile.sys at the 
> time).
>
> Regards,
> Martin

--- "Calvin Spealman"  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. If 
> that is the case, I am unsure what problem there is
> with >my fix of a temporary open file to test upon


I think the point is that the problem should be solved
(stat of open file) for any arbitrary open file
including pagefile.sys.

After booting into Win98, I can see that I have a
pagefile.sys indeed in my C drive which WinXP hides
from view. While in Win98 and with the file not in
use, the test passes on Win98 when looking for
pagefile.sys in C drive (no complaint about file not
found or access denied, even though I know that the
file is not open). And the test passes for the running
python.exe that is processing the test.

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. 

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.

Regards,
Khalid


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
Python-Dev mailing list
Python-Dev@python.org
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

[Khalid A. Bakr]

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.



259 tests OK.
8 tests failed:
test_anydbm test_bsddb test_mailbox test_os 
test_shelve test_unicode_file test_uuid 
test_whichdb
54 tests skipped:
test__locale test_aepack test_al test_applesingle 
test_bsddb185 test_bsddb3 test_cd test_cl 
test_codecmaps_cn test_codecmaps_hk
test_codecmaps_jp test_codecmaps_kr 
test_codecmaps_tw test_commands test_crypt 
test_curses test_dbm test_dl test_fcntl
test_fork1 test_gdbm test_gl test_grp test_imgfile

test_ioctl test_largefile test_linuxaudiodev 
test_macfs test_macostools test_mhlib test_nis 
test_normalization test_openpty test_ossaudiodev 
test_pep277 test_plistlib test_poll test_posix
test_pty test_pwd test_resource 
test_scriptpackages test_signal test_socket_ssl 
test_socketserver test_sunaudiodev test_tcl
test_threadsignals test_timeout test_urllib2net 
test_urllibnet test_wait3 test_wait4
test_zipfile64
1 skip unexpected on win32:
test_tcl
find_library('c') ->  None
find_library('m') ->  None
a DOS box should flash briefly ...



$ python -i
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC
v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> from test import test_os as t
>>> t.test_main()
test_access (test.test_os.FileTests) ... ok
test_tempnam (test.test_os.TemporaryFileTests) ... ok
test_tmpfile (test.test_os.TemporaryFileTests) ... ok
test_tmpnam (test.test_os.TemporaryFileTests) ... ok
test_1565150 (test.test_os.StatAttributeTests) ...
FAIL
test_1686475 (test.test_os.StatAttributeTests) ... ok
test_stat_attributes (test.test_os.StatAttributeTests)
... ok
test_statvfs_attributes
(test.test_os.StatAttributeTests) ... ok
test_bool (test.test_os.EnvironTests) ... ok
test_constructor (test.test_os.EnvironTests) ... ok
test_get (test.test_os.EnvironTests) ... ok
test_getitem (test.test_os.EnvironTests) ... ok
test_items (test.test_os.EnvironTests) ... ok
test_keys (test.test_os.EnvironTests) ... ok
test_len (test.test_os.EnvironTests) ... ok
test_pop (test.test_os.EnvironTests) ... ok
test_popitem (test.test_os.EnvironTests) ... ok
test_read (test.test_os.EnvironTests) ... ok
test_setdefault (test.test_os.EnvironTests) ... ok
test_update (test.test_os.EnvironTests) ... ok
test_update2 (test.test_os.EnvironTests) ... ok
test_values (test.test_os.EnvironTests) ... ok
test_write (test.test_os.EnvironTests) ... ok
test_traversal (test.test_os.WalkTests) ... ok
test_makedir (test.test_os.MakedirTests) ... ok
test_devnull (test.test_os.DevNullTests) ... ok
test_urandom (test.test_os.URandomTests) ... ok
test_access (test.test_os.Win32ErrorTests) ... ok
test_chdir (test.test_os.Win32ErrorTests) ... ok
test_chmod (test.test_os.Win32ErrorTests) ... ok
test_mkdir (test.test_os.Win32ErrorTests) ... ok
test_remove (test.test_os.Win32ErrorTests) ... ok
test_rename (test.test_os.Win32ErrorTests) ... ok
test_utime (test.test_os.Win32ErrorTests) ... ok

==
FAIL: test_1565150 (test.test_os.StatAttributeTests)
--
Traceback (most recent call last):
  File "G:\GMISC\PY25\lib\test\test_os.py", line 232,
in test_1565150
self.assertEquals(os.stat(self.fname).st_mtime,
t1)
AssertionError: 1159195040.0 != 1159195039.25

--
Ran 34 tests in 0.440s

FAILED (failures=1)
Traceback (most recent call last):
  File "", line 1, in 
  File "G:\GMISC\PY25\lib\test\test_os.py", line 434,
in test_main
Win32ErrorTests
  File "G:\GMISC\PY25\lib\test\test_support.py", line
441, in run_unittest
run_suite(suite, testclass)
  File "G:\GMISC\PY25\lib\test\test_support.py", line
426, in run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "G:\GMISC\PY25\lib\test\test_os.py", line 232,
in test_1565150
self.assertEquals(os.stat(self.fname).st_mtime,
t1)
AssertionError: 1159195040.0 != 1159195039.25

>>> 
>>> 
>>> 


Regards,
Khalid

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
Python-Dev mailing list
Python-Dev@python.org
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 Y Knight]

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, requiring that the arglist be specified is an  
attractive nuisance.

Now, I'm no syntax designer, but, just being able to say "super()"  
seems nice to me. (but don't get too hung up on that spelling, the  
concept of not having to repeat the arglist is the important point.)

James


___
Python-Dev mailing list
Python-Dev@python.org
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

[Josiah Carlson]

"Khalid A. Bakr" <[EMAIL PROTECTED]> wrote:
> 
> --- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > There must be more to the problem than just an open
> > file. Please undo the change that triggered the 
> > addition of the test, and see whether you
> > can reproduce the original problem with an arbitrary
> > open file (I
> > could trigger the problem with pagefile.sys at the 
> > time).
> >
> > Regards,
> > Martin
> 
> --- "Calvin Spealman"  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. If 
> > that is the case, I am unsure what problem there is
> > with >my fix of a temporary open file to test upon
> 
> 
> I think the point is that the problem should be solved
> (stat of open file) for any arbitrary open file
> including pagefile.sys.

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.

 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com