On Tue, Jan 17, 2012 at 15:11, Brian Curtin br...@python.org wrote:
On Tue, Jan 17, 2012 at 15:01, Martin v. Löwis mar...@v.loewis.de wrote:
I previously completed the port at my old company (but could not
release it), and I have a good bit of it completed for us at
PEP: XXX
Title: Interpreter support for concurrent programming
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman et...@stoneleaf.us
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Jan-2012
Python-Version: 3.3
Post-History:
Abstract
One of the open
On Jan 26, 2012, at 10:54 PM, Benjamin Peterson wrote:
2012/1/26 Ethan Furman et...@stoneleaf.us:
PEP: XXX
Title: Interpreter support for concurrent programming
mm?
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman et...@stoneleaf.us
Status: Draft
Type: Standards Track
Benjamin Peterson wrote:
2012/1/26 Ethan Furman et...@stoneleaf.us:
PEP: XXX
Title: Interpreter support for concurrent programming
mm?
Oops!
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman et...@stoneleaf.us
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
2012/1/26 Ethan Furman et...@stoneleaf.us:
BTW, I don't really think this needs a PEP.
Obviously it doesn't hurt. And I see from the issue that the change
was not as uncontroversial as I originally thought, so it's likely for
the better.
--
Regards,
Benjamin
On Fri, Jan 27, 2012 at 1:54 PM, Benjamin Peterson benja...@python.org wrote:
BTW, I don't really think this needs a PEP.
That's largely my influence - the discussion in the relevant tracker
item (http://bugs.python.org/issue6210) had covered enough ground that
I didn't notice that Ethan's
On Thu, Jan 26, 2012 at 9:18 PM, Nick Coghlan ncogh...@gmail.com wrote:
I've been burnt by too much code that replaces detailed, informative
and useful error messages that tell me exactly what is going wrong
with bland, useless garbage to be in favour of an approach that
doesn't even set the
On 1/26/2012 10:25 PM, Gregory P. Smith wrote:
(and on top of all of this I believe we're all settled on having per
interpreter hash randomization_as well_ in 3.3; but this AVL tree
approach is one nice option for a backport to fix the major
vulnerability)
If the tree code cures the problem,
