Mailman 3 February 2010 - Python-Dev

Using git to checkout Python
by Neil Schemenauer 24 Feb '10

24 Feb '10

For those interested, I updated my instructions for using the git repositories on svn.python.org. They are now on the Python wiki: http://wiki.python.org/moin/Git Regards, Neil

2 1

'languishing' status for the tracker
by R. David Murray 24 Feb '10

24 Feb '10

I believe Brett mentioned the 'languishing' status for the tracker in passing in his notes from the language summit. To expand on this: the desire for this arises from the observation that we have a lot of bugs in the tracker that we don't want to close, because they are real bugs or non-crazy enhancement requests, but for one reason or another (lack of an interested party, lack of a good, non-controversial solution, lack of a test platform on which to test the bug fix, the fix is hard but the bug is not of a commensurate priority, etc) the issue just isn't getting dealt with, and won't get dealt with until the blocking factor changes. The motivation for introducing a new status, rather than continuing to leave these bugs in 'open' state, is to make it clear which bugs are the *active* bugs, the ones we should be focusing on and working to fix first. This would allow the count of open bugs to be a more meaningful metric than it is currently, and might even allow us to get to a point where the open bug count stops increasing. More importantly, however, it would act as a first level partition of the non-closed bugs, such that the ones for which it is most likely that effective action can be taken will be what appear first. This is especially important for new people coming in to help. How many people have looked at the tracker, and decided to start from the oldest bugs and see what they can fix? I know I started out that way. Looking through those oldest bugs can be quite discouraging, since many of them are old because they are hard, or blocked for one reason or another. We would in addition propose that a 'languishing' search be added to the standard searches. I would also propose that the default search be changed to search all bugs, and group them by status, not priority. This will make it more likely that bug *reporters* will find existing bugs that relate to the problem they are experiencing or the feature they want to propose. The other searches (except open) should probably return languishing issues as well as open, since they sort in reverse chronological order the more active bugs will be at the top, and that way the languishing bugs won't be forgotten. (Note: languishing bugs should probably never have the 'needs review' keyword, since bugs should not be allowd to languish simply for need of a review.) To move a bug to state languishing, the procedure should be to post a comment saying why you are moving the bug to that status, that by implication or explicitly lays out the conditions required for it to move back to open. Doing so may wake someone up who wants to and can deal with the issue, in which case it can be moved back to open. --David PS: I believe that the other change that would be required in addition to adding the new status and search is to alter the bug summary email script to handle the languishing state. If I've missed anything else please let me know.

5 6

Question for you
by Connor, Craig A. 24 Feb '10

24 Feb '10

Hello, Dave; My name is Craig Connor and I am a senior s/w developer at Northrop Grumman. I have a question for you. I have installed Boost (via the Installer), and stored it into my C Drive inside a dir called: C:\boost_1_42 I also installed the Boost Jam into a directory called: C:\boost-jam-3.1.17 I am using 2 separate compilers in my Win OS XP (SP3) and I would like to be able to use the Python module of Boost in order to embed Python.h into my C++ compiler. The C++ compilers that I have are: o Dev-cpp, and o Visual C++.net (of MS Visual Studio.Net 2008). Problem: When I compile a simple program, I keep getting the error: "pyconfig.h: No such file or directory". The program I am trying to start with is (below): #include <iostream> #include<boost/any.hpp> #include<boost/python.hpp> using namespace std; int main( ) { cout << "Hello, Boost World!!" << endl; boost::any a(5); a = 7.67; std::cout<<boost::any_cast<double>(a)<<std::endl; system( "PAUSE" ); return 0; } Also: I did set up my environmental config to go to the Boost dir. Question: Do you know what am I doing wrong? Regards, Craig Connor 720.622.2209

3 2

PEP 385 progress report
by Dirkjan Ochtman 23 Feb '10

23 Feb '10

It's been a long time! So for the past few weeks, Mercurial crew member Patrick Mezard has been hunting for the ugly bug in hgsubversion that I'd previously been looking at, and it finally got fixed. A new bug popped up, but then we managed to fix that, too (thanks to the PSF for partially funding our sprint, it was very succesful!). In a joyous moment, I nagged Augie Fackler to actually put a hgsubversion release out there so hopefully more people can start using it, so we now have that, too. Another sponsor for our sprint was Logilab (who provided their brand new office for us to work in), and one of their employees, Andre Espaze, fortunately wanted to help out and managed to write up a patch for the sys.mercurial attribute (now in the pymigr repo). In fact, a few weeks ago I talked to Brett and we figured that we should probably pin down a deadline. We discussed aiming at May 1, and at this time I think that should be feasible. That also seems to coincide with the release of 2.7b2, though, so maybe we need to do it one week later (or sooner?). Anyway, we figured that a weekend would probably be a good time. If we manage to find a good date, I'll put it in the PEP. As for the current state of The Dreaded EOL Issue, there is an extension which seems to be provide all the needed features, but it appears there are some nasty corner cases still to be fixed. Martin Geisler has been working on it over the sprint, but I think there's more work to be done here. Anyone who wants to jump in would be quite welcome (maybe Martin will clarify here what exactly the remaining issues are). The current version of the repository (latest SVN revision is 78055, clone it from hg.python.org) weighs in at about 1.4G, but still needs branch pruning (which will be my primary focus for the coming few weeks). The good part about it now being a year later than, well, last year is that named branches are much more solid than before, and so I feel much better about using those for Python's release branches. Any questions and/or concerns? I will also be at PyCon; I'll be doing a more advanced talk on Mercurial internals on Sunday but I'd also be happy to do some handholding or introductory stuff in an open space. If there's anyone who'd like help converting their SVN repository, I might be able to help there too (during the sprints). For other conversions, I know for a fact that an expert in CVS conversions will be there. Cheers, Dirkjan

12 50

3.1 and 2.7 break format() when used with complex (sometimes)
by Eric Smith 23 Feb '10

23 Feb '10

This code works on 2.6 and 3.0: >>> format(1+1j, '10s') '(1+1j) ' That's because format ends up calling object.__format__ because complex doesn't have its own __format__. Then object.__format__ calls str(self) which returns '(1+1j) '. So the original call basically turns into "format('(1+1j) ', '10s')". In 3.1 (released) and 2.7 (not yet released) I implemented __format__ on complex. So now that same code is an error: >>> format(1+1j, '10s') Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: Unknown format code 's' for object of type 'complex' That's because complex._format__ doesn't recognize string formatting codes, in particular 's'. There's a general problem that types that sprout __format__ will break existing usages of format() that use some string formatting codes, unless the types recognize string formats in addition to their own. I think we should change the documentation of format() to warn that you should really call str() on the first argument if you're relying on the second argument being a string formatting code. But what to do about 3.1 and 2.7 with respect to complex? I see 2 options: 1. Leave it as-is, such that 3.1 and 2.7 might break some uses of format(complex, str). 2. Modify format to understand 's' and do the conversion itself. But we don't do this for int and float, that's why we added '!s'. I'm sort of leaning toward #1, but I'd like to know if anyone has an opinion. I haven't heard of anyone complaining about this yet; it would only have tripped up people moving from 3.0 -> 3.1, or from 2.6 -> 3.1 who used format (or str.format()) while specifying 's' or some other str-specific format codes. Eric.

1 2

Another mercurial repo
by Tarek Ziadé 23 Feb '10

23 Feb '10

Hello Dirkjan, We are going to start working on a few things in Distutils at Pycon outside the trunk. I was about to start this work in the svn sandbox, but if possible I'd rather have a repo at hg.python.org as well Regards Tarek -- Tarek Ziadé | http://ziade.org

5 20

Mercurial move?
by Frank Wierzbicki 23 Feb '10

23 Feb '10

An advantage of being at PyCon :) We *may* be able to get on mercurial very fast -- since all of the interested parties are here. I'm going to get an svndump now -- the downside to this is whatever anyone checks in during this in between stage would need to get re-checked in after we move. I'll let you know how it goes. -Frank

2 3

small suggestion for a sprint project
by Benjamin Peterson 22 Feb '10

22 Feb '10

Somebody at the sprint looking for a thankless task of drudgery could resolve the current svnmerge queue into the py3k branch. -- Regards, Benjamin

1 0

Mercurial repository for Python benchmarks
by Collin Winter 22 Feb '10

22 Feb '10

Hey Dirkjan, Would it be possible for us to get a Mercurial repository on python.org for the Unladen Swallow benchmarks? Maciej and I would like to move the benchmark suite out of Unladen Swallow and into python.org, where all implementations can share it and contribute to it. PyPy has been adding some benchmarks to their copy of the Unladen benchmarks, and we'd like to have as well, and Mercurial seems to be an ideal solution to this. Thanks, Collin Winter

8 14

some notes from the first part of the lang summit
by Trent Mick 22 Feb '10

22 Feb '10

(http://trentmick.blogspot.com/2010/02/other-python-vms-upcoming-python.html) Note that this was just from the first 15 minutes or so... > > Some quick notes about the coming plans by the "other" Python implementations > from today's Python Language Summit at PyCon 2010: > > - IronPython: > - plan is to do Python 2.7 first, focus for this year > - python 3.2 for the end of next year hopefully > - other work on IDE stuff > - Pynie (i.e. Parrot) -- Allison Randall: > - about 4 major features away from pure Python syntax (did dicts last > night) > - targetting py3k repo and test suite: should be on track for python 3.2 > - Jython: > - plan to target 2.6 (b/c 2to3 depends on 2.6) > - temporarily skip 2.7 and target 3.x (probably 3.2) > - then if 3.x adoption isn't fully there, then go back and add Python 2.7 > - will require JDK 2.7 for Python 3 support (b/c of new support for > dynamic languages) > - PyPy (Holger): > - plan is Benjamin will port to Python 2.7 in the summer > - only have slight deviations from CPython: idea is to merge back with > CPython so don't have deviations. Typcically 1 or 2 line changes in ~25 > modules. > Trent -- Trent Mick trentm at activestate.com http://trentm.com/blog/

9 14