[Python-Dev] contributor to committer
Hello, I am a semi-regular contributor for Python: I have contributed many patches since end of last year, some of them were reviewed by Antoine. Lately, he suggested that I should apply for commit rights. Some of the accepted patches: - Fix refleaks in py3k branch (#5596) - Extend stringlib fastsearch for various methods of bytes, bytearray and unicode objects (#7462 and #7622) - Various documentation patches, including FAQ Recently, I worked with Ezio to fix some tests and to silence py3k warnings in the test suite (#7092). And I am in touch with Fredrik to release ElementTree 1.3 and port it to Python 2.7 (#6472). As a final note, I would like to highlight a small script in the same spirit as Pyflakes: pep8.py I've contributed few patches for the version 0.5, released a week ago: http://pypi.python.org/pypi/pep8/ -- Florent Xicluna ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Question for you
Michael Foord wrote: > Hello Connor, > > I think you have the wrong email address - this is Python-dev, an email > list for the development *of* Python. One of the boost specific lists or the general python-list (aka comp.lang.python) would be the place to go for help of this nature. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython
Tarek Ziadé wrote: > That makes me wonder : why don't we have a sys.implementation variable ? > (cython/jython/pypi), since we can have several values for cython in > sys.platform You might want to try and catch up with Christian Heimes. He was going to write a PEP to add one, but must have been caught up with other things. See the thread starting at: http://mail.python.org/pipermail/python-dev/2009-October/092893.html Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Add alternate float formatting styles to new-style formatting: allowed under moratorium?
http://bugs.python.org/issue7094 proposes adding "alternate" formatting [1] to floating point new-style formatting (float.__format__ and probably Decimal.__format__). I'd like to add this to make automated translation from %-formatting strings to str.format strings easier. Would this be allowed under the moratorium? I think it falls under the Case-by-Case Exemptions section, but let me know what you think. Eric. [1] Alternate formatting for floats modifies how trailing zeros and decimal points are treated. See http://docs.python.org/dev/library/stdtypes.html#string-formatting-operations ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add alternate float formatting styles to new-style formatting: allowed under moratorium?
Eric Smith wrote: > http://bugs.python.org/issue7094 proposes adding "alternate" formatting > [1] to floating point new-style formatting (float.__format__ and > probably Decimal.__format__). I'd like to add this to make automated > translation from %-formatting strings to str.format strings easier. > > Would this be allowed under the moratorium? I think it falls under the > Case-by-Case Exemptions section, but let me know what you think. +1 to add it. We want the new-style formatting to be able to replace as many old style uses as possible (preferably all of them) and this is a well-defined formatting operation from C99. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] contributor to committer
On Wed, 24 Feb 2010 12:13:10 +, Florent Xicluna wrote: > I am a semi-regular contributor for Python: I have contributed many patches > since end of last year, some of them were reviewed by Antoine. > Lately, he suggested that I should apply for commit rights. +1 --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Another version of Python
Some of you have probably already seen this, but in case you haven't: http://www.staringispolite.com/likepython/ :-) Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Another version of Python
On Feb 24, 2010, at 10:37 AM, [email protected] wrote: > Some of you have probably already seen this, but in case you haven't: > >http://www.staringispolite.com/likepython/ I wish I actually had, like, that much time on my hands bro. S ___ Python-Dev mailing list [email protected] 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 repository for Python benchmarks
Would there be any interest in accepting IronPython's in-house benchmarks into this repository as well? Internally we run the usual suspects (PyStone, PyBench, etc), but we also have a plethora of custom benchmarks we've written that also happen to run under CPython. My best, Dave -- Message: 2 Date: Mon, 22 Feb 2010 15:17:09 -0500 From: Collin Winter To: Daniel Stutzbach Cc: Dirkjan Ochtman , Python Dev Subject: Re: [Python-Dev] Mercurial repository for Python benchmarks Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 21, 2010 at 9:43 PM, Collin Winter wrote: > Hey Daniel, > > On Sun, Feb 21, 2010 at 4:51 PM, Daniel Stutzbach > wrote: >> On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter >> wrote: >>> >>> 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. >> >> If and when you have a benchmark repository set up, could you announce it >> via a reply to this thread?? I'd like to check it out. > > Will do. The benchmarks repository is now available at http://hg.python.org/benchmarks/. It contains all the benchmarks that the Unladen Swallow svn repository contains, including the beginnings of a README.txt that describes the available benchmarks and a quick-start guide for running perf.py (the main interface to the benchmarks). This will eventually contain all the information from http://code.google.com/p/unladen-swallow/wiki/Benchmarks, as well as guidelines on how to write good benchmarks. If you have svn commit access, you should be able to run `hg clone ssh://[email protected]/repos/benchmarks`. I'm not sure how to get read-only access; Dirkjan can comment on that. Still todo: - Replace the static snapshots of 2to3, Mercurial and other hg-based projects with clones of the respective repositories. - Fix the 2to3 and nbody benchmarks to work with Python 2.5 for Jython and PyPy. - Import some of the benchmarks PyPy has been using. Any access problems with the hg repo should be directed to Dirkjan. Thanks so much for getting the repo set up so fast! Thanks, Collin Winter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython
On Wed, Feb 24, 2010 at 6:35 AM, Nick Coghlan wrote: > Tarek Ziadé wrote: >> That makes me wonder : why don't we have a sys.implementation variable ? >> (cython/jython/pypi), since we can have several values for cython in >> sys.platform > Hello. So I propose to have a sys.implementation which would have string representation like "CPython" or "Jython" and have a couple of extra attributes on that. I can think about a lot of attributes, however, couple comes to mind as obvious. * supports_c_api - whether it can load and use CPython C modules * gc_strategy - probably equals "refcounting" or not, useful for some people * frame_introspection - This is mostly True for everybody except IronPython which has it as an optional command line argument. Might be useful to have it for some projects, unsure. What do you think? I'm willing to implement this for CPython and PyPy (this should be dead-simple anyway). Cheers, fijal ___ Python-Dev mailing list [email protected] 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 repository for Python benchmarks
On Wed, Feb 24, 2010 at 12:12 PM, Dave Fugate wrote: > Would there be any interest in accepting IronPython's in-house benchmarks > into this repository as well? Internally we run the usual suspects (PyStone, > PyBench, etc), but we also have a plethora of custom benchmarks we've written > that also happen to run under CPython. > > My best, > > Dave > From my perspective the more we have there the better. We might not run all of them on nightly run for example (we as in PyPy). Are you up to adhering to perf.py expectation scheme? (The benchmark being runnable by perf.py) Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] contributor to committer
On Wed, Feb 24, 2010 at 7:13 AM, Florent Xicluna wrote: > Hello, > > I am a semi-regular contributor for Python: I have contributed many patches > since end of last year, some of them were reviewed by Antoine. > Lately, he suggested that I should apply for commit rights. > +1 -- Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython
On Feb 23, 2010, at 2:10 PM, Tarek Ziadé wrote: > On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski wrote: >> Hello. >> >> I would like to have a feature on platform module (or sys or >> somewhere) that can tell distutils or distutils2 that this platform >> (be it PyPy or Jython) is not able to compile any C module. The >> purpose of this is to make distutils bail out in more reasonable >> manner than a compilation error in case this module is not going to >> work on anything but CPython. >> >> What do you think? > > +1 > > I think we could have a global variable in sys, called "dont_compile", > distutils would look at > before it tris to compile stuff, exactly like how it does for pyc file > (sys.dont_write_bytecode) Every time somebody says "let's have a global variable", God kills a kitten. If it's in sys, He bludgeons the kitten to death *with another kitten*. sys.dont_write_bytecode really ought to have been an API of an importer object somewhere; hopefully, when Brett has the time to finish the refactoring which he alluded to at the language summit, it will be. Similarly, functionally speaking this API is a good idea, but running the C compiler is distutils' job. Therefore any API which describes this functionality should be close to distutils itself. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'languishing' status for the tracker
On Feb 22, 2010, at 12:17 AM, R. David Murray wrote: > 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. In my opinion, the problem is not so much that tickets are left open for a long time, as that there's no distinction between triaged and un-triaged tickets. I think it's perfectly fine for tickets to languish as "open", in no special state, as long as it's easy to find out whether someone has gotten back to the original patch-submitter or bug-reporter to clarify the status at least once. Of course, then the submitter needs to be able to put it back into the un-triaged state by making a counterproposal, or attaching a new patch. To the extent that people are frustrated with the Python development process, it's generally not that their bugs don't get fixed (they understand that they're depending on volunteer labor); it's that they went to the trouble to diagnose the bug, specify the feature, and possibly even develop a complete fix or implementation, only to never hear *anything* about what the likelihood is that it will be incorporated. In the Twisted tracker, whenever we provide feedback or do a code review that includes critical feedback that needs to be dealt with before it's merged, we re-assign the ticket to its original submitter. I feel that this is pretty clear: it means "the ticket is open, it's valid, but it's also not my problem; if you want it fixed, fix it yourself". ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] contributor to committer
> On Wed, Feb 24, 2010 at 7:13 AM, Florent Xicluna > > Hello, > > > > I am a semi-regular contributor for Python: I have contributed many patches > > since end of last year, some of them were reviewed by Antoine. > > Lately, he suggested that I should apply for commit rights. > > Another +1. :) -- Senthil Every living thing wants to survive. -- Spock, "The Ultimate Computer", stardate 4731.3 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython
On Wed, Feb 24, 2010 at 11:17 AM, Glyph Lefkowitz wrote: > > On Feb 23, 2010, at 2:10 PM, Tarek Ziadé wrote: > >> On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski wrote: >>> Hello. >>> >>> I would like to have a feature on platform module (or sys or >>> somewhere) that can tell distutils or distutils2 that this platform >>> (be it PyPy or Jython) is not able to compile any C module. The >>> purpose of this is to make distutils bail out in more reasonable >>> manner than a compilation error in case this module is not going to >>> work on anything but CPython. >>> >>> What do you think? >> >> +1 >> >> I think we could have a global variable in sys, called "dont_compile", >> distutils would look at >> before it tris to compile stuff, exactly like how it does for pyc file >> (sys.dont_write_bytecode) > > Every time somebody says "let's have a global variable", God kills a kitten. I't not a global *variable*, it's a global *constant*, unlike dont_write_bytecode. > Similarly, functionally speaking this API is a good idea, but running the C > compiler is distutils' job. Therefore any API which describes this > functionality should be close to distutils itself. We're talking here about a way how interpreter can tell distutils what it can and what it can't do. Other option would be to modify distutils shipped with other python implementations, but that's a bit against goals of having a unified stdlib. Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Another version of Python
Reminiscent of INTERCAL, where you had to say PLEASE at regular but not too frequent intervals, or the compiler would accuse you of being either too impolite or too smarmy. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using git to checkout Python
On Feb 23, 2010, at 11:17 AM, Neil Schemenauer wrote: >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 Along those lines, I've updated the wiki for instructions on using Bazaar via the Launchpad mirrors of the Subversion masters: http://wiki.python.org/moin/Bazaar -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add alternate float formatting styles to new-style formatting: allowed under moratorium?
On 2/24/2010 8:13 AM, Eric Smith wrote: http://bugs.python.org/issue7094 proposes adding "alternate" formatting [1] to floating point new-style formatting (float.__format__ and probably Decimal.__format__). I'd like to add this to make automated translation from %-formatting strings to str.format strings easier. An excellent goal, for the reasons Nick stated. Would this be allowed under the moratorium? I see the formating mini-language as somewhat separate from Python syntax itself (as is the re minilanguage). In any case, it is new and somewhat experimental, rather than being the result of 20 years of testing. Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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 repository for Python benchmarks
perf.py - I'll look into this. At this point we'll need to refactor them any ways as there are a few dependencies on internal Microsoft stuff the IronPython Team didn't create. Thanks, Dave -Original Message- From: Maciej Fijalkowski [mailto:[email protected]] Sent: Wednesday, February 24, 2010 10:51 AM To: Dave Fugate Cc: [email protected] Subject: Re: [Python-Dev] Mercurial repository for Python benchmarks On Wed, Feb 24, 2010 at 12:12 PM, Dave Fugate wrote: > Would there be any interest in accepting IronPython's in-house benchmarks > into this repository as well? Internally we run the usual suspects (PyStone, > PyBench, etc), but we also have a plethora of custom benchmarks we've written > that also happen to run under CPython. > > My best, > > Dave > From my perspective the more we have there the better. We might not run all of them on nightly run for example (we as in PyPy). Are you up to adhering to perf.py expectation scheme? (The benchmark being runnable by perf.py) Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] contributor to committer
Le Wed, 24 Feb 2010 12:13:10 +, Florent Xicluna a écrit : > Hello, > > I am a semi-regular contributor for Python: I have contributed many > patches since end of last year, some of them were reviewed by Antoine. Semi-regular is quite humble. You have been cranking out patches at a higher frequency than almost any of us in the last 3 months. We are exhausted of reviewing and (most of the time) committing your patches :) (fortunately, your work happens to be of consistently good quality) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] contributor to committer
On Wed, Feb 24, 2010 at 18:48, Antoine Pitrou wrote: > Le Wed, 24 Feb 2010 12:13:10 +, Florent Xicluna a écrit : > > Hello, > > > > I am a semi-regular contributor for Python: I have contributed many > > patches since end of last year, some of them were reviewed by Antoine. > > Semi-regular is quite humble. You have been cranking out patches at a > higher frequency than almost any of us in the last 3 months. We are > exhausted of reviewing and (most of the time) committing your patches :) > (fortunately, your work happens to be of consistently good quality) > > Regards > > Antoine. > > Sometimes it seems like half of the tracker updates are Florent's. Semi-regular is quite the understatement. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] contributor to committer
Florent Xicluna gmail.com> writes: > I am a semi-regular contributor for Python: I have contributed many patches > since end of last year, some of them were reviewed by Antoine. > Lately, he suggested that I should apply for commit rights. +1 Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
