Re: [Python-Dev] [issue8033] sqlite: broken long integer handling for arguments to user-defined functions
On 2011-01-05, at 8:16 AM, Phil Le Bienheureux wrote: Hello, I am quite new to development in python, and as a first contribution to the community, I have provided a patch to the issue 8033 (quite trivial). I then ran the test suite an everything was ok. However, the status has not changed, and nobody has answered so far (patch provided one month ago). So my question : has I missed something in the procedure that I read carefully, to deliver a patch, or something else? I'm not a core developer, but there's two reasons I can think of: 1. Your diff doesn't include tests. 2. Core developers are busy, these things take time. I don't think any bugfix gets checked in without a regression test to go with it. A core developer coming by your issue could maybe do it himself, but since he's likely very busy, he won't have time for this. So your best bet for this fix to be checked in is to add a test, but even then, sometimes, patches fade into oblivion and you might have to regularly freshen your diff to match with the trunk so it applies cleanly. Virgil Dupras ___ 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] Possible optimization for LOAD_FAST ?
On 1/4/2011 6:39 PM, Guido van Rossum wrote: So, that significantly weakens the argument that this optimization will break unit tests, since I am happy to promise never to optimize these builtins, and any other builtins intended for I/O. This is one comprehensible rule rather than a list of exceptions, so easier to remember. It has two rationales: such often need to be over-riden for testing, possibly in hidden ways; such are inherently 'slow' so optimizing dict lookup away hardly makes sense. -- Terry Jan Reedy ___ 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-checkins] devguide: Strip out all generic svn instructions from the FAQ. It's not only
On 1/5/2011 1:18 AM, Eli Bendersky wrote: On Wed, Jan 5, 2011 at 04:13, Nick Coghlan ncogh...@gmail.com Your call as the author, but please reconsider this one. I've found it *hugely* convenient over the years to have these task oriented answers in the FAQ. The problem with the answers all over the internet is that I (or someone new to our source control tool) may not know enough to ask the right question, and hence those answers may as well not exist. Even if these FAQ answers don't always provide everything needed, they usually provide enough information to let me search for the full answers. I agree with Nick here. I also found these instructions useful in the past, although I'm quite familiar with SVN. New devs interested in contributing to Python but not too familiar with the source-control tool it's using at the time will benefit even more from this. As for maintenance nightmare, I'm sure it's simple enough to attract contributors. For example, I can volunteer to maintain it. As a complete neophyte at actually using a source code system, I found the stripped-down step-by-step instructions useful even though I am using TortoiseSVN. Even the TortoiseSVN help doc is a bit overwhelming because it includes so much that I do not need to read. It would be a bit like a beginning programmer trying to learn Python from the Langauge Reference without having the Tutorial to read. (And even as an experienced C programmer, I started with the latter.) -- Terry Jan Reedy ___ 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] Hello everyone
Hello everyone, My name is Yeswanth . I am doing my third year Btech in Computer Science in India. My desire is to get into gsoc 2011 . I have been looking over the projects of last year to see where I would fit in. And I found python to be interesting, something I can contribute. I dont know if Python Software Foundation will apply for Gsoc this year, I just hope it will . So here I am , planning to make an entry in contributing to this open source project. I can just program in Python ,never contributed anything to it , atleast of now. So I have read the development links provided in the python.org site. Can anyone suggest me some areas where I can actually start with developing for this proje ___ 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] Omit Py_buffer struct from Stable ABI for Python 3.2?
Currently [1], the implementation and the documentation for PEP 3118's Py_buffer struct don't line up (there's an extra field in the implementation that the PEP doesn't mention). Accordingly, Mark and I think it may be a good idea to leave this structure (and possibly related APIs) out of the stable ABI for the 3.2 release. I don't *think* it needs changing, but I'm not 100% certain until we finish working through the problem and realign the implementation and documentation. Applications and extension modules that use this interface would still work - they would just have to wait until 3.3 before they could consider migrating to the stable ABI. Regards, Nick. [1] http://bugs.python.org/issue10181 -- 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
Re: [Python-Dev] Omit Py_buffer struct from Stable ABI for Python 3.2?
On Wed, Jan 5, 2011 at 12:31 PM, Nick Coghlan ncogh...@gmail.com wrote: Currently [1], the implementation and the documentation for PEP 3118's Py_buffer struct don't line up (there's an extra field in the implementation that the PEP doesn't mention). I think there are actually two such fields: smalltable and obj. The need for obj is a little ugly: as far as I can tell, it's meaningless for a 3rd-party object that wants to export buffers---it's only really used by the memoryview object and by internal Python types. Mark ___ 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] Omit Py_buffer struct from Stable ABI for Python 3.2?
On Wed, 5 Jan 2011 12:55:55 + Mark Dickinson dicki...@gmail.com wrote: On Wed, Jan 5, 2011 at 12:31 PM, Nick Coghlan ncogh...@gmail.com wrote: Currently [1], the implementation and the documentation for PEP 3118's Py_buffer struct don't line up (there's an extra field in the implementation that the PEP doesn't mention). I think there are actually two such fields: smalltable and obj. The need for obj is a little ugly: as far as I can tell, it's meaningless for a 3rd-party object that wants to export buffers---it's only really used by the memoryview object and by internal Python types. I don't think it's ugly. It's the only way to know which object exported a Py_buffer. Otherwise you have to track the information separately, which is quite a bit uglier (especially when in conjunction with PyArg_ParseTuple and friends). Regards Antoine. ___ 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] Possible optimization for LOAD_FAST ?
How about not changing semantics and still making this optimization possible? PyPy already has CALL_LIKELY_BUILTIN which checks whether builtins has been altered (by keeping a flag on the module dictionary) and if not, loads a specific builtin on top of value stack. From my current experience, I would make a bet that someone is altering pretty much every builtin for some dark reasons. One that comes to mind is to test something using external library which is not playing along too well. That however only lets one avoid dictionary lookups, it doesn't give potential for other optimizations (which in my opinion are limited until we hit something dynamic like an instance, but let's ignore it). How about creating two copies of bytecode (that's not arbitrary number, just 2) and a way to go from more optimized to less optimized in case *any* of promises is invalidated? That gives an ability to save semantics, while allowing optimizations. That said, I think CPython should stay as a simple VM and refrain from doing things that are much easier in the presence of a JIT (and give a lot more speedups), but who am I to judge. Cheers, fijal ___ 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] Omit Py_buffer struct from Stable ABI for Python 3.2?
On Wed, Jan 5, 2011 at 2:03 PM, Mark Dickinson dicki...@gmail.com wrote: Maybe I'm misunderstanding. What's the responsibility of a buffer export w.r.t. the obj field---i.e., what should 3rd party code be Grr. *buffer exporter*, not *buffer export*. Mark ___ 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] Omit Py_buffer struct from Stable ABI for Python 3.2?
On Wed, Jan 5, 2011 at 1:13 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 5 Jan 2011 12:55:55 + Mark Dickinson dicki...@gmail.com wrote: The need for obj is a little ugly: as far as I can tell, it's meaningless for a 3rd-party object that wants to export buffers---it's only really used by the memoryview object and by internal Python types. I don't think it's ugly. It's the only way to know which object exported a Py_buffer. Otherwise you have to track the information separately, which is quite a bit uglier (especially when in conjunction with PyArg_ParseTuple and friends). Maybe I'm misunderstanding. What's the responsibility of a buffer export w.r.t. the obj field---i.e., what should 3rd party code be filling that obj field with in a call to getbuffer? It looks to me as though it's really the memoryview object that needs this information; that it doesn't belong in the Py_buffer struct. Isn't that what the 'base' field in PyMemoryViewObject in PEP 3118 was supposed to be for? Though I notice that that field is unused in the actual PyMemoryViewObject in Include/memoryobject.h. Mark ___ 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] Omit Py_buffer struct from Stable ABI for Python 3.2?
On Wed, 5 Jan 2011 14:03:41 +
Mark Dickinson dicki...@gmail.com wrote:
On Wed, Jan 5, 2011 at 1:13 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 5 Jan 2011 12:55:55 +
Mark Dickinson dicki...@gmail.com wrote:
The need for obj is a little ugly: as far as I can tell, it's
meaningless for a 3rd-party object that wants to export buffers---it's
only really used by the memoryview object and by internal Python
types.
I don't think it's ugly. It's the only way to know which object exported
a Py_buffer. Otherwise you have to track the information separately,
which is quite a bit uglier (especially when in conjunction with
PyArg_ParseTuple and friends).
Maybe I'm misunderstanding. What's the responsibility of a buffer
export w.r.t. the obj field---i.e., what should 3rd party code be
filling that obj field with in a call to getbuffer?
It would let PyBuffer_FillInfo() do the job.
If it doesn't want to, it must put itself in that field, and increment
its reference count.
It looks to me as though it's really the memoryview object that needs
this information;
No, anyone wanting to release a buffer without keeping separate track
of the original object needs it. As I said, this also applies to users
of PyArg_ParseTuple and friends (s*, y* etc. format codes).
Isn't that what the 'base' field in PyMemoryViewObject in PEP 3118 was
supposed to be for?
Perhaps, but practice (implementing s* etc.) suggested it was useful
in other cases. That field ('base') is removed in 3.2.
Regards
Antoine.
___
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] Omit Py_buffer struct from Stable ABI for Python 3.2?
On Thu, Jan 6, 2011 at 12:03 AM, Mark Dickinson dicki...@gmail.com wrote: Maybe I'm misunderstanding. What's the responsibility of a buffer export w.r.t. the obj field---i.e., what should 3rd party code be filling that obj field with in a call to getbuffer? It should be a pointer to the object (with the reference count incremented appropriately). GetBuffer/ReleaseBuffer should actually manage it automatically, but I'd have to look at the code to make sure that is the case (and, if it isn't, there may be backwards compatibility implications in fixing it). It looks to me as though it's really the memoryview object that needs this information; that it doesn't belong in the Py_buffer struct. Isn't that what the 'base' field in PyMemoryViewObject in PEP 3118 was supposed to be for? Though I notice that that field is unused in the actual PyMemoryViewObject in Include/memoryobject.h. If nothing else, PyObject_ReleaseBuffer needs it - otherwise the function signature would need to include a separate argument to tell it who the buffer belongs to (so it can find the appropriate function pointer to call). The implementation makes sense (since every call to GetBuffer needs to be paired with a corresponding call to ReleaseBuffer, it makes sense to keep the object reference inside the Py_buffer struct), but the fact the documentation was never corrected suggests there are going to be plenty of broken implementations of the protocol kicking around, potentially even in the standard library. Cheers, Nick. -- 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
Re: [Python-Dev] Checking input range in time.asctime and time.ctime
On Mon, Jan 3, 2011 at 7:47 PM, Guido van Rossum gu...@python.org wrote: Given the rule garbage in - garbage out, I'd do the most useful thing, which would be to produce a longer output string (and update the docs). This would match the behavior of e.g. '%04d' % y when y . If that means the platform libc asctime/ctime can't be used, too bad. I've committed code that does not use platform libc asctime/ctime anymore. Now it seems odd that we support years but not years 1900. A commonly given explanation for rejecting years 1900 is that Python has to support POSIX standard for 2-digit years. However, this support is conditional on the value of time.accept2dyear and several people argued that when it is set to false, full range of years should be supported. Furthermore, in order to support 2-digit years, there is no need to reject years 1900. It may be confusing to map 99 to 1999 while accepting 100 as is, but I don't see much of the problem in accepting 4-digit years from 1000 through 1899 while mapping [0 - 99] to present times according to POSIX standard. See http://bugs.python.org/issue10827 for more. ___ 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] Checking input range in time.asctime and time.ctime
On Wed, 5 Jan 2011 12:33:55 -0500 Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Mon, Jan 3, 2011 at 7:47 PM, Guido van Rossum gu...@python.org wrote: Given the rule garbage in - garbage out, I'd do the most useful thing, which would be to produce a longer output string (and update the docs). This would match the behavior of e.g. '%04d' % y when y . If that means the platform libc asctime/ctime can't be used, too bad. I've committed code that does not use platform libc asctime/ctime anymore. Now it seems odd that we support years but not years 1900. A commonly given explanation for rejecting years 1900 is that Python has to support POSIX standard for 2-digit years. However, this support is conditional on the value of time.accept2dyear and several people argued that when it is set to false, full range of years should be supported. Couldn't we deprecate and remove time.accept2dyear? It has been there for backward compatibility since Python 1.5.2. Not to mention that global settings affecting behaviour are generally bad, since multiple libraries could have conflicting expectations about it. And parsing times and dates is the kind of thing that a library will often rely on. Regards Antoine. ___ 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] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 12:48 PM, Antoine Pitrou solip...@pitrou.net wrote:
..
Couldn't we deprecate and remove time.accept2dyear? It has been there
for backward compatibility since Python 1.5.2.
It will be useful for another 50 years or so. (POSIX 2-digit years
cover 1969 - 2068.) In any case, this is not an option for 3.2 while
extending accepted range is a borderline case IMO.
Not to mention that global settings affecting behaviour are generally
bad, since multiple libraries could have conflicting expectations about
it. And parsing times and dates is the kind of thing that a library
will often rely on.
Yes, for 3.3 I am going to propose an optional accept2dyear argument
to time.{asctime, strftime} in addition to or instead of a global
variable. This is also necessary to implement a pure python version
of datetime.strftime that would support full range of datetime. See
http://bugs.python.org/issue1777412 .
___
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] Omit Py_buffer struct from Stable ABI for Python 3.2?
Mark Dickinson, 05.01.2011 13:55: On Wed, Jan 5, 2011 at 12:31 PM, Nick Coghlan wrote: Currently [1], the implementation and the documentation for PEP 3118's Py_buffer struct don't line up (there's an extra field in the implementation that the PEP doesn't mention). I think there are actually two such fields: smalltable and obj. The need for obj is a little ugly: as far as I can tell, it's meaningless for a 3rd-party object that wants to export buffers---it's only really used by the memoryview object and by internal Python types. Not at all. It's the reason why some of the buffer API functions could be changed to a simpler signature after earlier versions of the PEP had been written. Stefan ___ 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] Possible optimization for LOAD_FAST ?
On Wed, Jan 5, 2011 at 5:27 AM, Maciej Fijalkowski fij...@gmail.com wrote: How about not changing semantics and still making this optimization possible? PyPy already has CALL_LIKELY_BUILTIN which checks whether builtins has been altered (by keeping a flag on the module dictionary) and if not, loads a specific builtin on top of value stack. I can only repeat what I said before. That's what everybody proposes, and if you have the infrastructure, it's a fine solution. But to me, those semantics aren't sacred, and I want to at least explore an alternative. Putting a hook on two dicts (the module globals and builtins.__dict__) is a lot of work in CPython, and has the risk of slowing everything down (just a tad, but still -- AFAIK dicts currently are not hookable). Checking whether there's a global named 'len' is much simpler in the current CPython compiler. -- --Guido van Rossum (python.org/~guido) ___ 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-checkins] devguide: Strip out all generic svn instructions from the FAQ. It's not only
To those that want to keep those steps in the dev FAQ, go ahead but I recuse myself from maintaining it. Having had so many instances of people asking how do I do this? and me almost always able to go read the dev FAQ has basically made me feel like it is not worth the effort if people are not going to bother to check it and just simply ask how to do things. The copy of the dev FAQ on the website has not been touched, so me cutting this stuff out so I know what has and has not been covered has no permanent impact. Plus having the devguide on hg.python.org and not the website means anyone with commit rights can modify the devguide, including adding/maintaining a dev FAQ on common VCS/SSH/whatever tools. On Wed, Jan 5, 2011 at 01:08, Terry Reedy tjre...@udel.edu wrote: On 1/5/2011 1:18 AM, Eli Bendersky wrote: On Wed, Jan 5, 2011 at 04:13, Nick Coghlan ncogh...@gmail.com Your call as the author, but please reconsider this one. I've found it *hugely* convenient over the years to have these task oriented answers in the FAQ. The problem with the answers all over the internet is that I (or someone new to our source control tool) may not know enough to ask the right question, and hence those answers may as well not exist. Even if these FAQ answers don't always provide everything needed, they usually provide enough information to let me search for the full answers. I agree with Nick here. I also found these instructions useful in the past, although I'm quite familiar with SVN. New devs interested in contributing to Python but not too familiar with the source-control tool it's using at the time will benefit even more from this. As for maintenance nightmare, I'm sure it's simple enough to attract contributors. For example, I can volunteer to maintain it. As a complete neophyte at actually using a source code system, I found the stripped-down step-by-step instructions useful even though I am using TortoiseSVN. Even the TortoiseSVN help doc is a bit overwhelming because it includes so much that I do not need to read. It would be a bit like a beginning programmer trying to learn Python from the Langauge Reference without having the Tutorial to read. (And even as an experienced C programmer, I started with the latter.) -- Terry Jan Reedy ___ 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/brett%40python.org ___ 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] Hello everyone
On Wed, 05 Jan 2011 17:18:00 +0530, yeswanth swamiyeswa...@hotmail.com wrote: My name is Yeswanth . I am doing my third year Btech in Computer Science [...] Can anyone suggest me some areas where I can actually start with developing for this proje Welcome, Yeswanth. Great idea to get involved early :) I'm guessing the PSF will apply to GSoC in 2011, but I'm not involved in that decision so I don't really know anything. The best way to start out helping is to do what you've done, read the developer docs (which Brett Cannon is currently updating, by the way). Next you could take a look at the bug tracker at bugs.python.org. There are plenty of open issues there that need to be reviewed (anyone can do reviews). Try out patches for issues that have existing patches, note anything missing (tests, doc updates, etc) (supply them if you like), and report your experiences with testing the patch, and any comments you may have on it. When you feel ready to try your hand at writing patches, click on the 'easy issues' button on the left. That tag is assigned to bugs where the reviewer thought the patch could be written in a day or less of work (of course, if you are still relatively new to Python coding it may take longer to do the necessary research to be able to write the patch). If you like you can also come hang out on the #python-dev IRC channel on freenode, where a number of the core developers and other folks hang out and discuss issues (among other things :) -- R. David Murray www.bitdance.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] Hello everyone
On Wed, Jan 5, 2011 at 05:48, yeswanth swamiyeswa...@hotmail.com wrote: Hello everyone, My name is Yeswanth . I am doing my third year Btech in Computer Science in India. My desire is to get into gsoc 2011 . I have been looking over the projects of last year to see where I would fit in. And I found python to be interesting, something I can contribute. I dont know if Python Software Foundation will apply for Gsoc this year, I just hope it will . So here I am , planning to make an entry in contributing to this open source project. I can just program in Python ,never contributed anything to it , atleast of now. So I have read the development links provided in the python.org site. Can anyone suggest me some areas where I can actually start with developing for this proje Yeswanth, http://docs.pythonsprints.com/core_development/beginners.html might be helpful for getting started, and to supplement David's suggestions. It was written for users like yourself to go from zero to successful contribution as quick as possible. Brian ___ 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] Hello everyone
Am 05.01.2011 12:48, schrieb yeswanth: Hello everyone, My name is Yeswanth . I am doing my third year Btech in Computer Science in India. My desire is to get into gsoc 2011 . I have been looking over the projects of last year to see where I would fit in. And I found python to be interesting, something I can contribute. I dont know if Python Software Foundation will apply for Gsoc this year, I just hope it will . So here I am , planning to make an entry in contributing to this open source project. I can just program in Python ,never contributed anything to it , atleast of now. So I have read the development links provided in the python.org site. Can anyone suggest me some areas where I can actually start with developing for this proje PSF GSoC applicants will be asked to submit a patch to the Python(ic) project they are going to contribute to, as a proof that they actually know how to write code. So I suggest you browse through the bug tracker, find an open issue with no patch, and write a patch. You may want to focus on issues marked as easy. 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
Re: [Python-Dev] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 10:12 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Jan 5, 2011 at 12:48 PM, Antoine Pitrou solip...@pitrou.net wrote:
..
Couldn't we deprecate and remove time.accept2dyear? It has been there
for backward compatibility since Python 1.5.2.
It will be useful for another 50 years or so. (POSIX 2-digit years
cover 1969 - 2068.) In any case, this is not an option for 3.2 while
extending accepted range is a borderline case IMO.
I like accepting all years = 1 when accept2dyear is False.
In 3.3 we should switch its default value to False (in addition to the
keyword arg you are proposing below, maybe).
Maybe we can add a deprecation warning in 3.2 when a 2d year is
actually received? The posix standard notwithstanding they should be
rare, and it would be better to make this the app's responsibility if
we could.
Not to mention that global settings affecting behaviour are generally
bad, since multiple libraries could have conflicting expectations about
it. And parsing times and dates is the kind of thing that a library
will often rely on.
Yes, for 3.3 I am going to propose an optional accept2dyear argument
to time.{asctime, strftime} in addition to or instead of a global
variable. This is also necessary to implement a pure python version
of datetime.strftime that would support full range of datetime. See
http://bugs.python.org/issue1777412 .
I wish we didn't have to do that -- isn't it easy enough for the app
to do the 2d - 4d conversion itself before calling the library
function? The only exception would be when parsing a string -- but
strptime can tell whether a 2d or 4d year is requested by the format
code (%y or %Y).
--
--Guido van Rossum (python.org/~guido)
___
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] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 2:19 PM, Guido van Rossum gu...@python.org wrote: .. extending accepted range is a borderline case IMO. I like accepting all years = 1 when accept2dyear is False. Why = 1? Shouldn't it be = 1900 - maxint? Also, what is your take on always accepting [1000 - 1899]? Now, to play the devil's advocate a little, with the new logic accept2dyear would actually mean map 2-digit year because 2-digit years will be accepted when accept2dyear is False, just not mapped to reasonable range. I don't have much of a problem with having a deprecated setting that does not have the meaning that its name suggests. (At the moment accept2dyear = True is actually treated as accept2dyear = 0!) I am mentioning this because I think the logic should be if accept2dyear: if 0 = y 69: y += 2000 elif 69 = y 100: y += 1900 elif 100 = y 1000: raise ValueError(3-digit year in map 2-digit year mode) and even the last elif may not be necessary. In 3.3 we should switch its default value to False (in addition to the keyword arg you are proposing below, maybe). Note that time.accept2dyear is controlled by PYTHONY2K environment variable. If we switch the default, we may need to add a variable with the opposite meaning. Maybe we can add a deprecation warning in 3.2 when a 2d year is actually received? +1, but only when with accept2dyear = 1. When accept2dyear = 0, any year should just pass through and this should eventually become the only behavior. The posix standard notwithstanding they should be rare, and it would be better to make this the app's responsibility if we could. .. I wish we didn't have to do that -- isn't it easy enough for the app to do the 2d - 4d conversion itself before calling the library function? Note that this is already done at least in two places in stdlib: in email package parsedate_tz and in _strptime.py. Given that the POSIX convention is arbitrary and unintuitive, maybe we should provide time.posix2dyear() function for this purpose. The only exception would be when parsing a string -- but strptime can tell whether a 2d or 4d year is requested by the format code (%y or %Y). Existing stdlib date parsing code already does that and ignores accept2dyear setting. ___ 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] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 12:58 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Jan 5, 2011 at 2:19 PM, Guido van Rossum gu...@python.org wrote: .. extending accepted range is a borderline case IMO. I like accepting all years = 1 when accept2dyear is False. Why = 1? Because that's what the datetime module accepts. Shouldn't it be = 1900 - maxint? Also, what is your take on always accepting [1000 - 1899]? Now, to play the devil's advocate a little, with the new logic accept2dyear would actually mean map 2-digit year because 2-digit years will be accepted when accept2dyear is False, just not mapped to reasonable range. I don't have much of a problem with having a deprecated setting that does not have the meaning that its name suggests. (At the moment accept2dyear = True is actually treated as accept2dyear = 0!) I am mentioning this because I think the logic should be if accept2dyear: if 0 = y 69: y += 2000 elif 69 = y 100: y += 1900 elif 100 = y 1000: raise ValueError(3-digit year in map 2-digit year mode) and even the last elif may not be necessary. Shouldn't the logic be to take the current year into account? By the time 2070 comes around, I'd expect 70 to refer to 2070, not to 1970. In fact, I'd expect it to refer to 2070 long before 2070 comes around. All of which makes me think that this is better left to the app, which can decide for itself whether it is more important to represent dates in the future or dates in the past. In 3.3 we should switch its default value to False (in addition to the keyword arg you are proposing below, maybe). Note that time.accept2dyear is controlled by PYTHONY2K environment variable. If we switch the default, we may need to add a variable with the opposite meaning. Yeah, but who sets that variable? Couldn't we make it so that if PYTHONY2K is set (even to the empty string) it wins, but if it's not set (at all) we can make the default adjust over time? Maybe we can add a deprecation warning in 3.2 when a 2d year is actually received? +1, but only when with accept2dyear = 1. When accept2dyear = 0, any year should just pass through and this should eventually become the only behavior. The posix standard notwithstanding they should be rare, and it would be better to make this the app's responsibility if we could. .. I wish we didn't have to do that -- isn't it easy enough for the app to do the 2d - 4d conversion itself before calling the library function? Note that this is already done at least in two places in stdlib: in email package parsedate_tz and in _strptime.py. Given that the POSIX convention is arbitrary and unintuitive, maybe we should provide time.posix2dyear() function for this purpose. The only exception would be when parsing a string -- but strptime can tell whether a 2d or 4d year is requested by the format code (%y or %Y). Existing stdlib date parsing code already does that and ignores accept2dyear setting. -- --Guido van Rossum (python.org/~guido) ___ 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] Checking input range in time.asctime and time.ctime
On Jan 5, 2011, at 4:33 PM, Guido van Rossum wrote: Shouldn't the logic be to take the current year into account? By the time 2070 comes around, I'd expect 70 to refer to 2070, not to 1970. In fact, I'd expect it to refer to 2070 long before 2070 comes around. All of which makes me think that this is better left to the app, which can decide for itself whether it is more important to represent dates in the future or dates in the past. The point of this somewhat silly flag (as I understood its description earlier in the thread) is to provide compatibility with POSIX 2-year dates. As per http://pubs.opengroup.org/onlinepubs/007908799/xsh/strptime.html - %y is the year within century. When a century is not otherwise specified, values in the range 69-99 refer to years in the twentieth century (1969 to 1999 inclusive); values in the range 00-68 refer to years in the twenty-first century (2000 to 2068 inclusive). Leading zeros are permitted but not required. So, 70 means 1970, forever, in programs that care about this nonsense. Personally, by the time 2070 comes around, I hope that 70 will just refer to 70 A.D., and get you odd looks if you use it in a written date - you might as well just write '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-checkins] r87768 - in python/branches/py3k: Lib/socket.py Lib/test/test_socket.py Misc/NEWS
Issue #7995: When calling accept() on a socket with a timeout, the returned socket is now always non-blocking, regardless of the operating system. Seems clear enough +# Issue #7995: if no default timeout is set and the listening +# socket had a (non-zero) timeout, force the new socket in blocking +# mode to override platform-specific socket flags inheritance. Slightly confusing +# Issue #7995: when calling accept() on a listening socket with a +# timeout, the resulting socket should not be non-blocking. Seems to contradict the first. 'sould not be non-blocking' to me means 'should be blocking', as opposed to 'is now ... non-blocking'. Terry ___ 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-checkins] devguide: Start a doc on running and writing unit tests.
+The shortest, simplest way of running the test suite is:: + +./python -m test Not on Windows. C:\Programs\Python32./python -m test '.' is not recognized as an internal or external command, operable program or batch file. python -m test works (until it failed, separate issue). I would like to know, insofar as possible, how to run tests from the interpreter prompt (or IDLE simulation thereof) from whatmod import whatfunc; whatfunc() # ?? ditto for such remaining alternatives you give as can be made from prompt. Besides the convenience for Windows users (for whom the Command Prompt window is hidden away and possibly unknown), I think we should know if any tests are incompatible with interactive mode. --- Terry Jan Reedy ___ 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-checkins] r87768 - in python/branches/py3k: Lib/socket.py Lib/test/test_socket.py Misc/NEWS
On Wed, 05 Jan 2011 17:21:23 -0500 Terry Reedy tjre...@udel.edu wrote: Issue #7995: When calling accept() on a socket with a timeout, the returned socket is now always non-blocking, regardless of the operating system. Seems clear enough +# Issue #7995: if no default timeout is set and the listening +# socket had a (non-zero) timeout, force the new socket in blocking +# mode to override platform-specific socket flags inheritance. Slightly confusing +# Issue #7995: when calling accept() on a listening socket with a +# timeout, the resulting socket should not be non-blocking. Seems to contradict the first. 'sould not be non-blocking' to me means 'should be blocking', as opposed to 'is now ... non-blocking'. Thank you for spotting the contradiction; this is now fixed. Regards Antoine. ___ 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] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 4:33 PM, Guido van Rossum gu...@python.org wrote: .. Why = 1? Because that's what the datetime module accepts. What the datetime module accepts is irrelevant here. Note that functions affected by accept2dyear are: time.mktime(), time.asctime(), time.strftime() and indirectly time.ctime(). Neither of them produces result that is directly usable by the datetime module. Furthermore, this thread started with me arguing that year should raise ValueError and if we wanted to restrict time module functions to datetime-supported year range, that would be the right thing to do. If I understand your garbage in garbage out principle correctly, time-processig functions should not introduce arbitrary limits unless there is a specific reason for them. In datetime module, calendar calculations would be too complicated if we had to support date range that does not fit in 32-bit integer. There is no such consideration in the time module, so we should support whatever the underlying system can. This said, I would be perfectly happy with just changing y = 1900 to y = 1000. Doing so will spare us from making a choice between '0012', '12' and ' 12' in time.asctime(). Time-series that extend back to 19th century are not unheard of and in many places modern calendar was already in use back then. Anything prior to year 1000 would certainly require a custom calendar module anyways. ___ 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-checkins] devguide: Start a doc on running and writing unit tests.
On Wed, 05 Jan 2011 17:43:32 -0500 Terry Reedy tjre...@udel.edu wrote: Not on Windows. C:\Programs\Python32./python -m test '.' is not recognized as an internal or external command, operable program or batch file. python -m test works (until it failed, separate issue). This will not run the right interpreter, unless this is an installed build. You must use: - PCbuild\python_d.exe in debug mode - PCbuild\python.exe in release mode - PCbuild\amd64\python_d.exe in 64-bit debug mode - PCbuild\amd64\python.exe in 64-bit release mode I would like to know, insofar as possible, how to run tests from the interpreter prompt (or IDLE simulation thereof) You can't. There is no such supported thing. Regards Antoine. ___ 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-checkins] devguide: Start a doc on running and writing unit tests.
+Running +--- Is there a way to skip a particular test, such as one that crashes the test process? Terry ___ 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] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 2:55 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Jan 5, 2011 at 4:33 PM, Guido van Rossum gu...@python.org wrote: .. Why = 1? Because that's what the datetime module accepts. What the datetime module accepts is irrelevant here. Not completely -- they are both about dates and times, there are some links between them (time tuples are used by both), both have a strftime() method. If they both impose some arbitrary limits, it would be easier for users to remember the limits if they were the same for both modules. (In fact datetime.strftime() is currently limited by what time.strftime() can handle -- more linkage.) Note that functions affected by accept2dyear are: time.mktime(), time.asctime(), time.strftime() and indirectly time.ctime(). Neither of them produces result that is directly usable by the datetime module. But the latter calls strftime() -- although never with a 2d year of course. Furthermore, this thread started with me arguing that year should raise ValueError and if we wanted to restrict time module functions to datetime-supported year range, that would be the right thing to do. I'd be fine with a ValueError too, if that's what it takes to align the two modules better. If I understand your garbage in garbage out principle correctly, time-processig functions should not introduce arbitrary limits unless there is a specific reason for them. In datetime module, calendar calculations would be too complicated if we had to support date range that does not fit in 32-bit integer. There is no such consideration in the time module, so we should support whatever the underlying system can. (Except that the *originally* underlying system, libc, was too poorly standardized and too buggy on some platforms, so we have ended up reimplementing more and more of it.) This said, I would be perfectly happy with just changing y = 1900 to y = 1000. Doing so will spare us from making a choice between '0012', '12' and ' 12' in time.asctime(). Time-series that extend back to 19th century are not unheard of and in many places modern calendar was already in use back then. Anything prior to year 1000 would certainly require a custom calendar module anyways. Yeah, but datetime takes a position here (arbitrarily extending the Gregorian calendar all the way back to the year 1, and forward to the year ). I'd be happiest if time took the same position. For example it would fix the problem that datetime accepts years 1900 but then you cannot call strftime() on those. -- --Guido van Rossum (python.org/~guido) ___ 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-checkins] devguide: Start a doc on running and writing unit tests.
On Wed, Jan 5, 2011 at 17:00, Terry Reedy tjre...@udel.edu wrote:
+Running
+---
Is there a way to skip a particular test, such as one that crashes the test
process?
-x {list of tests to skip}
___
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-checkins] devguide: Start a doc on running and writing unit tests.
On Wed, 05 Jan 2011 18:00:18 -0500 Terry Reedy tjre...@udel.edu wrote: +Running +--- Is there a way to skip a particular test, such as one that crashes the test process? -x test_foo ___ 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-checkins] devguide: Start a doc on running and writing unit tests.
On Jan 5, 2011 4:45 PM, Terry Reedy tjre...@udel.edu wrote: +The shortest, simplest way of running the test suite is:: + +./python -m test Not on Windows. C:\Programs\Python32./python -m test '.' is not recognized as an internal or external command, operable program or batch file. python -m test works (until it failed, separate issue). I would like to know, insofar as possible, how to run tests from the interpreter prompt (or IDLE simulation thereof) from whatmod import whatfunc; whatfunc() # ?? ditto for such remaining alternatives you give as can be made from prompt. Besides the convenience for Windows users (for whom the Command Prompt window is hidden away and possibly unknown), I think we should know if any tests are incompatible with interactive mode. --- Terry Jan Reedy The command prompt on Windows is no more hidden than it is on any other OS. In fact it's easier to find than on OS X (IMO) :) I think we do need to make *some* assumptions in the developer docs that the reader is actually a developer (who would know where cmd is) and not a first-time user of the OS, otherwise it becomes a computer users guide and not a development guide. ___ 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] 3.2b2 fails test suite on (my) Windows XP
To test Brett's test running instruction, I ran python -m test # not ./Python! in a Command Prompt window --- Microsoft Windows XP [Version 5.1.2600] == CPython 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)] == Windows-XP-5.1.2600-SP3 little-endian == c:\docume~1\terry\locals~1\temp\test_python_3528 [ 1/351] test_grammar ... [ 10/351] test___all__ Warning -- os.environ was modified by test___all__ [ 11/351] test___future__ ... [ 37/351] test_capi Window hangs, can only close. Error popup says python.exe has encountered a problem... at 000a03f7 in python32.dll RUN 2, same command, I get [ 37/351] test_capi test test_capi failed -- Traceback (most recent call last): File C:\Programs\Python32\lib\test\test_capi.py, line 50, in test_no_FatalEr ror_infinite_loop b'Fatal Python error:' AssertionError: bFatal Python error: PyThreadState_Get: no current thread\r\n\r \nThis application has requested the Runtime to terminate it in an unusual way.\ nPlease contact the application's support team for more information. != b'Fatal Python error: PyThreadState_Get: no current thread' and it continued on with test_cfgparser, etc, so crashing rather than mere failure is intermitant. BUT process then stopped (hung, no error popup) at [ 67/351] test_concurrent_futures Traceback (most recent call last): File string, line 1, in module File C:\Programs\Python32\lib\multiprocessing\forking.py, line 369, in main prepare(preparation_data) File C:\Programs\Python32\lib\multiprocessing\forking.py, line 477, in prepa re assert main_name not in sys.modules, main_name AssertionError: __main__ RUN 3 python -m test -x test_capi test_concurrent_futures went further, more failed tests, then process started repeatedly (hundred of times) outputting assert main_name not in sys.modules, main_name AssertionError: __main__ Traceback (most recent call last): File string, line 1, in module File C:\Programs\Python32\lib\multiprocessing\forking.py, line 369, in main prepare(preparation_data) File C:\Programs\Python32\lib\multiprocessing\forking.py, line 477, Occasionally a new test would start in between this stuff. It ended with test_sax. I cannot say when it began because the volume overfilled the output buffer. [306/349] test_ttk_guionly # and test_tk test_ttk_guionly skipped -- ttk not available: Can't find a usable init.tcl in t he following directories: C:/Programs/Python32/lib/tcl8.5 C:/Programs/lib/tcl8.5 C:/lib/tcl8.5 C:/Prog rams/library C:/library C:/tcl8.5.9/library C:/tcl8.5.9/library This probably means that Tcl wasn't installed properly. Funny, IDLE works fine. In any case, I did a standard install from the distributed installer. Something is definitely not ready for final release. The final mishmash: [349/349] test_zlib 295 tests OK. 11 tests failed: test_datetime test_difflib.bak test_ftplib test_lib2to3 test_multiprocessing test_os.bak test_pep277 test_pkgutil test_posixpath test_runpy test_tcl 2 tests altered the execution environment: test___all__ test_site 41 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue test_largefile test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_smtpnet test_socketserver test_syslog test_threadsignals test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_wait3 test_wait4 test_winsound test_xmlrpc_net test_zipfile64 4 skips unexpected on win32: test_gdb test_readline test_tk test_ttk_guionly Traceback (most recent call last): File C:\Programs\Python32\lib\test\support.py, line 468, in temp_cwd yield os.getcwd() File C:\Programs\Python32\lib\test\__main__.py, line 13, in module regrtest.main() File C:\Programs\Python32\lib\test\regrtest.py, line 704, in main sys.exit(len(bad) 0 or interrupted) SystemExit: True During handling of the above exception, another exception occurred: Traceback (most recent call last): File C:\Programs\Python32\lib\runpy.py, line 160, in _run_module_as_main __main__, fname, loader, pkg_name) File C:\Programs\Python32\lib\runpy.py, line 73, in _run_code exec(code, run_globals) File C:\Programs\Python32\lib\test\__main__.py, line 13, in module regrtest.main() File C:\Programs\Python32\lib\contextlib.py, line 46, in __exit__ self.gen.throw(type, value, traceback) File C:\Programs\Python32\lib\test\support.py, line 472, in temp_cwd rmtree(name) File C:\Programs\Python32\lib\test\support.py, line 198, in rmtree shutil.rmtree(path) File C:\Programs\Python32\lib\shutil.py, line 287, in rmtree onerror(os.rmdir, path, sys.exc_info()) File C:\Programs\Python32\lib\shutil.py, line 285, in rmtree
Re: [Python-Dev] 3.2b2 fails test suite on (my) Windows XP
On Wed, Jan 5, 2011 at 17:47, Terry Reedy tjre...@udel.edu wrote: To test Brett's test running instruction, I ran python -m test # not ./Python! in a Command Prompt window --- Microsoft Windows XP [Version 5.1.2600] == CPython 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)] == Windows-XP-5.1.2600-SP3 little-endian == c:\docume~1\terry\locals~1\temp\test_python_3528 [ 1/351] test_grammar ... [ 10/351] test___all__ Warning -- os.environ was modified by test___all__ [ 11/351] test___future__ ... [ 37/351] test_capi Window hangs, can only close. Error popup says python.exe has encountered a problem... at 000a03f7 in python32.dll RUN 2, same command, I get [ 37/351] test_capi test test_capi failed -- Traceback (most recent call last): File C:\Programs\Python32\lib\test\test_capi.py, line 50, in test_no_FatalEr ror_infinite_loop b'Fatal Python error:' AssertionError: bFatal Python error: PyThreadState_Get: no current thread\r\n\r \nThis application has requested the Runtime to terminate it in an unusual way.\ nPlease contact the application's support team for more information. != b'Fatal Python error: PyThreadState_Get: no current thread' and it continued on with test_cfgparser, etc, so crashing rather than mere failure is intermitant. BUT process then stopped (hung, no error popup) at [ 67/351] test_concurrent_futures Traceback (most recent call last): File string, line 1, in module File C:\Programs\Python32\lib\multiprocessing\forking.py, line 369, in main prepare(preparation_data) File C:\Programs\Python32\lib\multiprocessing\forking.py, line 477, in prepa re assert main_name not in sys.modules, main_name AssertionError: __main__ RUN 3 python -m test -x test_capi test_concurrent_futures went further, more failed tests, then process started repeatedly (hundred of times) outputting assert main_name not in sys.modules, main_name AssertionError: __main__ Traceback (most recent call last): File string, line 1, in module File C:\Programs\Python32\lib\multiprocessing\forking.py, line 369, in main prepare(preparation_data) File C:\Programs\Python32\lib\multiprocessing\forking.py, line 477, Occasionally a new test would start in between this stuff. It ended with test_sax. I cannot say when it began because the volume overfilled the output buffer. [306/349] test_ttk_guionly # and test_tk test_ttk_guionly skipped -- ttk not available: Can't find a usable init.tcl in t he following directories: C:/Programs/Python32/lib/tcl8.5 C:/Programs/lib/tcl8.5 C:/lib/tcl8.5 C:/Prog rams/library C:/library C:/tcl8.5.9/library C:/tcl8.5.9/library This probably means that Tcl wasn't installed properly. Funny, IDLE works fine. In any case, I did a standard install from the distributed installer. Something is definitely not ready for final release. The final mishmash: [349/349] test_zlib 295 tests OK. 11 tests failed: test_datetime test_difflib.bak test_ftplib test_lib2to3 test_multiprocessing test_os.bak test_pep277 test_pkgutil test_posixpath test_runpy test_tcl 2 tests altered the execution environment: test___all__ test_site 41 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue test_largefile test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_smtpnet test_socketserver test_syslog test_threadsignals test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_wait3 test_wait4 test_winsound test_xmlrpc_net test_zipfile64 4 skips unexpected on win32: test_gdb test_readline test_tk test_ttk_guionly Traceback (most recent call last): File C:\Programs\Python32\lib\test\support.py, line 468, in temp_cwd yield os.getcwd() File C:\Programs\Python32\lib\test\__main__.py, line 13, in module regrtest.main() File C:\Programs\Python32\lib\test\regrtest.py, line 704, in main sys.exit(len(bad) 0 or interrupted) SystemExit: True During handling of the above exception, another exception occurred: Traceback (most recent call last): File C:\Programs\Python32\lib\runpy.py, line 160, in _run_module_as_main __main__, fname, loader, pkg_name) File C:\Programs\Python32\lib\runpy.py, line 73, in _run_code exec(code, run_globals) File C:\Programs\Python32\lib\test\__main__.py, line 13, in module regrtest.main() File C:\Programs\Python32\lib\contextlib.py, line 46, in __exit__ self.gen.throw(type, value, traceback) File C:\Programs\Python32\lib\test\support.py, line 472, in temp_cwd rmtree(name) File C:\Programs\Python32\lib\test\support.py, line 198, in rmtree shutil.rmtree(path) File C:\Programs\Python32\lib\shutil.py, line 287, in
Re: [Python-Dev] 3.2b2 fails test suite on (my) Windows XP
On Wed, Jan 5, 2011 at 17:56, Brian Curtin brian.cur...@gmail.com wrote: On Wed, Jan 5, 2011 at 17:47, Terry Reedy tjre...@udel.edu wrote: To test Brett's test running instruction, I ran python -m test # not ./Python! in a Command Prompt window --- Microsoft Windows XP [Version 5.1.2600] == CPython 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)] == Windows-XP-5.1.2600-SP3 little-endian == c:\docume~1\terry\locals~1\temp\test_python_3528 [ 1/351] test_grammar ... [ 10/351] test___all__ Warning -- os.environ was modified by test___all__ [ 11/351] test___future__ ... [ 37/351] test_capi Window hangs, can only close. Error popup says python.exe has encountered a problem... at 000a03f7 in python32.dll RUN 2, same command, I get [ 37/351] test_capi test test_capi failed -- Traceback (most recent call last): File C:\Programs\Python32\lib\test\test_capi.py, line 50, in test_no_FatalEr ror_infinite_loop b'Fatal Python error:' AssertionError: bFatal Python error: PyThreadState_Get: no current thread\r\n\r \nThis application has requested the Runtime to terminate it in an unusual way.\ nPlease contact the application's support team for more information. != b'Fatal Python error: PyThreadState_Get: no current thread' and it continued on with test_cfgparser, etc, so crashing rather than mere failure is intermitant. BUT process then stopped (hung, no error popup) at [ 67/351] test_concurrent_futures Traceback (most recent call last): File string, line 1, in module File C:\Programs\Python32\lib\multiprocessing\forking.py, line 369, in main prepare(preparation_data) File C:\Programs\Python32\lib\multiprocessing\forking.py, line 477, in prepa re assert main_name not in sys.modules, main_name AssertionError: __main__ RUN 3 python -m test -x test_capi test_concurrent_futures went further, more failed tests, then process started repeatedly (hundred of times) outputting assert main_name not in sys.modules, main_name AssertionError: __main__ Traceback (most recent call last): File string, line 1, in module File C:\Programs\Python32\lib\multiprocessing\forking.py, line 369, in main prepare(preparation_data) File C:\Programs\Python32\lib\multiprocessing\forking.py, line 477, Occasionally a new test would start in between this stuff. It ended with test_sax. I cannot say when it began because the volume overfilled the output buffer. [306/349] test_ttk_guionly # and test_tk test_ttk_guionly skipped -- ttk not available: Can't find a usable init.tcl in t he following directories: C:/Programs/Python32/lib/tcl8.5 C:/Programs/lib/tcl8.5 C:/lib/tcl8.5 C:/Prog rams/library C:/library C:/tcl8.5.9/library C:/tcl8.5.9/library This probably means that Tcl wasn't installed properly. Funny, IDLE works fine. In any case, I did a standard install from the distributed installer. Something is definitely not ready for final release. The final mishmash: [349/349] test_zlib 295 tests OK. 11 tests failed: test_datetime test_difflib.bak test_ftplib test_lib2to3 test_multiprocessing test_os.bak test_pep277 test_pkgutil test_posixpath test_runpy test_tcl 2 tests altered the execution environment: test___all__ test_site 41 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue test_largefile test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_smtpnet test_socketserver test_syslog test_threadsignals test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_wait3 test_wait4 test_winsound test_xmlrpc_net test_zipfile64 4 skips unexpected on win32: test_gdb test_readline test_tk test_ttk_guionly Traceback (most recent call last): File C:\Programs\Python32\lib\test\support.py, line 468, in temp_cwd yield os.getcwd() File C:\Programs\Python32\lib\test\__main__.py, line 13, in module regrtest.main() File C:\Programs\Python32\lib\test\regrtest.py, line 704, in main sys.exit(len(bad) 0 or interrupted) SystemExit: True During handling of the above exception, another exception occurred: Traceback (most recent call last): File C:\Programs\Python32\lib\runpy.py, line 160, in _run_module_as_main __main__, fname, loader, pkg_name) File C:\Programs\Python32\lib\runpy.py, line 73, in _run_code exec(code, run_globals) File C:\Programs\Python32\lib\test\__main__.py, line 13, in module regrtest.main() File C:\Programs\Python32\lib\contextlib.py, line 46, in __exit__ self.gen.throw(type, value, traceback) File C:\Programs\Python32\lib\test\support.py, line 472, in temp_cwd rmtree(name) File C:\Programs\Python32\lib\test\support.py, line 198, in rmtree
Re: [Python-Dev] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 6:12 PM, Guido van Rossum gu...@python.org wrote: .. If they both impose some arbitrary limits, it would be easier for users to remember the limits if they were the same for both modules. Unfortunately, that is not possible on 32-bit systems where range supported by say time.ctime() is limited by the range of time_t. (In fact datetime.strftime() is currently limited by what time.strftime() can handle -- more linkage.) Not really. There is a patch at http://bugs.python.org/issue1777412 that removes this limit for datetime.strftime. There is an issue for pure python implementation that does depend on time.strftime(), but that can be addressed in several ways including ignoring it until time modules is fixed. .. Furthermore, this thread started with me arguing that year should raise ValueError and if we wanted to restrict time module functions to datetime-supported year range, that would be the right thing to do. I'd be fine with a ValueError too, if that's what it takes to align the two modules better. Do you want to *add* year range checks to say time.localtime(t) so that it would not produce time tuple with out of range year? IMO, range checks are justified when they allow simpler implementation. As far as users are concerned, I don't think anyone would care about precise limits if they are wider than [1000 - ]. .. This said, I would be perfectly happy with just changing y = 1900 to y = 1000. Doing so will spare us from making a choice between '0012', '12' and ' 12' in time.asctime(). Time-series that extend back to 19th century are not unheard of and in many places modern calendar was already in use back then. Anything prior to year 1000 would certainly require a custom calendar module anyways. Yeah, but datetime takes a position here (arbitrarily extending the Gregorian calendar all the way back to the year 1, and forward to the year ). I'd be happiest if time took the same position. Doesn't it already? On my system, $ cal 9 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 but (datetime(1752, 9, 2) - datetime(1970,1,1))//timedelta(0, 1) -6858259200 time.gmtime(-6858259200)[:3] (1752, 9, 2) datetime(1752, 9, 2).weekday() 5 time.gmtime(-6858259200).tm_wday 5 ___ 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] 3.2b2 fails test suite on (my) Windows XP
On Thu, Jan 6, 2011 at 9:47 AM, Terry Reedy tjre...@udel.edu wrote: To test Brett's test running instruction, I ran python -m test # not ./Python! in a Command Prompt window Does it behave itself if you add -x test_capi to the command line? Cheers, Nick. -- 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
Re: [Python-Dev] Checking input range in time.asctime and time.ctime
I'm sorry, but at this point I'm totally confused about what you're asking or proposing. You keep referring to various implementation details and behaviors. Maybe if you summarized how the latest implementation (say python 3.2) works and what you propose to change that would be quicker than this back-and-forth about whether or not datetime and time behave the same or should behave the same or whatever. -- --Guido van Rossum (python.org/~guido) ___ 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-checkins] devguide: Add a note about a possible starter project.
On Thu, Jan 6, 2011 at 8:11 AM, brett.cannon python-check...@python.org wrote: +.. todo:: + See if tempfile or test.support has a context manager that creates and + deletes a temp file so as to move off of test.support.TESTFN. Yeah, tempfile.TemporaryFile and friends all support the CM protocol. There's also the tempfile.TemporaryDirectory CM (as of 3.2). Cheers, Nick. -- 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
Re: [Python-Dev] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 9:18 PM, Guido van Rossum gu...@python.org wrote: I'm sorry, but at this point I'm totally confused about what you're asking or proposing. You keep referring to various implementation details and behaviors. Maybe if you summarized how the latest implementation (say python 3.2) works and what you propose to change I'll try. The current implementation is of time.asctime and time.strftime is roughly if y 1900: if accept2dyear: if 69 = y = 99: y += 1900 elif 0 = y = 68: y += 2000 else: raise ValueError(year out of range) else: raise ValueError(year out of range) # call system function with tm_year = y - 1900 I propose to change that to if y 1000: if accept2dyear: if 69 = y = 99: y += 1900 elif 0 = y = 68: y += 2000 else: raise ValueError(year out of range) # call system function with tm_year = y - 1900 ___ 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] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 6:46 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Jan 5, 2011 at 9:18 PM, Guido van Rossum gu...@python.org wrote: I'm sorry, but at this point I'm totally confused about what you're asking or proposing. You keep referring to various implementation details and behaviors. Maybe if you summarized how the latest implementation (say python 3.2) works and what you propose to change I'll try. The current implementation is of time.asctime and time.strftime is roughly if y 1900: if accept2dyear: if 69 = y = 99: y += 1900 elif 0 = y = 68: y += 2000 else: raise ValueError(year out of range) else: raise ValueError(year out of range) # call system function with tm_year = y - 1900 I propose to change that to if y 1000: if accept2dyear: if 69 = y = 99: y += 1900 elif 0 = y = 68: y += 2000 else: raise ValueError(year out of range) # call system function with tm_year = y - 1900 The new logic doesn't look right, am I right that this is what you meant? if accept2dyear and 0 = y 100: (convert to year = 1970) if y 1000: raise ... But what guarantees do we have that the system functions accept negative values for tm_year on all relevant platforms? The 1000 limit still seems pretty arbitrary to me -- if it's only because you don't want to decide whether to use leading spaces or zeros for numbers shorter than 4 digits, let me propose leading zeros since we use those uniformly for months, days, hours, minutes and seconds 10, and then you can make the year range accepted the same for these as for datetime (i.e. 1 = y = ). Tim Peters picked those at least in part because they are right round numbers... -- --Guido van Rossum (python.org/~guido) ___ 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] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 10:50 PM, Guido van Rossum gu...@python.org wrote: .. I propose to change that to if y 1000: if accept2dyear: if 69 = y = 99: y += 1900 elif 0 = y = 68: y += 2000 else: raise ValueError(year out of range) # call system function with tm_year = y - 1900 The new logic doesn't look right, am I right that this is what you meant? if accept2dyear and 0 = y 100: (convert to year = 1970) if y 1000: raise ... Not quite. My proposed logic would not do any range checking if accept2dyear == 0. But what guarantees do we have that the system functions accept negative values for tm_year on all relevant platforms? I've already committed an implementation of asctime, so time.asctime and time.ctime don't call system functions anymore. This leaves time.mktime and time.strftime. The latter caused Tim Peters to limit year range to = 1900 eight years ago: http://svn.python.org/view?view=revrevision=30224 For these functions, range checks are necessary only when system functions may crash on out of range values. If we can detect error return and convert it to an exception, there is no need to look before you leap. (Note that asctime was different because the relevant standards specifically allowed it to have undefined behavior for out of range values.) I cannot rule out that there are systems out there with buggy strftime, but the situation has improved in the last eight years and we have buildbots and unittests to check behavior on relevant platforms. If we do find a platform with buggy strftime which crashes or produces nonsense with negative tm_year, we can add a platform specific range check to work around platform bug, or just ask users to bug their OS vendor. :-) The 1000 limit still seems pretty arbitrary to me -- if it's only because you don't want to decide whether to use leading spaces or zeros for numbers shorter than 4 digits, let me propose leading zeros since we use those uniformly for months, days, hours, minutes and seconds 10, Except we don't: time.asctime((2000, 1, 1, 0, 0, 0, 0, 0, -1)) 'Sat Jan 1 00:00:00 2000' (note that day is space-filled.) I am not sure, however, what you are proposing here. Are you arguing for a wider or a narrower year range? I would be happy with just if accept2dyear: if 69 = y = 99: y += 1900 elif 0 = y = 68: y += 2000 # call system function with tm_year = y - 1900 but I thought that would be too radical. ___ 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] Checking input range in time.asctime and time.ctime
On Wed, Jan 5, 2011 at 10:50 PM, Guido van Rossum gu...@python.org wrote: .. But what guarantees do we have that the system functions accept negative values for tm_year on all relevant platforms? Also note that the subject of this thread is limited to time.asctime and time.ctime. The other functions came into discussion only because the year range checking code is shared inside the time module. If calling specific system functions such as strftime with tm_year 0 is deemed unsafe, we can move the check to where the system function is called. No system function is called from time.asctime anymore and time.ctime(t) is now time.asctime(localtime(t)). ___ 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-checkins] devguide: Start a doc on running and writing unit tests.
On 1/5/2011 5:57 PM, Antoine Pitrou wrote: On Wed, 05 Jan 2011 17:43:32 -0500 Terry Reedytjre...@udel.edu wrote: Not on Windows. C:\Programs\Python32./python -m test Installation, not checkout. '.' is not recognized as an internal or external command, operable program or batch file. python -m test works (until it failed, separate issue). This will not run the right interpreter, unless this is an installed build. It is, from 32b2.msi. I have no compiler ;-). -- Terry Jan Reedy ___ 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-checkins] r87768 - in python/branches/py3k: Lib/socket.py Lib/test/test_socket.py Misc/NEWS
On 1/5/2011 5:43 PM, Antoine Pitrou wrote: On Wed, 05 Jan 2011 17:21:23 -0500 Terry Reedytjre...@udel.edu wrote: Thank you for spotting the contradiction; this is now fixed. I am following your example of looking at checkins. -- Terry Jan Reedy ___ 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] 3.2b2 fails test suite on (my) Windows XP
On 1/5/2011 8:59 PM, Nick Coghlan wrote:
On Thu, Jan 6, 2011 at 9:47 AM, Terry Reedytjre...@udel.edu wrote:
To test Brett's test running instruction, I ran
python -m test # not ./Python!
in a Command Prompt window
Does it behave itself if you add -x test_capi to the command line?
No, it gets worse. Really.
Let me summarize a long post.
Run 1: normal (as above)
Process stops at capi test with Windows error message.
Close command prompt window with [x] buttom (crtl-whatever had no effect).
Run 2: normal (as before)
Process reported capi test failure (supposedly fatal) but continued.
Process just stopped ('hung') at concurrent futures. Close as before.
Run 3: -x test_capi test_concurrent_futures
Instead of the normal output I expected, I got some of the craziest
stuff I have ever seen. Things like
assert main_name not in sys.modules, main_name
AssertionError: __main__
Traceback (most recent call last):
File string, line 1, in module
File C:\Programs\Python32\lib\multiprocessing\forking.py, line 369,
in main
prepare(preparation_data)
File C:\Programs\Python32\lib\multiprocessing\forking.py, line 477,
were printed 100s of times intermixed with the normal sequential test
startup lines. They stopped after text_sax started and output became
normal through the end of the report.
295 tests OK.
11 tests failed:
test_datetime test_difflib.bak test_ftplib test_lib2to3
test_multiprocessing test_os.bak test_pep277 test_pkgutil
test_posixpath test_runpy test_tcl
2 tests altered the execution environment:
test___all__ test_site
41 tests skipped:
[snip]
4 skips unexpected on win32:
test_gdb test_readline test_tk test_ttk_guionly
(It previously said it could not find tk (or ttk), even though IDLE does
just fine.)
Then chained error craziness during shutdown: SystemExit, WindowsError,
AttributeError, EOFError (details in original post).
I forgot to mention before that test_ftplib runs into Windows security
and pops up a window (which I closed).
If I did not know better, I might have thought python to be a buggy
piece of junk, but my well-tested package-in-progress runs fine (from
IDLE edit window) in 3.2b2, unchanged from 3.1. I think fixing test
regressions should happen before a 'release candidate'.
On same machine (again, installed from Martin's .msi)
C:\Programs\Python31python -m test.regrtest
seems to run 'normally' (same security popup), no craziness (except for
blocked ftplib test), with results
298 tests OK.
3 tests failed:
test_ftplib test_lib2to3 test_tcl
39 tests skipped:
[snip]
2 skips unexpected on win32:
test_tk test_ttk_guionly
test_tcl had multiple errors, tk,ttk skips are from not finding usable
init.tcl
Similar result with 2.7 with addition of test_distutils failure and
'unexpected skips' of test_gbd and test_readline (but I presume these
really should be expected).
--
Terry Jan Reedy
___
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-checkins] devguide: Start a doc on running and writing unit tests.
On Thu, 06 Jan 2011 00:34:11 -0500 python -m test works (until it failed, separate issue). This will not run the right interpreter, unless this is an installed build. It is, from 32b2.msi. I have no compiler ;-). Ah, sorry. For the devguide, however, I recommend assuming an uninstalled up-to-date build, since keeping fresh sources is the most productive way (or the least frustrating) way of contributing. Note that, if you're willing to give it a try, Microsoft Visual Studio Express is a free download (free as in beer). Regards Antoine. ___ 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
