Re: [Python-Dev] What type of object mmap.read_byte should return on py3k?
I uploaded the patch with choice (a) http://bugs.python.org/file13215/py3k_mmap_and_bytes.patch If (b) is suitable, I'll rewrite the patch. ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Hi everybody, PEP 372 was modified so that it provides a simpler API (only the dict API to be exact) and it was decided to start with a Python-only implementation and replace it with a C version later if necessary. Annotated changes from earlier versions of the PEP: - the extra API for ordered dict was dropped to keep the interface simple and clean. Future versions can still be expanded but it's impossible to drop features later on. - To keep the implementation simple 3.1 / 2.7 will ship with a Python-only version of the class. It can still be rewritten in C if it turns out to be too slow or thread safety is required. The corresponding issue in the tracker: http://bugs.python.org/issue5397 Link to the PEP: http://www.python.org/dev/peps/pep-0372/ Anything else that should be done? Regards, Armin ___ 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] draft 3.1 release schedule
2009/2/27 Benjamin Peterson : > 2009/2/27 Nick Coghlan schrieb: >> >> I should have a PEP (and implementation) ready for alpha 2 to address >> the current discrepancy between contextlib.nested and actual nested with >> statements: >> http://bugs.python.org/issue5251 >> >> If you do add a reference to that bug report to the release PEP, mark >> fixing it as a maybe though - with the associated PEP not even written >> yet, I obviously still have some work to do to get the semantic change >> approved by Guido and the rest of python-dev. > > Ok. I've added it. Is it worth getting simplegeneric exposed in 3.1 (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd like to see it hit 3.1. The patch is against trunk (for 2.7) at the moment, I'm not sure what the process would be for forward-porting it (do I generate a new patch against the py3k branch, or should it be applied to trunk and merged in?) 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] draft 3.1 release schedule
Paul Moore wrote: > 2009/2/27 Benjamin Peterson : >> 2009/2/27 Nick Coghlan schrieb: >>> I should have a PEP (and implementation) ready for alpha 2 to address >>> the current discrepancy between contextlib.nested and actual nested with >>> statements: >>> http://bugs.python.org/issue5251 >>> >>> If you do add a reference to that bug report to the release PEP, mark >>> fixing it as a maybe though - with the associated PEP not even written >>> yet, I obviously still have some work to do to get the semantic change >>> approved by Guido and the rest of python-dev. >> Ok. I've added it. > > Is it worth getting simplegeneric exposed in 3.1 > (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd > like to see it hit 3.1. The patch is against trunk (for 2.7) at the > moment, I'm not sure what the process would be for forward-porting it > (do I generate a new patch against the py3k branch, or should it be > applied to trunk and merged in?) As much as I'd like to get a simple generic implementation into functools, the lack of support for ABCs still bothers me (despite my last post about that on the tracker item). I'd be a -0 on it going in as is, but if someone can figure out a clever way of supporting ABCs without completing killing the invocation speed for generics, that would go up to a +1. (The current difficulty of this may actually reflect a more significant limitation on the available metadata for ABCs in PEP 3119: it is easy to ask "is this specific type an example of this ABC?", but difficult to ask "which ABCs is this type as example of?". For actual inheritance, the __mro__ attribute means that both questions are easy to answer, but I'm not aware of any corresponding way of answering the latter question for ABCs) Cheers, Nick. P.S. I just unassigned myself from that tracker item - I'm going to have my hands full working on the proposed change to the with statement. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] test_io fails on test_1686475
Running the test suite with Python 2.6.1 32 bit (compiled in DEBUG mode with Visual Studio Express Edition 2008) on Vista x64, I've got an assert error: test_1686475 (__main__.StatAttributeTests) ... Assertion failed: (__int64)(int)((in / 1000) - secs_between_epochs) == ((in / 1000) - secs_between_epochs), file ..\Modules\posixmodule.c, line 790 I have no idea about this failure. Any hint? Cheers, Cesare ___ 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] test_io fails on test_1686475
On Sun, 2009-03-01 at 23:04 +0100, Cesare Di Mauro wrote: > Running the test suite with Python 2.6.1 32 bit (compiled in DEBUG mode > with Visual Studio Express Edition 2008) on Vista x64, I've got an assert > error: > > test_1686475 (__main__.StatAttributeTests) ... Assertion failed: > (__int64)(int)((in / 1000) - secs_between_epochs) == ((in / 1000) > - secs_between_epochs), file ..\Modules\posixmodule.c, line 790 > > I have no idea about this failure. Any hint? [I haven't checked the test yet, let me know if my guess is wrong :)]. It looks to me that its asserting something to do with stat times; note that windows has up to a 2 second granularity for stat times on files - you may be hitting some code that assumes a sane file system :) -Rob signature.asc Description: This is a digitally signed message part ___ 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] test_io fails on test_1686475
Hello, On Sun, Mar 1, 2009 at 23:04, Cesare Di Mauro wrote: > Running the test suite with Python 2.6.1 32 bit (compiled in DEBUG mode > with Visual Studio Express Edition 2008) on Vista x64, I've got an assert > error: > > test_1686475 (__main__.StatAttributeTests) ... Assertion failed: > (__int64)(int)((in / 1000) - secs_between_epochs) == ((in / 1000) > - secs_between_epochs), file ..\Modules\posixmodule.c, line 790 > > I have no idea about this failure. Any hint? The failing assertion comes from this code in posixmodule.c: /* XXX Win32 supports time stamps past 2038; we currently don't */ *time_out = Py_SAFE_DOWNCAST((in / 1000) - secs_between_epochs, __int64, int); the test (btw, it's in test_os.py) is trying os.stat(r"c:\pagefile.sys") Can you please check the three time stamps of this file (creation, update, access)? -- Amaury Forgeot d'Arc ___ 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] draft 3.1 release schedule
2009/3/1 Paul Moore : > > Is it worth getting simplegeneric exposed in 3.1 > (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd > like to see it hit 3.1. The patch is against trunk (for 2.7) at the > moment, I'm not sure what the process would be for forward-porting it > (do I generate a new patch against the py3k branch, or should it be > applied to trunk and merged in?) Patches to the trunk are fine. As for the actual feature, I don't think it should hold up releases. -- Regards, Benjamin ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Sun, 1 Mar 2009 19:13:27 + (UTC), Armin Ronacher wrote: Hi everybody, PEP 372 was modified so that it provides a simpler API (only the dict API to be exact) and it was decided to start with a Python-only implementation and replace it with a C version later if necessary. Annotated changes from earlier versions of the PEP: - the extra API for ordered dict was dropped to keep the interface simple and clean. Future versions can still be expanded but it's impossible to drop features later on. Keeping the API simple and clean sounds great. I'm all in favor of this. However, it does no one a service to continue to propagate the idea that all the code written for Python always has to be perfect. It's feasible and even simple to drop features later on, should it turn out to be that they are not desirable. 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] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement
[Armin Ronacher] PEP 372 was modified so that it provides a simpler API (only the dict API to be exact) and it was decided to start with a Python-only implementation and replace it with a C version later if necessary. Annotated changes from earlier versions of the PEP: - the extra API for ordered dict was dropped to keep the interface simple and clean. Future versions can still be expanded but it's impossible to drop features later on. - To keep the implementation simple 3.1 / 2.7 will ship with a Python-only version of the class. It can still be rewritten in C if it turns out to be too slow or thread safety is required. The corresponding issue in the tracker: http://bugs.python.org/issue5397 Link to the PEP: http://www.python.org/dev/peps/pep-0372/ Anything else that should be done? Guido, I'm recommending this PEP for acceptance. Raymond ___ 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
