Mailman 3 February 2008 - Python-Dev

Python 2.6 and 3.0
by Barry Warsaw 28 Feb '08

28 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, I've volunteered to be the release manager for Python 2.6 and 3.0. It's been several years since I've RM'd a Python release, and I'm happy to do it again (he says while the medication is still working :). I would like to get the next alpha releases of both versions out before Pycon, so I propose next Friday, February 29 for both. Guido reminded me that we released Python 1.6 and 2.0 together and it makes sense to both of us to do the same for Python 2.6 and 3.0. I don't think it will be that much more work (for me at least :) to release them in lockstep, so I think we should try it. I won't try to sync their pre-release version numbers except at the milestones (e.g. first beta, release candidates, final releases). I propose to change PEP 361 to outline the release schedule for both Python 2.6 and 3.0. I'm hoping we can work out a more definite schedule at Pycon, but for now I want to at least describe the lockstep release schedule and the Feb 29 date. I'd also like for us to consider doing regular monthly releases. Several other FLOSS projects I'm involved with are doing this to very good success. The nice thing is that everyone knows well in advance when the next release is going to happen, and so all developers and users know what to expect and what is needed from them. I'd like to propose that we do a joint release the last Friday of every month. For the alphas, it's basically what's in svn. This gives us some time to experiment with the process out and see if we like it enough to keep it going through the betas and final releases. Comments? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR79ek3EjvBPtnXfVAQJrmQP+KAzy0lSzake2BZsVxErD0kpFQJM+Iij0 qN86wjH0NoqARMfYKVA6eUzEY8vZPu7sJl+SjCOmhnE/KP+l/ArOdis5smiSKwQI klL4XKd/qdorTMqQ9mWgA0DeBb0Asvln9y64nxzNqgve+36q9j6ytPuRey1GjSI5 nVWoJDb3WsM= =4SRa -----END PGP SIGNATURE-----

11 31

Adding a new Windows x64 buildbot
by Trent Nelson 28 Feb '08

28 Feb '08

Hi, I've got a Windows Server 2008 x64 server I'd like to contribute as a buildbot. As per the recommendation on http://wiki.python.org/moin/BuildBot, it sounds like I'm looking for Martin, Anthony or Neal to sort me out with slave credentials. Feel free to drop me a line! Regards, Trent.

1 0

hello
by panrui pan 27 Feb '08

27 Feb '08

1 0

Getting a second review on a rewrite of test_logging
by Brett Cannon 27 Feb '08

27 Feb '08

I think over a week ago I applied some GHOP work that turned test_logging into a doctest, but it turns out it is still flaky. Luckily Antoine Pitrou rewrote test_logging using unittest and seems to have made it more sound. But before I replace test_logging again (especially with a more dramatic change) I would like to get a second pair of eyes on the patch as I really don't know the logging package that well. It's issue 1740 (http://bugs.python.org/issue1740). If you happen to know the logging package I would really appreciate it if you could give the patch a look. -Brett

1 0

getpass and stdin
by Shaya Potter 27 Feb '08

27 Feb '08

[please cc me on responses] I was wondering if getpass could be changed to enable piped stdin to work. For instance, the getmail program can read my email password in via stdin using getpass functionality. However, if I do echo password | getmail4 it will fail due to stdin not being a terminal and therefore not being able to do a old = termios.tcgetattr(fd) on it. From what I can tell, the point of this is to only to prevent echoing the password, which isn't a problem in the echo case I give (especially if using bash, then it wont even be on the cmdline when run from a script as it's a builtin, script can also read in the password and store it in memory). currently the code is ----- def unix_getpass(prompt='Password: '): """Prompt for a password, with echo turned off. Restore terminal settings at end. """ try: fd = sys.stdin.fileno() except: return default_getpass(prompt) old = termios.tcgetattr(fd) # a copy to save new = old[:] new[3] = new[3] & ~termios.ECHO # 3 == 'lflags' try: termios.tcsetattr(fd, termios.TCSADRAIN, new) passwd = _raw_input(prompt) finally: termios.tcsetattr(fd, termios.TCSADRAIN, old) sys.stdout.write('\n') return passwd ----- it would seem that if the tcgetattr() line is moved into the initial try, my echo case would work as expected (as it would fail, but be caught and then just run default_getpass() (which should just read it from stdin). Is there any reason not to do it this way?

4 10

February bug day outcome
by A.M. Kuchling 26 Feb '08

26 Feb '08

Yesterday's bug day was another success, closing 48 issues. Several committers were there: Facundo Bastista, Georg Brandl, and Christian Heimes. Facundo organized a local group of participants, and we committed a number of contributions from new people. Should we have one next month? The PyCon sprint will fall on Monday through Thursday, and few people not at PyCon will be available during the work week. OTOH, if we scheduled a bug day for the 29th, that's two weeks after the conference, and we may have recovered from our PyCon burnout at that point. What do people think? --amk

5 10

optimizing out local variables
by Neal Norwitz 25 Feb '08

25 Feb '08

Short description (see http://bugs.python.org/issue2181 for the patch and more details): Optimize code like: x = any_expression return x to: return any_expression The local variable x is no longer set before returning. Is this appropriate for .pyc generation or should it only be done for .pyo files? n

5 4

Backporting PEP 3127 to trunk
by Eric Smith 25 Feb '08

25 Feb '08

I'm going to work on backporting PEP 3127, specifically the hex, oct(), and bin() builtins. I have bin() completed, and I'll check it in shortly. oct() will require a future import. Does anyone have any pointers for implementing this? I understand (and have completed) adding the future import, but what I don't understand is how to modify the behavior of oct() for only the module where the future import is execute. Any rough ideas or pointers to existing code that does something similar would be helpful. I also need a name for the future import statement. Also, I notice in py3k that __hex__ and __oct__ have vanished, and instead hex() and oct() just uses the __index__ machinery to produce a number, then converts that to a string. So I'm thinking that maybe we could use the same future import statement that controls oct()'s behavior to also switch hex() and oct() to the py3k behavior. Or, maybe we should use a different future import? Or, I guess, not do this at all. But I think it's a good idea. I guess another issue is changing hex()'s behavior of adding a trailing L for longs. I don't really see the value in this, and maybe it should also change with a future import statement. For bin(), I just used the py3k behavior, and didn't implement a __bin__ method. I'm also not adding a trailing L for longs. I think that makes the most sense. Eric.

5 16

Proposed revision of PEP 3 (using the issue tracker)
by Nick Coghlan 25 Feb '08

25 Feb '08

I've attached a proposed revision of PEP 3 below. Feedback would be appreciated, and once we have a reasonable consensus that it accurately describes our current processes I can check it in and Martin can update the tracker to reflect any changes. It is intentional that the current non-resolution resolutions like 'later' are missing - I think those should definitely be retired. I also left out the 'compile error' type - I would prefer to see the Compiler added to the Components list so we can attach feature requests to it as well as bugs. One question I did have is whether or not access to 'security' type issues is automatically limited to a small subset of the developers. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org PEP: 3 Title: Guidelines for Handling Tracker Issues Version: $Revision: 59412 $ Last-Modified: $Date: 2007-12-08 20:48:07 +1000 (Sat, 08 Dec 2007) $ Author: jeremy(a)alum.mit.edu (Jeremy Hylton), ncoghlan(a)gmail.com (Nick Coghlan) Status: Active Type: Process Content-Type: text/x-rst Created: 25-Sep-2000 Post-History: 23-Feb-2008 Introduction ============ This PEP contains guidelines for handling bug reports and feature requests for the Python project using the tracker at bugs.python.org [1]. These are guidelines for the developers of Python, not the submitters of bugs. Those are included as part of the documentation so they are available in the offline documentation as well as being available online [2]. Tracker Issues ============== All bug reports and feature requests are handled as issues in the tracker. Whether they are bugs or requests for new features is indicated by the type of issue. Title ----- This should be a short description of the problem or request. It is worth correcting it if the originator's title turns out to be misleading. Type ---- This attribute describes the kind of issue being reported. It should be adjusted if the originator has not set it correctly. The possible issue types are: *feature request* the issue is not a bug, but a request for additional functionality *behavior* this covers most bugs (including all documentation bugs), where the behaviour is not desirable or not what the user expected *crash* a bug that causes the Python interpreter to crash (segfault/access violation/bus error) *resource usage* a bug that causes Python to handle limited resources (memory, file handles, etc) poorly *security* a bug that may allow the Python interpreter to be used to gain unauthorised access to information in memory or on the file system (either locally or remotely) (XXX: is public access to security bugs limited by default?) Severity -------- This attribute allows the originator to indicate how important the issue is to them. It should not be adjusted (set the Priority instead). Components ---------- The originator and developers can use the components list to indicate which areas of Python or its development tools are affected by the issue. Eventually developers will be able to subscribe to the tracker so that it automatically adds them to the nosy list when issues are registered against components they are interested in. For discrepancies between the documentation and the actual behavior, the components list should be updated if the problem is determined to be an error in the documentation (and vice-versa if the issue was originally reported as a documentation problem, but it is later determined that the documentation accurately describes the desired behavior). Versions -------- This field is primarily of importance for bug reports - it should indicate which versions of Python exhibit the problem. Problems which are seen in a development version should also be flagged appropriately (currently Python 2.6 for the trunk and Python 3.0 for the py3k branch). For feature requests this field is used to flag the target version for the feature (following a major version release, all open features should be bumped to target the next version). Status ------ Open issues are still under consideration. Closed issues have been resolved, and the resolution field should indicate their final disposition. Pending issues are intended to be closed soon, but are being held open for a short period to allow time for some other event (e.g. additional details from the originator or a decision on whether or not a fix should be backported to the current maintenance branch). Resolution ---------- For closed and pending issues, indicates how the issue was (or will be) resolved. This field should not be set for open issues. In all cases, a comment should be added when closing the issue to provide additional detail as to the rationale behind the resolution. *accepted* the feature request has been implemented for the next version *rejected* the feature request was either not described clearly enough to be implemented, or is not considered a desirable addition to the language or standard library. *fixed* the reported bug has been fixed for the next version *invalid* the reported bug was either not described clearly enough to be reproduced, or is actually the intended behaviour *works for me* the reported bug could not be replicated by the developers *out of date* the reported bug applies only to versions of Python which are no longer supported, or the bug has already been fixed in all versions where it is possible to fix it (some fixes require new features and hence cannot be backported to maintenance branches) *duplicate* the reported bug or feature request duplicates an existing issue. The existing issue should be listed in the Superseder field and closure comment. Dependencies ------------ A list of other issues which must be addressed before this issue can be addressed. Superseder ---------- A list of other issues which replace this issue. Most commonly used when a new issue is marked as a duplicate of an existing issue, but can also be used to indicate when a big issue is split into multiple smaller issues. Assigned To ----------- The developer with primary responsibility for the issue. Usually this indicate a request to investigate an initial bug report or to review an attached patch for a bug report or feature request. It can also be used by developers to indicate that they intend to address a particular issue. Nosy List --------- A list of users that will be automatically notified of changes to the issue. Modifying or commenting on an issue automatically adds you to the nosy list. Priority -------- Indicates how significant the bug or feature request is from the point of view of the developers. *immediate* critical issue requiring release of an immediate patch. Only likely to be needed for PSF security advisories. *urgent* blocker for release of next version *high* should be fixed for release of next version, but may be delayed at the discretion of the release manager *normal* to be considered for next version, but may be delayed until later if it is not implemented in time *low* the issue is valid, but not likely to cause any problems for anyone Keywords -------- There are a few additional keywords that can be set to aid in performing searches for certain kinds of issue. These keywords are: *64bit* issue is specific to the 64-bit version of Python *easy* issue should be able to be addressed by newcomers to Python development *patch* a patch file has been attached to the issue for review General Guidelines ================== #. Make sure the issue type and components list are correct. If they are correct, it is easier for someone interested in helping to find out, say, what all the open Tkinter bugs are. (In the future, the tracker will allow developers to be automatically added to the nosy list for issues relating to particular components) #. Assign the issue a reasonable priority based on the description above. #. If a bug report doesn't have enough information to allow you to reproduce or diagnose it, post a comment asking the originator for more information and set the status to pending, and the resolution to invalid, works for me or out of date (which one makes the most sense will depend on the specific bug) If the originator doesn't respond within a reasonable period of time, the issue can be closed (In the future, pending bug reports will likely be closed automatically after a certain amount of time in that state without any activity on the issue). #. If you fix a bug, set the status to closed and the resolution to fixed. In the comments, include the SVN revision numbers of the commit(s). In the SVN checkin message, include the issue number *and* a normal description of the change, mentioning the contributor if a patch was applied. Don't forget to update Misc/NEWS as well. #. If uncertain whether or not a fix should be backported to the current maintenance branch, set the status to pending and ask on python-dev for advice. Once the fix has been backported (or it has been decided not to backport it), update the issue appropriately and close it. #. For implemented feature requests, the resolution is set to accepted rather than fixed, but they are otherwise handled the same way as for bugs. #. If you are assigned an issue that you are unable to deal with (either through a lack of knowledge or time), assign it to someone else if you think they will be able to deal with it, or else set it to unassigned. Otherwise it will appear that the issue is being handled, when this is not in fact the case. References ========== [1] http://bugs.python.org/ [2] http://docs.python.org/lib/reporting-bugs.html

8 10

Downloads Page
by Michael Foord 25 Feb '08

25 Feb '08

Hello all, The downloads page on python.org shows 2.5.1 as the latest release: http://python.org/download/ Michael

2 1