Mailman 3 November 2013 - python-committers

Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges
by Brett Cannon Dec. 1, 2013

Dec. 1, 2013

I just want to make sure others know that Georg has warned Anatoly that if he continues to re-open a specific issue he will lose his tracker privileges (http://bugs.python.org/issue19822#msg204696). I stand behind his warning and will support anyone who enforces it. I would suggest that if he does this to *any* other issue that he be warned that flipping *any *fields after a core dev has made a decision and without discussing it first will also lead to his loss of privileges. I would also like to point out his attitude is still horrible at times; being accused of spreading "ill FUD policies in favor of creating [a] collaborative environment" is not exactly polite ( http://bugs.python.org/issue19826#msg204693).

18 66

Anatoly Techtonik's contribution (again)
by Antoine Pitrou Nov. 29, 2013

Nov. 29, 2013

Hello, I'm a bit curious, but do people think Anatoly is now behaving more constructively than before? He does seem to post *less*, otherwise... After all, he's just sent another rant about the "community process" in which the word CLA seems to appear multiple times: https://mail.python.org/pipermail/python-dev/2013-November/130632.html Regards Antoine.

6 5

[RELEASED] Python 3.4.0b1
by Larry Hastings Nov. 24, 2013

Nov. 24, 2013

On behalf of the Python development team, it's my privilege to announce the first beta release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 453, a bundled installer for the *pip* package manager * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for late February 2014. To download Python 3.4.0b1 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0b1 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors)

1 1

Python 3.4.0b1 is now tagged, feature-freeze is now in effect
by Larry Hastings Nov. 24, 2013

Nov. 24, 2013

Please refrain from checking in any new features to Python trunk until after the 3.4 release branch is created (which will be a few months). Instead, let's concentrate our efforts on polishing Python 3.4 until it's the best and most-defect-free release yet! Thanks, //arry/

1 0

Reminder: Less than 24 hours until 3.4 feature freeze
by Larry Hastings Nov. 22, 2013

Nov. 22, 2013

I hope to tag 3.4 in less than 24 hours from now. Last call, folks. Here's hoping the buildbots all get green soon, //arry/

1 0

The evolution of HTMLParser
by Ezio Melotti Nov. 20, 2013

Nov. 20, 2013

Hi, during the last few months/years I worked on HTMLParser and the html package -- this is a brief summary of what happened, what I'm working on for 3.4, and what are the plans for future, and I'm looking for some feedback about the latter. When I first looked at it, the parser was able to parse most valid pages, and had some heuristic to work around common mistakes, but was raising exceptions on most broken pages. On Python 3.2 it also had a new strict argument that when set to False would allow the parser to try to handle some more broken markup. Last year HTML5 became a "Candidate Recommendation", and a lengthy specification with detailed algorithms to handle both valid and invalid markup was released [0]. Since then I worked on converging HTMLParser to the HTML5 standard, while trying to remain backward compatible and, where necessary, provide warnings for the changes I was making. Since the HTML5 standard specifies how to handle broken markup and since the strict mode of HTMLParser is not strict enough to be used to validate markup, I decided to deprecate it in 3.3 and remove it in 3.5 [2]. Currently the parser is able to handle horribly broken markup and (in theory) should never raise errors while parsing HTML. The result it produces is really close to what the standard says and what the browser does (I intentionally ignore a few obscure corner cases to keep the code relatively simple/fast). This is true for both 2.7 and 3.x (you can try to break it and report any failures you might encounter). Python 3.3 also comes with the list of HTML 5 entities (html.entities.html5), and 3.4 will have an html.unescape() function to convert them to the corresponding Unicode characters. Now I'm working on #13633 (Automatically convert character references in HTMLParser [1]), and I'm planning to add a convert_charrefs boolean flag to the constructors that, when set to True, will automatically convert charrefs (e.g. """, """) to the corresponding Unicode characters, and avoid calling the handle_charref/handle_entityref methods. Since in my opinion this behavior is preferable, I am thinking about switching the default to True in 3.5/3.6 and add a warning to 3.4 that warns the user to either set convert_charrefs explicitly or be ready to a behavior change in 3.5/3.6. This means that HTMLParser will see the warning and will have to set the flag, and they will be able to remove it in 3.5/3.6, when the default will be True and warning will be gone. Do you think this would be acceptable? If not, can you think any better way to do it? After this, most of the work on HTMLParser and the html package should be done. I plan to update the documentation and say that the parser is (almost) compliant with HTML 5, phase out the deprecated "strict" argument [2] and eventually the warning about convert_charrefs, and possibly do some optimizations/clean ups. There's also an open issue to add a generator-based API [3], but that's a major change and I need more time to think about it. Best Regards, Ezio Melotti [0]: http://www.w3.org/TR/html5/syntax.html [1]: http://bugs.python.org/issue13633 - Automatically convert character references in HTMLParser [2]: http://bugs.python.org/issue15114 - Deprecate strict mode of HTMLParser [3]: http://bugs.python.org/issue17410 - Generator-based HTMLParser

2 2

[RELEASED] Python 3.3.3 final
by Georg Brandl Nov. 19, 2013

Nov. 19, 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I'm very happy to announce the release of Python 3.3.3. Python 3.3.3 includes several security fixes and over 150 bug fixes compared to the Python 3.3.2 release. Importantly, a security bug in CGIHTTPServer was fixed [1]. Thank you to those who tested the 3.3.3 release candidate! This release fully supports OS X 10.9 Mavericks. In particular, this release fixes an issue that could cause previous versions of Python to crash when typing in interactive mode on OS X 10.9. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in the 3.3 series, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.3 rc2 visit: http://www.python.org/download/releases/3.3.3/ This is a production release, please report any bugs to http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) [1] http://bugs.python.org/issue19435 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlKLDGYACgkQN9GcIYhpnLCjewCfQ+EJHpzGzIyTvYOrYmsRmnbv n40AniVM0UuQWpPrlCu349fu7Edt+d4+ =WSIj -----END PGP SIGNATURE-----

1 0

Reminder: Python 3.4 feature freeze in a week
by Larry Hastings Nov. 16, 2013

Nov. 16, 2013

We're on schedule to tag Python 3.4 Beta 1 next Saturday. And when that happens we go into "feature freeze" on Python trunk; no new features will be accepted in trunk until we branch the 3.4 release branch next February. Time to get those checkins in folks. Last call, everyone, //arry/

1 0

[RELEASED] Python 3.3.3 release candidate 2
by Georg Brandl Nov. 12, 2013

Nov. 12, 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I'm quite happy to announce the Python 3.3.3 release candidate 2. Python 3.3.3 includes several security fixes and over 150 bug fixes compared to the Python 3.3.2 release. This release fully supports OS X 10.9 Mavericks. In particular, this release fixes an issue that could cause previous versions of Python to crash when typing in interactive mode on OS X 10.9. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in the 3.3 series, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.3 rc2 visit: http://www.python.org/download/releases/3.3.3/ This is a preview release, please report any bugs to http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlKB1G4ACgkQN9GcIYhpnLAu5gCfRkfpnEs+rmtZ9iTjaaZcHDx3 sNYAn180Q4cFZmKtwJdaG+g/3jHAVd97 =n/Tt -----END PGP SIGNATURE-----

1 0

Fwd: Re: Fwd: Python at HackerOne
by Christian Heimes Nov. 8, 2013

Nov. 8, 2013

Here is another mail from Alex. I asked him about conflict of interest: -------- Original-Nachricht -------- Betreff: Re: Fwd: Python at HackerOne Datum: Thu, 7 Nov 2013 17:33:52 -0800 Von: Alex Rice <arice(a)hackerone.com> An: Christian Heimes <christian(a)python.org> Our "easy fix" to the collusion issue is to request core developers donate the bounty directly to a nonprofit instead of personal gain (the nonprofit could be the PSF). Attacking the problem directly requires a bit more structure. This would be a start: - transparent, consistent bounty amounts. This requires removing most subjectiveness from the award process - volunteer cannot be paid for a bug in code they wrote - bug must have been *live* for 12+ months But, to be honest, it's not a problem with one clearcut solution. If there's a desire for a formal code of conduct (probably a worthwhile exercise), we can take a first pass at drafting one and request feedback from the community. On Nov 7, 2013 8:19 PM, "Christian Heimes" <christian(a)python.org <mailto:christian@python.org>> wrote: Am 08.11.2013 01:45, schrieb Alex Rice: > FYI :) Hi Alex, I totally forgot that it's a member's only mailing list. I have forward your mail. Thanks for the heads-up! We are going to discuss your input internally and get back to you in a couple of days. I have one final question / remark for you: Do you have a recommendation how we should handle conflict of interests with IBB? After all a high percentage of security-related discoveries, fixes and improvements are made by Python core committers or PSRT members. Although we are all unpaid volunteers I (and probably others) would feel uncomfortable to suggest fellow developers for a bounty. It would feel like cronyism... Are you working on a code of conduct for these kinds of problems? Good night! Christian

1 0

Fwd: Re: Python at HackerOne
by Christian Heimes Nov. 7, 2013

Nov. 7, 2013

Forwarded mail -------- Original-Nachricht -------- Betreff: Re: Python at HackerOne Datum: Thu, 7 Nov 2013 16:37:30 -0800 Von: Alex Rice <arice(a)hackerone.com> An: Christian Heimes <christian(a)python.org> Kopie (CC): python-committers(a)python.org, IBB Panel <ibb-panel(a)hackerone.com> Hi Christian! Thanks for getting in touch, glad there's interest on your end! Our initial approach was structured to be as noninvasive as possible. The simple version: we'll keep an eye out for public security patches and reactively issue bounties for both the discovery & fix. This passive approach is optimized for minimizing pain but leaves room for efficiency gains given how removed we are from the project. Fortunately, we have a lot of flexibility here and we welcome assistance devising more effective means of rewarding outstanding security contributions to the Python community. Here are a few options worth mentioning: - Our initial scope only covers the rare, high-severity bugs, because we're a bottleneck that can't investigate every bug. This scope can be expanded if you're willing to accept more submissions and provide a severity assessment for confirmed bugs. For example, you might include low-severity bugs (i.e., DoS) for ~$500. - Please shout at us whenever you observe a contribution that you believe made us all safer. You will undoubtedly have insight into each vulnerability that we might have overlooked. - We're happy to make suggested edits to the program's description at https://hackerone.com/python In general, you're the boss: feel free to think of this as the "Python Bug Bounty". You tell us how the budget would be spent most effectively and we'll work with you to strike a balance. As examples, the guys at Phabricator decided to exclude bounties for patches (they'd rather fix every issue themselves) and rewrote most of our scope from scratch. Django is going through the same exercise right now. Thanks, Alex

1 0

Python at HackerOne
by Christian Heimes Nov. 7, 2013

Nov. 7, 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi! I'm contacting you on behalf of the Python core committers and Python Security Response Team (PSRT). We were really excited and honored that Python was selected as one of the twelve first projects for the new Internet Bug Bounty program. Thanks a lot for including Python! Is there anything the PSRT or Python Software Foundation can do to join the effort and assist with your program? I think it's in our mutable interest to spread the word and handle incoming security issues properly. We will be glad to help you. Regards, Christian Heimes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSe+w5AAoJEMeIxMHUVQ1FScgP/RFfopZobKp6Zm6m+/x3PLuK drN6qNFz+bVTP0OWBjuADLOIJHMH2Bg4BdhBaxwz0gFF+f4g6iqr5bI4VJRhaDiE Is99KzY7ZrMUy2OKC0MbrmbAxrWq8axmwel2u4wjCs/EH1qr794/fwExCEG8udzq 3KEzlBT5S+sxVvv8aXLeQX5fRyEAxr6saRtbXqThTZjL/MmZ0cb4f3eNfJDT4RTv SDHRjnAC/OtrGr5Qg+0y+qX7Qa7+YcMvQXGmNIFIrunbUCGiODtBJAx8xsjZNFDP 6N28CprnHYo2fLkDJTC//QhIpdS+dsrHtEhNih1cxw5ZjMf28MQNEenPjFx27S// gFkJC87JFV3cbWVFWZLM8j8im1tv+o2Ph09nrLj8QoApS5cgLB3LJXUy2b++rHOX cw5OM3BlQt701KpV3ATuPspWQEELqlKB7+gOeJEdd0+XUrEQfIEMdiT6fZOEOE+N qd+uPKRUNxxVC8kGne2GszhLXhHoeeBDK8EaTICr94Xw3ZVM8HaNBA6sykDdXEXn QX8OjSrXbW9iyS63Aru6KoUZS0PdHAzSHLDQbzRJUMtaE39kxVe5zfLovgaPY3dH zQnvotts5jvZ6K/G89dyNLqDRnGrZgPROKej1Uws82iah6GXO/3FTFSGrRmX4JUk /9xOzzkdBMjS1EF6/ca+ =oUpk -----END PGP SIGNATURE-----

1 0

Python bug bounty
by Christian Heimes Nov. 7, 2013

Nov. 7, 2013

Hi, this is going through the news right now. Has anybody contact us about the bug bounty program for Python? https://hackerone.com/python Christian

3 4

2.7.6
by Benjamin Peterson Nov. 3, 2013

Nov. 3, 2013

I know I said I would do Python 2.7.6 this weekend, but I became unexpectedly busy. I will plan to get to it in the next few days. -- Regards, Benjamin

1 0

Thank you
by Zachary Ware Nov. 3, 2013

Nov. 3, 2013

Hi all, Just wanted to briefly say thank you for the vote of confidence in accepting me into your ranks. I'm looking forward to working with such a great group of people on such a great project for a long time to come! Thanks, Zach Ware

4 3

Zachary Ware for commit access?
by Brian Curtin Nov. 1, 2013

Nov. 1, 2013

Hi all, What do you think about giving commit access to Zachary Ware? He's been active on the tracker for a while and has contributed a good bit of Windows code. I'm not doing much Windows stuff these days, and unfortunately I haven't had much time to contribute much lately. The latter will be changing, but the former probably won't. Anyways, Zach is interested in picking up some of our Windows slack and I think he could benefit from commit access. Although I've been mostly quiet, I have been nosy on most of his issues and have looked over most of the patches. I volunteer to continue looking after him as I too get back into contributing. Any thoughts?

7 6