Re: [python-committers] Deny nonbreaking spaces in the precommit script?
On Mon, 2010-11-08 at 12:22 +, Michael Foord wrote: > On 08/11/2010 12:18, Łukasz Langa wrote: > > Am 08.11.2010 12:55, schrieb Michael Foord: > >> On 08/11/2010 11:42, Senthil Kumaran wrote: > >>> We can just customize our environments. It is easy. > > > > I already pointed out in my last post why that's not going to solve > > the problem. > > > >> Additional checks could be put in `make patchcheck` or a local commit > >> hook for hg. > > > > Automation always pays off. Simplifying the process always pays off. > > Providing yet another step to the workflow would be a move in the > > opposite direction*. > > You mean `make patchcheck` isn't *already* part of your workflow? FWIW, "make patchcheck" isn't mentioned on the "Python Patch Submission Guidelines" here: http://www.python.org/dev/patches/ and doesn't seem to be mentioned anywhere on the website. I'm attaching a patch (to the website) that adds this to that page. (snip) Index: data/dev/patches/content.ht === --- data/dev/patches/content.ht (revision 13459) +++ data/dev/patches/content.ht (working copy) @@ -40,6 +40,13 @@ or documentation; it's better to use the same issue and keep all discussion in one place. +* Please run "make patchcheck" before submitting your patch. This is a + checklist of common issues with patches. It will try to enforce whitespace + rules in the files you changed. It will also remind you to run the test + suite, and remind you if you haven't edited the documentation, ``Misc/ACKS`` + or ``Misc/NEWS``. + + Python Patch Style Guidelines - ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] Python Language Summit at PyCon US
On Tue, 2012-01-10 at 13:04 +, Michael Foord wrote: > Hello Python Committers, > > As usual we will hold a Python Language Summit before the PyCon US conference. [...] > If you have topics you would like to see on the agenda please also let me > know. I sincerely hope that we'll have secured the various python runtimes against hash collision denial-of-service attacks by the time of the language summit, but if not, we probably ought to talk about the issue then. Thanks Dave ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] List Linux distribution maintainers to help with bug triaging?
On Thu, 2012-04-26 at 11:55 +1000, Nick Coghlan wrote: > While helping to diagnose what appears to be a Fedora/RHEL specific > problem with distutils, it occurred to me that it may be useful for > triaging that kind of distribution specific problem if distro package > maintainers (or at least points of contact) were listed in the experts > file in the devguide: http://docs.python.org/devguide/experts > > What do people think of the idea of adding specific distros (e.g. > "Linux (Fedora/RHEL)", "Linux (Ubuntu)") to the "Platforms" table for > cases related to building and packaging where it may not be clear if > the problem lies within CPython or within the distro? Feel free to add me for "Linux (Fedora/RHEL)". ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PyCon Language Summit: Wednesday 9th April
On Wed, 2013-12-04 at 12:28 -0800, Eli Bendersky wrote: > > > > On Wed, Dec 4, 2013 at 11:47 AM, M.-A. Lemburg wrote: > On 04.12.2013 20:07, Benjamin Peterson wrote: > > 2013/12/4 Barry Warsaw : > >> On Dec 04, 2013, at 07:15 PM, Antoine Pitrou wrote: > >> > >>> As for the question, I think we should wait at least two > or three years > >>> before "sunsetting" 2.7. > >> > >> I've been thinking we should move Python 2.7 to > security-fix only around the > >> Python 3.5 time frame, with a couple more years of promised > security support. > > > > FWIW, the current plan is to have the last normal release in > 2015 and > > security releases "indefinitely" (2020 or something like > that). > > > Just as data point: we have customers that still request > Python 2.4 > compatible versions of our products - simply because they > cannot > upgrade. The last release of that series was in 2008. > > > I was always curious about these "cannot upgrade" cases. Most of the > time, they seem to boil down to "because that's the default Python our > RHEL comes with", completely ignoring the possiblity of just building > a newer Python locally and/or carrying along with the product. FWIW Red Hat also now has a RH-supported way of running more recent versions of Python on RHEL: http://developerblog.redhat.com/2013/09/12/rhscl1-ga/ though I believe that's only supported on RHEL6 onwards (giving 2.7 and 3.3. on RHEL6). Doesn't help on RHEL 5 (which is still 2.4), though there are (unsupported) srpms available for later releases there. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
