Mailman 3 February 2009 - Python-Dev

Tkinter problem in Python 3
by Klaus Müller Feb. 21, 2009

Feb. 21, 2009

Hi! I am the lead developer of SimPy (http://simpy.sourceforge.net) . Currently, I am porting SimPy to Python 3. SimPy provides Tk/Tkinter-based GUI and plot facilities. I find that "import Tkinter" does not work in Python 3, only "import tkinter". What are the changes for Tkinter under Python 3? Thanks for your help! Klaus Müller

3 2

IO implementation: in C and Python?
by Benjamin Peterson Feb. 21, 2009

Feb. 21, 2009

As we prepare to merge the io-c branch, the question has come up [1] about the original Python implementation. Should it just be deleted in favor C version? The wish to maintain the two implementations together has been raised on the basis that Python is easier to experiment on and read (for other vm implementors). Thoughts? http://bugs.python.org/issue4565 -- Regards, Benjamin

13 18

Summary of Python tracker Issues
by Python tracker Feb. 20, 2009

Feb. 20, 2009

ACTIVITY SUMMARY (02/13/09 - 02/20/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2341 open (+55) / 14813 closed (+27) / 17154 total (+82) Open issues with patches: 817 Average duration of open issues: 656 days. Median duration of open issues: 393 days. Open Issues Breakdown open 2315 (+55) pending 26 ( +0) Issues Created Or Reopened (84) … [View More]

2 1

lifting of prohibition against readlines inside a "for line in file" in Py3?
by Mitchell L Model Feb. 19, 2009

Feb. 19, 2009

In Digest Vol. 67, Issue 52 (13 Feb 2009) I pointed out that Python 2's prohibition against performing readlines on a file being iterated over appears to have been lifted in Python 3. I asked if this was intentional and whether it should be add to the "What's New" documentation. I also expressed muy surprise that "for line in fil"'s can be nested using the same fil in both Python 2 and 3. I presented an example for each point and some and further comments. I didn't get any response. Is … [View More]

6 8

Peephole Optimization
by Venkatraman S Feb. 19, 2009

Feb. 19, 2009

Hi, I was looking around possibilities of bytecode optimizations in cpython and was looking at some older bugs. One of them being issue#2499<http://bugs.python.org/issue2499>; the following line kind of confuses me and wasnt sure what exactly Raymond(et al) is planning, as i presume that bytecode optimizations are much _easier_ than optimizations in AST. "Most of the peepholer is going to be migrated up the chain, after the AST is generated, but before the opcodes are generated." If … [View More]

3 2

a nicer looking dir()
by Mike Klaas Feb. 19, 2009

Feb. 19, 2009

Someone has implemented a version of dir() which is much nicer for human consumption. The difference is striking enough that I thought it would be bringing to python-dev's attention. http://github.com/inky/see/tree/master >>> pencil_case = [] >>> dir(pencil_case) ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__delsli ce__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__gets lice__', '__gt__', '__hash__', '__iadd__', … [View More]

1 0

Tracker cleanup roadmap
by Daniel (ajax) Diniz Feb. 18, 2009

Feb. 18, 2009

This is the janitorial plan I mentioned earlier... It's so humongously huge by now that I'm not sure whether I should submit it to e.g. the Python Papers or just print it and set it on fire and run screaming. Fortunately, a tl;dl summary is provided :) Daniel Summary Let's improve the tracker UI to better fit our needs. Then, classify them bugs and separate garbage from real development. Lastly, bug reporters should get a better UI. That's it, any help is welcome. The wall of text … [View More]Developer time constraints are arguably the main bottleneck in handling tickets, which is only a subset of Python development. Optimizing the application of main/core developers' time to Python issues is a no-brainer. Being able to add volunteers to the productive time pool is also very desirable. This document outlines a tentative plan to move towards a better workflow in the Python Tracker. Summary of tracker issues The Python Tracker contains more than 17000 tickets, with approximately 2350 still open. Of the open tickets, 500 were last updated more than a year ago, while about 1150 were created before that. Current problems Core developers, volunteers and newcomers are burdened with a lot of inefficient and/or nonproductive chores when handling issues. Requesting and waiting for feedback/confirmation/patch testing, performing multiple searches, missing relevant discussion in similar/duplicated issues and other low-level tasks and gotchas get in the way of solving real problems. The low signal/noise ratio of open issues is a major component of this burden. At least 850 issues have outdated/missing version information, while about 850 don't have a type (RFE, behavior, crash) set. About 800 issues have patches. Priorities carry little information, mostly because they are left in the default setting: 1200 issues are set to 'normal' (a SF.net artifact) and 750 have no priority (a Roundup artifact). Less than 200 tickets have 'low' priority. Most of these issues boil down to tracker features being underused. Another relevant time-sink consists of inadequacies of the current interface. Many search features are hard to use or notice, among them date spans and entering multiple inputs as lists. Other search features are lacking, mostly simple boolean relations, e.g. those including more than one keyword, full search terms, type, component, etc. Besides searching, the lack of interfaces (and backend support) for selecting and working with multiple issues tends to waste considerable amounts of time. Proposed plan The suggested approach consists of a three parts effort focusing first on developer-side tracker UI, then on massive issue categorization and lastly on user-side UI. This optimizes the work of a single tracker janitorveloper, but can be better partitioned if more janitorvelopers are available. The developer-side UI effort will focus, in this order, on making available tracker features easier to use, adding new search features and mass-handling of issues. This should improve both developers' and tracker janitors' workflow. Issue categorization will look like this last Bug Season (adding details to tickets), but hopefully with a saner workflow. There are a few clear sets of similar issues, e.g. about socket, handling of characters on network protocol and format parsing modules, Tkinter + IDLE, etc., that could use grouping and closing of duplicates. A suggested form of grouping would be 'umbrella' or 'grab-bag' issues, with existing issues of a topic as dependencies. Finally, bug-reporter UI. The idea is to make it easier for users to provide good bug reports, make the options clearer and minimize the need for (preliminary) issue post-processing by developers. This might include a template or wizard for reports, adding information about which versions receive fixes or RFE, etc. Deliverables (WIP) Developer-side UI Patches for client-side Roundup: - add missing fields/options to search (e.g. Stages, fix 'not closed') - allow multiple choices for versions, components and keywords - add checkboxes to multiselects - avoid drop-downs above multiselects (janitors misclick a lot!) - support for mass-selection/display (3rd party patch available) - add a clutter-free 'search in all issues' button Patches for server-side Roundup: - boolean searches - support for mass-updates (3rd party patch available) - maybe add regex support (3rd party patch available) Issue categorization - present better statistics about the open issues - maybe add grab-bag issues (3rd party patch available) - assorted closing, updating and poking old issues User-side interface Patches for client-side Roundup: - inline help for fields in issue creation - adapt current docs (and Brett's guide) for easy access during reporting Patches for server-side Roundup: - maybe add a wizard for filling bugs (3rd party patch available) Timeline TBD, first part should definitely be done before PyCon, how much of second part can be done for PyCon and 2.7/3.1 is hard to predict without more specific goals in this area. Conclusion TBD, should learn to write shorter, clear messages :/ [View Less]

5 6

Re: [Python-Dev] To 3.0.2 or not to 3.0.2?
by Lennart Regebro Feb. 18, 2009

Feb. 18, 2009

On Tue, Feb 17, 2009 at 00:50, Guido van Rossum <guido(a)python.org> wrote: > Can you explain the difficulty with porting setuptools in more detail? Oh, it just exposes a bug in distutils. It probably means I'll have to make a test for python version, and if it is 3.0.1, monkey-patch distutils. I haven't really looked into if there is any other possibilities yet, I'm concentrating to make it run for 3.1 trunk first. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://… [View More]

10 14

Re: [Python-Dev] lifting of prohibition against readlines inside a "for line in file" in Py3?
by Leif Walsh Feb. 18, 2009

Feb. 18, 2009

On Wed, Feb 18, 2009 at 12:42 PM, Mitchell L Model <MLMLists(a)comcast.net> wrote: > I'd appreciate comments -- especially a redirection to a different list, if > this one isn't appropriate for my query. It seems as though you have the right list, but perhaps whoever knows about the change is busy, or maybe several people that don't know about the change are trying to find it. If there's something in particular that you need answered in a specific timeframe, I don't know what to … [View More]

1 0

Python 2.6.2 and 3.0.2
by Barry Warsaw Feb. 18, 2009

Feb. 18, 2009

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thinking again about 3.0.2. If we'd like to do bug fix releases before Pycon, I suggest Monday March 9th for code freeze and tagging. That would mean a Tuesday March 10th release. What do you think? Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSZsbpHEjvBPtnXfVAQK5xgP/XIKmhKSbQLQ4rZvknkhDTel6R8w14/7Z lThGtuFJd3eKE4EOO3CP/zT8LT0rHTRkF1wGUZjyNoLW6bIQkGiTQYWxOsTV+Z7z Ak49VzUpf0KySd4Nwtzn/KxQ+z/… [View More]

2 2