Mailman 3 July 2010 - Python-Dev

Mercurial migration readiness (was: Taking over the Mercurial Migration)
by anatoly techtonik July 7, 2010

July 7, 2010

After reading PEP 384 and PEP 385 (finally) I got a strong impression that they are not ready for the change (read below the line for details), because they do not propose any workflow. So, instead of rushing with migration I'd like to propose incremental change rather than revolutionary that will allow people to taste what it like to work with Mercurial and update all relevant papers on the website. I propose to setup workflow that will include pulling changes to Mercurial master clone from current Subversion repository and pushing them back to Subversion using Mercurial. This will be similar to http://mercurial.selenic.com/wiki/DeveloperRepos scheme, but with hg-stable replaced with svn. I am willing to collaborate for getting this system in place before EuroPython even if I won't find a chance to get there. --- the line --- I didn' t have time to follow Mercurial discussion, so I expected PEP 384 and PEP 385 to be exhaustive reference on both the migration and workflow before and after the switch. Unfortunately, both are too vague in this respect and my opinion that migration now will do more harm than good. Primary concern is that will happen with central Subversion repository. There are a plenty of private tools and automated scripts that were written to work with central Subversion repository, so it is important that central Subversion repository continue to operate and be synchronized. However, PEP 385 "The Future of Subversion" [1] does not propose any way to keep Subversion repository in sync. "it will probably live on for a bit" phrase looks like Subversion will be immediately dead after switching. The second concern is workflow. Even after getting my hands dirty I still can't find the best solution for working with Mercurial copy of Python. In Subversion I do shallow checkouts of interesting features when I run into one bug or another. Not all patches are ready, so they stay in those checkouts as uncommitted diffs. To be prepared for conflicts I review code with `svn log -vr base:head` before updating. But with Mercurial I see two major problems with my workflow (which I am unlikely to change for the next few weeks due to heavy automation): 1. No shallow checkouts - that means that I have to copy 200Mb+ for every patch I have 2. No `hg log` command to see changes in my branch from remote repository before fetching them (I used to invoke `hg incoming`, but ended up with fetching everything with `hg pull` and then using `hg log -vr .:tip`, because `hg inc` didn't show changes that were already pulled, but not updated in wc, and `hg log` could not show incoming) 3. There is no clear branch separation in my working copy. I don't know how to diff files in different branches without copying 200Mb+ clone. I don't know how to diff my files with remote repository without pulling it. 4. Even if I make patch in my Mercurial clone - you still can't pull it and I have to attach it to tracker. No gain. So from these PEPs I can't really see how Mercurial solves problems with development. I can feel that it doesn't solve my problems, but I see no way where I can submit my user story. I would put accent on keeping mirror of Subversion as easy way to contribute for those who are not yet ready for DVCS. Subversion also provides greater interoperability. Assuming that any modern DVCS tool may act as Subversion client, we will gain more contributors if we won't try to force people use Python and Mercurial. [1] http://www.python.org/dev/peps/pep-0385/#the-future-of-subversion -- anatoly t.

26 86

blocking 2.7
by Benjamin Peterson July 6, 2010

July 6, 2010

This is just a note that we have one bug blocking 2.7 final at the moment: http://bugs.python.org/issue9144 -- Regards, Benjamin

10 15

[RELEASE] Python 2.7 released
by Benjamin Peterson July 6, 2010

July 6, 2010

On behalf of the Python development team, I'm jocund to announce the second release candidate of Python 2.7. Python 2.7 will be the last major version in the 2.x series. However, it will also have an extended period of bugfix maintenance. 2.7 includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, set literals, dictionary views, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, a new sysconfig module, auto-numbering of fields in the str/unicode format method, and support for ttk Tile in Tkinter. For a more extensive list of changes in 2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python distribution. To download Python 2.7 visit: http://www.python.org/download/releases/2.7/ 2.7 documentation can be found at: http://docs.python.org/2.7/ This is a production release and should be suitable for all libraries and applications. Please report any bugs you find, so they can be fixed in the next maintenance releases. The bug tracker is at: http://bugs.python.org/ Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 2.7's contributors)

5 5

Signs of neglect?
by Steve Holden July 6, 2010

July 6, 2010

I was pretty stunned when I tried this. Remember that the Tools subdirectory is distributed with Windows, so this means we got through almost two releases without anyone realizing that 2to3 does not appear to have touched this code. Yes, I have: http://bugs.python.org/issue9083 When's 3.2 due out? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000

10 10

SVN <-> HG workflow to split Python Library by Module
by anatoly techtonik July 6, 2010

July 6, 2010

I planned to publish this proposal when it is finally ready and tested with an assumption that Subversion repository will be online and up-to-date after Mercurial migration. But recent threads showed that currently there is no tested mechanism to sync Subversion repository back with Mercurial, so it will probably quickly outdate, and the proposal won't have a chance to be evaluated. So now is better than never. So, this is a way to split modules from monolithic Subversion repository into several Mercurial mirrors - one mirror for each module (or whatever directory structure you like). This will allow to concentrate your work on only one module at a time ("distutils", "CGIHTTPServer" etc.) without caring much about anything else. Exceptionally useful for occasional external "contributors" like me, and folks on Windows, who don't possess Visual Studio to compile Python and are forced to use whatever version they have installed to create and test patches. Here is a picture if you feel bored - https://docs.google.com/drawings/edit?id=1c9FDQ27BnaIew_1T7Tr-rFg1OCdPVS9w3… An example of the split distutils module - http://bitbucket.org/techtonik/distutils The split is not perfect, but the process can be polished - it is the first version I managed to get only this morning. More important is that HG repository is incrementally synchronized. The split is not perfect, because in particular I see that documentation dir is not sucked in. But it is a working proof on concept you can test yourself using the code from: http://bitbucket.org/techtonik/python-split You will also need patched version of `hgsvn` from http://bitbucket.org/techtonik/hgsvn How does it work ------------------------- The module is described as a series of paths inside typical Subversion checkout. On the first run `refresh.py` script from `python-split` creates shallow SVN checkout with only required files using distutils.module.def module definition Second run of `refresh.py` imports shallow checkout into Mercurial And the third run imports the rest of the history pulling only changesets relevant to given paths. Workflow ------------- Diagram showed patches that are pulled from local clones of split repositories to master Mercurial mirror, but it won't work this way, because hashes of revisions in direct mirror wont't match hashes in split repositories - that's why some hash lookup/sync procedure is needed to correctly process incoming patches. This workflow works with hash sync only when changes are pushed back to central Subversion repository from local clones (possibly through another intermediate normalizing repository). Changes pushed this way are streamlined and could be downloaded into stable branch of other mirrors as a single line of development. I borrowed streamlining concept from Go contribution guide as it really helps to review chaotic Mercurial commits. http://golang.org/doc/contribute.html#Code_review Maintaining centralized Subversion repository will require additional properties to be set, but this is doable. I don't how to make module split with Mercurial alone. http://mercurial.selenic.com/wiki/ShallowClone is still a draft (and complicated one) and Mercurial 1.6 that released today doesn't contain anything revolutionary to propose an alternative. I am exhausted. -- anatoly t.

9 14

FWD: error: 3.2 release schedule has release in Jan 2010.
by Aahz July 5, 2010

July 5, 2010

----- Forwarded message from Ric Johnson <rjcooks(a)yahoo.com> ----- > Date: Mon, 5 Jul 2010 08:49:29 -0700 (PDT) > From: Ric Johnson <rjcooks(a)yahoo.com> > Subject: error: 3.2 release schedule has release in Jan 2010. > To: webmaster(a)python.org > > Hey! > There's a typo on http://www.python.org/dev/peps/pep-0392/: > > Release Schedule > > The current schedule is: > > ... > > # 3.2 candidate 2: January 1, 2010 ==> should be 2011 > # 3.2 final: January 15, 2010 ==> should be 2011 > > > I know it is rough schedule but it looks bad ... > > Ric > > -Verba nihil operandi melius est quam absurde. > > > ----- End forwarded message ----- -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra

2 1

set/dict comprehensions don't leak in Py2.7 - intentional?
by Stefan Behnel July 5, 2010

July 5, 2010

Hi, I only noticed now that set/dict comprehensions were backported to 2.7 without letting the loop Variables leak into the surrounding scope. So they now behave different from list comprehensions. Is this intentional or just a backporting oversight? I'm asking because we had a discussion about the 'right' semantics several times on the Cython list, and the current behaviour is that all comprehensions leak when compiling Py2 code and the do not leak when compiling Py3 code. I would hate to fix that up to match 2.7 and then see that the behaviour in Py2.7 is to be considered an accident. Stefan

4 3

Can Python implementations reject semantically invalid expressions?
by Steven D'Aprano July 5, 2010

July 5, 2010

This question was inspired by something asked on #python today. Consider it a hypothetical, not a serious proposal. We know that many semantic errors in Python lead to runtime errors, e.g. 1 + "1". If an implementation rejected them at compile time, would it still be Python? E.g. if the keyhole optimizer raised SyntaxError (or some other exception) on seeing this: def f(): return 1 + "1" instead of compiling something which can't fail to raise an exception, would that still be a legal Python implementation? -- Steven D'Aprano

13 31

Thank yous
by Benjamin Peterson July 5, 2010

July 5, 2010

Now that Python 2.7 is out, I'd like to thank a few of the people who made it possible: - Martin for building Windows Installers to my schedule, maintaining the tracker and PyPi, and providing lots of guidance and advice. - Ronald for building Mac installers. - Tarek for picking up the reins of distutils. - Jesse for being responsive to last minute multiprocessing bugs. - Georg for keeping the documentation excellent and numerous bug fixes. - Victor for fixing obscure unicode bugs and segfaults. - Ezio for plugging unicode holes and fixing docs. - Alexander Belopolsky for taking up datetime. - R. David Murray for picking up the email module. - Alexandre Vassalotti for various backports. - Mark for oiling Python's mathematical gears and explaining floating point to me. - Antoine for backporting the improved io module, memoryviews, adopting the ssl module, and numerous bug fixes. - Barry for mentoring me in the release process and testing out release.py. - Dirkjan for always getting us closer to Mercurial migration. - Andrew for writing "What's New in Python 2.7?" That's a lot of changes to keep up with. - And, of course, all of the people who reported bugs or submitted patches. Thank you once again, Benjamin

8 7

More detailed build instructions for Windows
by Reid Kleckner July 4, 2010

July 4, 2010

Hey folks, I'm trying to test out a patch to add a timeout in subprocess.py on Windows, so I need to build Python with Visual Studio. The docs say the files in PCBuild/ work with VC 9 and newer. I downloaded Visual C++ 2010 Express, and it needs to convert the .vcproj files into .vcxproj files, but it fails. I can't figure out where to get VC 9, all I see is 2008 and 2010. Can someone with experience share the best practices for building Python on Windows? In particular, what is the most recent compiler known to work and where can I download it? Thanks, Reid

6 7