Re: [Python-Dev] blocking 2.7
On Sat, Jul 3, 2010 at 3:26 PM, Victor Stinner victor.stin...@haypocalc.com wrote: In the worst case, a function rejects valid data. If I have to choose, I prefer to reject valid data than a security vulnerability. But audioop has tests and I don't think that my patch breaks anything :-) But Python tests lack coverage stats, so it is hard to say anything. Even with tests it is not always possible to be even 80% sure if behavior is complicated or depends on the input data. -- anatoly 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] blocking 2.7
But Python tests lack coverage stats, so it is hard to say anything. FYI: http://coverage.livinglogic.de/ Regards ___ 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] distutils2 checking mails
Hi all ! I am sorry about the flood of mails in checkins this morning. It was annoying. It seems to me that this is a general problem that will appear in CPython too once it's in mercurial. I think this can be easily fixed by a patch policy. I have just sent a mail to python-ideas about this, to propose something. Regards Tarek -- Tarek Ziadé | http://ziade.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] Mercurial migration readiness
Am 04.07.2010 00:59, schrieb Martin v. Löwis: This is perhaps a naive question, but hat do you gain with the intermediate mirror clone of upstream? (Other than filling more of your disk?) In addition to the answer you got: this way of working is also the process that I arrived at, independently. I see two uses, both based around the problem creating a full clone will take a long time - much longer than a subversion checkout. 1. if I want several local checkouts (e.g. for testing separate features), I can clone them all from the local copy (thereby also preserving space, compared to independent clones) 2, throwing away local changes is not that easy in Mercurial, if you have committed them already. Of course, in SVN throwing away committed changes is completely impossible :) There are extensions to uncommit, but they are discouraged and have limitations. I wouldn't say that. strip works well and it does so logically, once one understands the DAG. The only thing discouraged is to strip changesets once pushed to the public repo, but that holds as well for getting rid of the changesets by making a new clone without them. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Mercurial migration readiness
The other risk with history-editing extensions is that they use the merge and rebase machinery to do their work, so they require a clean working directory. Otherwise you may loose uncommitted changes. Not requiring any Mercurial extension to contribute to Python would be a nice policy to lower the entry bar. Regards ___ 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] Mercurial migration readiness
Am 04.07.2010 13:29, schrieb Éric Araujo: The other risk with history-editing extensions is that they use the merge and rebase machinery to do their work, so they require a clean working directory. Otherwise you may loose uncommitted changes. That's true. Not requiring any Mercurial extension to contribute to Python would be a nice policy to lower the entry bar. That is already defeated by the need for the eol extension (which is now built-in in hg 1.6). Activating mq is something every developer should manage... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Mercurial migration readiness
Not requiring any Mercurial extension to contribute to Python would be a nice policy to lower the entry bar. That is already defeated by the need for the eol extension (which is now built-in in hg 1.6). Activating mq is something every developer should manage... Okay, make that “not requiring any third-party Mercurial extension” :) Some extensions are too useful to be left out, and since they’re shipped with Mercurial the cost of using them is null (patchbomb, eol, bookmarks, graphlog, progress, relink, crecord, rebase). MQ is another beast, it’s a new way of using Mercurial for middle or advanced users. Cheers ___ 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] Mercurial migration readiness
Martin v. Löwis mar...@v.loewis.de writes: My question is basically the same as Terry Reedy's, but I'm going to phrase it a bit differently: This is perhaps a naive question, but why do you create a second local clone instead of just creating a branch? IIUC, if you create a named branch, the branch will become globally visible when you push your changes back. I assume people will consider that clutter - it would be sufficient to just push the changes on the branch, along with commit messages, but not the branch itself (which would be only temporary, anyway). I'm not even sure how you pull changes from one branch into another: can somebody kindly explain the commands that would be required? You don't -- it is tempting to think of a named branch as a kind of container for changesets, but that metaphor makes people think that you can put changesets into a named branch and takes them out again. The opposite is in fact true: the changesets induce the named branch. Each changeset has a field in its metadata that names the branch it is on. So if you do hg branch X hg commit -m Created X branch then the newly created changeset has branch=X in its metadata. The X branch has thus been created because of the changeset. If there are no changesets with branch=X in your repository, then there is no X branch. A named branch is thus more a labeling system -- changesets belonging to the branch can (in principle) be scattered all over the repository. They are normally a connected sub-graph, though, and Mercurial will complain if you try to re-start a branch name. Since the branch name is embedded into the changesets themselves, you cannot changeset it without changing the identities of the changesets. A branch appears in the output of 'hg branches' if there are any open branch heads (a branch head is a changeset with no children on the same named branch). Use the 'hg commit --close-branch' command to make a closed branch head. The branch is considered closed when it only has closed branch heads. Summing up, the notion of named branches correspond quite closely to how people model branches in Subversion: if you make your changes in the directory branches/X/, then we say you work on the X branch. These revisions will always be on that branch. You can delete the branch by deleting the directory from the HEAD revision. The changes remain in the history and even after merging with trunk/, the old revision will of course show that they were made in the branches/X/ directory. Take a look at the bookmarks extension if you want to work with un-named branches (often called anonymous branches) instead. These branches are just a fork in the history graph, but they have no permanent name. The bookmarks gives you a convenient way to refer to them. Without bookmarks you can of course look at 'hg heads' or some other log viewer. http://mercurial.selenic.com/wiki/BookmarksExtension Since Mercurial 1.6, you can push and pull the bookmarks between repositories. They used to be local only, but this is now solved. See the bottom of the wiki page. -- Martin Geisler Mercurial links: http://mercurial.ch/ pgpocrujdNlzx.pgp Description: PGP signature ___ 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] Mercurial migration readiness
Am 04.07.2010 13:53, schrieb Éric Araujo: Not requiring any Mercurial extension to contribute to Python would be a nice policy to lower the entry bar. That is already defeated by the need for the eol extension (which is now built-in in hg 1.6). Activating mq is something every developer should manage... Okay, make that “not requiring any third-party Mercurial extension” :) mq is anything but third-party. Some extensions are too useful to be left out, and since they’re shipped with Mercurial the cost of using them is null (patchbomb, eol, bookmarks, graphlog, progress, relink, crecord, rebase). MQ is another beast, it’s a new way of using Mercurial for middle or advanced users. mq contains the strip command. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Mercurial migration readiness
Am 04.07.2010 13:37, schrieb Martin Geisler: Martin v. Löwis mar...@v.loewis.de writes: My question is basically the same as Terry Reedy's, but I'm going to phrase it a bit differently: This is perhaps a naive question, but why do you create a second local clone instead of just creating a branch? IIUC, if you create a named branch, the branch will become globally visible when you push your changes back. I assume people will consider that clutter - it would be sufficient to just push the changes on the branch, along with commit messages, but not the branch itself (which would be only temporary, anyway). I'm not even sure how you pull changes from one branch into another: can somebody kindly explain the commands that would be required? You don't -- it is tempting to think of a named branch as a kind of container for changesets, but that metaphor makes people think that you can put changesets into a named branch and takes them out again. I'm not sure if I misunderstand Martin's intent, but in principle, if you want to merge one changes (not changesets!) branch into another, all you need to do would be hg merge otherbranch. Subsequently committing the merge (after fixing conflicts) creates a new changeset on the current branch. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Mercurial migration readiness
On Sun, Jul 4, 2010 at 10:41 PM, Éric Araujo mer...@netwok.org wrote: By the way, is eol a requirement for people using Windows tools with limitations only, or for every person that will clone Python? It's designed so that everyone can run it regardless of platform. If someone chooses not to use it and messes up the line endings then the central repository hooks will reject the commit. 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] Mercurial migration readiness
I'm not sure if I misunderstand Martin's intent, but in principle, if you want to merge one changes (not changesets!) branch into another, all you need to do would be hg merge otherbranch. Subsequently committing the merge (after fixing conflicts) creates a new changeset on the current branch. Indeed, merges are branch-wise operations, not changeset-wise. You need tricks to copy one changeset from a named branch into another one. Copying changesets between a stable branch and a devel branch is easy if the devel history is a strict superset of the stable history. Every changesets landing into stable can then just be pulled into devel. This means no different named branches for stable and devel. Not sure I’m clear enough, I hope Mercurial experts can chime in. Regards ___ 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] Mercurial migration readiness
Éric Araujo mer...@netwok.org writes: I'm not sure if I misunderstand Martin's intent, but in principle, if you want to merge one changes (not changesets!) branch into another, all you need to do would be hg merge otherbranch. Subsequently committing the merge (after fixing conflicts) creates a new changeset on the current branch. Indeed, merges are branch-wise operations, not changeset-wise. You need tricks to copy one changeset from a named branch into another one. You basically need to replay the changes -- the transplant extension can do this for you. This is more or less a wrapper around 'hg export' (gives you a diff) and 'hg import' (applies the diff). Copying changesets between a stable branch and a devel branch is easy if the devel history is a strict superset of the stable history. Every changesets landing into stable can then just be pulled into devel. This means no different named branches for stable and devel. Not sure I’m clear enough, I hope Mercurial experts can chime in. It sounds like you are describing how Mercurial itself was developed before we began using named branches. This part of the graph is typical for us then: http://selenic.com/repo/hg/graph/52c5be55af82 Notice the three merges wtih 'crew-stable', which was what we called the clone representing the next stable release. Whenever a bugfix is made, it is immediatedly merged into the 'crew' clone, where normal development takes place. This gives a characteristic flow with two tracks (branches), where one is continuously merged into the other. The two with commit message Fix typeerror when specifying both --rebase and --pull (dd1b47e17d7e and aee8455ee8ec) are a typical example of a transplanted changeset: the bug was first fixed in 'crew', but it was then realized that it should also be in the 'crew-stable' repository so that it could be part of the next point release. Today we use a 'stable' branch in addition to the 'default' branch and the graph looks much the same: http://selenic.com/repo/hg/graph/4d3288197717 You'll notice the small labels saying 'stable' on the changesets from that branch -- that is the whole difference. A named branch is made up by the changesets that same the branch name, but the graph itself works the same. The nice thing about our current setup is that I can do hg update stable and the name 'stable' is then interpreted as the tip-most changeset on the stable branch. -- Martin Geisler Mercurial links: http://mercurial.ch/ pgpupOqXXRTQp.pgp Description: PGP signature ___ 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] [RELEASE] Python 2.7 released
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) ___ 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] Mercurial migration readiness
[Martin Geisler] You basically need to replay the changes -- the transplant extension can do this for you. This is more or less a wrapper around 'hg export' (gives you a diff) and 'hg import' (applies the diff). Core developers seem to be okay with svnmerge, so perhaps a familiar-looking command like transplant (with “merges” that are actually replays, and explicit blocking for bookkeeping) will feel right to them. It sounds like you are describing how Mercurial itself was developed before we began using named branches. Spot on, sir! [snip] You'll notice the small labels saying 'stable' on the changesets from that branch -- that is the whole difference. Thanks for the explanation. The new workflow seems quite good. Regards ___ 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] Thank yous
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 ___ 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] [RELEASE] Python 2.7 released
2010/7/4 Benjamin Peterson benja...@python.org: On behalf of the Python development team, I'm jocund to announce the second release candidate of Python 2.7. Arg!!! This should, of course, be final release. -- Regards, Benjamin ___ 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] [RELEASE] Python 2.7 released
On 07/04/2010 08:34 AM, Benjamin Peterson wrote: On behalf of the Python development team, I'm jocund to announce the second release candidate of Python 2.7. s/second release candidate/release/ *standing ovation* //larry// ___ 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] 2.7 hg mirror
On Sun, 4 Jul 2010 10:34:57 -0500 Benjamin Peterson benja...@python.org wrote: 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. A Mercurial mirror is also available for the 2.7 maintenance branch: http://code.python.org/hg/branches/release2.7-maint/ As usual, the full list of mirrors can be viewed at: http://code.python.org/hg 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] Thank yous
On Sun, Jul 4, 2010 at 12:02 PM, Benjamin Peterson benja...@python.org wrote: .. - Alexander Belopolsky for taking up datetime. I am honored that my contributions have been noticed, but would not be able to contribute as much without support from Mark Dickinson. ___ 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] Signs of neglect?
Hello pydev I’d like to volunteer to maintain a tool but I’m not sure where I can help. I’m already proposing changes to Brett for Tools/scripts/patchcheck.py, and I have commented on Tools/i18n bugs, but these ones are already maintained by their authors (e.g. Barry is assigned pygettext bugs) and I’m by no means a gettext expert. If I adopt a tool, it will still require some core dev time to review and commit, but I’ll do the bug triage, discussion and coding. I suggest that each adoption starts with a reindent.py run and a PEP 8 compliance check. Let demos and tools become a showcase to be proud of! I have opened a bug to discuss adding a simple sanity test that would just make sure tools and demos can run without syntax errors: http://bugs.python.org/issue9153 There was an open bug about demos, http://bugs.python.org/issue7962, I’ve widened it into a meta-bug for demos and tools. (I hope it is okay.) Please comment, adopt or condemn demos and tools in that report. Hope this helps. Regards ___ 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] Thank yous
On 4 July 2010 17:02, Benjamin Peterson benja...@python.org wrote: Now that Python 2.7 is out, I'd like to thank a few of the people who made it possible: And not forgetting Benjamin himself for managing the whole thing! Paul. ___ 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] Thank yous
On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore p.f.mo...@gmail.com wrote: On 4 July 2010 17:02, Benjamin Peterson benja...@python.org wrote: Now that Python 2.7 is out, I'd like to thank a few of the people who made it possible: And not forgetting Benjamin himself for managing the whole thing! +1. Thanks a lot for your hard work ___ 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] issue 9141
Dear colleagues: I'd like to have your input on http://bugs.python.org/issue9141 Allow objects to decide if they can be collected by GC. This generalizes the dynamic discovery of finalization state of objects, as already provided for generator objects with PyGen_NeedsFinalizing(),to any object. Kristján ___ 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] blocking 2.7
On 7/4/2010 2:31 AM, Éric Araujo wrote: But Python tests lack coverage stats, so it is hard to say anything. FYI: http://coverage.livinglogic.de/ Turns out the audioop is one of the best covered modules, at 98% -- 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] More detailed build instructions for Windows
On Sat, Jul 3, 2010 at 15:40, Martin v. Löwis mar...@v.loewis.de wrote: Am 03.07.2010 16:34, schrieb Christian Heimes: Am 03.07.2010 09:00, schrieb Martin v. Löwis: 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. Which docs did you look at specifically that said and newer? That would be a bug. The readme.txt in the PCbuild directory contains the sentence Microsoft Visual C++ 2008 Express Edition is required at the very least. The wording could be interpreted as 2008 at very least instead of Express Edition at very least. That's what I expected to get as an answer - interestingly enough, Reid was looking at some other place (the FAQ) that literally said and newer. I'd call that an error, even though, technically, converting the projects to VS 2010 ought to work (i.e. it did after I committed some fixes to make it work). FAQ updated with and newer stripped out. -Brett 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/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] Thank yous
On Sun, Jul 4, 2010 at 1:26 PM, Tarek Ziadé ziade.ta...@gmail.com wrote: On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore p.f.mo...@gmail.com wrote: On 4 July 2010 17:02, Benjamin Peterson benja...@python.org wrote: Now that Python 2.7 is out, I'd like to thank a few of the people who made it possible: And not forgetting Benjamin himself for managing the whole thing! +1. Thanks a lot for your hard work Seriously Benjamin, you've done a great job. ___ 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] Thank yous
Am 04.07.2010 22:45, schrieb Jesse Noller: On Sun, Jul 4, 2010 at 1:26 PM, Tarek Ziadé ziade.ta...@gmail.com wrote: On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore p.f.mo...@gmail.com wrote: On 4 July 2010 17:02, Benjamin Peterson benja...@python.org wrote: Now that Python 2.7 is out, I'd like to thank a few of the people who made it possible: And not forgetting Benjamin himself for managing the whole thing! +1. Thanks a lot for your hard work Seriously Benjamin, you've done a great job. Totally! *cheer* Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
