python-committers November 2013

python-committers@python.org

24 participants
16 discussions

Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

by Brett Cannon

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).

8 years, 1 month

Anatoly Techtonik's contribution (again)

by Antoine Pitrou

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.

8 years, 1 month

[RELEASED] Python 3.4.0b1

by Larry Hastings

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)

8 years, 1 month

Python 3.4.0b1 is now tagged, feature-freeze is now in effect

by Larry Hastings

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/

8 years, 1 month

Reminder: Less than 24 hours until 3.4 feature freeze

by Larry Hastings

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/

8 years, 1 month

The evolution of HTMLParser

by Ezio Melotti

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

8 years, 2 months

[RELEASED] Python 3.3.3 final

by Georg Brandl

-----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-----

8 years, 2 months

Reminder: Python 3.4 feature freeze in a week

by Larry Hastings

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/

8 years, 2 months

[RELEASED] Python 3.3.3 release candidate 2

by Georg Brandl

-----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-----

8 years, 2 months

Fwd: Re: Fwd: Python at HackerOne

by Christian Heimes

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

8 years, 2 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers November 2013