Re: [Python-Dev] Our failure at handling GSoC students

On Tue, Aug 6, 2013 at 9:26 PM, Antoine Pitrou wrote: > What didn't produce an alarm during Robin's work is that GSoC work is > done in private. Why is it done in private? //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.o

Re: [Python-Dev] Our failure at handling GSoC students

Nick Coghlan writes: > On 7 August 2013 05:26, Antoine Pitrou wrote: > > I would like to point out that we currently fail at handling GSoC > > projects and bringing them to completion. > > Agreed. I have no opinion on that statement, having not looked at the projects. > > What didn't pro

Re: [Python-Dev] a Constant addition to enum

On 7 August 2013 07:36, Eli Bendersky wrote: > On Tue, Aug 6, 2013 at 1:42 PM, Ethan Furman wrote: >> >> A question came up on stackoverflow asking about the Planet example and >> the need to have the constant G defined in the method instead of at the >> class level: >> >> http://stackoverflow.co

Re: [Python-Dev] Our failure at handling GSoC students

On 7 August 2013 05:26, Antoine Pitrou wrote: > > Hello, > > I would like to point out that we currently fail at handling GSoC > projects and bringing them to completion. Agreed. > What didn't produce an alarm during Robin's work is that GSoC work is > done in private. Therefore, other core deve

Re: [Python-Dev] (New) PEP 446: Make newly created file descriptors non-inheritable

2013/8/6 Victor Stinner : > Oh, the summary table is wrong for the "subprocess, default" line: all > inheritable handles are inherited if at least one standard stream is > replaced. I updated the PEP: - add a new section "Performances of Closing All File Descriptors" - mention a previous attempt

Re: [Python-Dev] Our failure at handling GSoC students

On Aug 6, 2013, at 3:26 PM, Antoine Pitrou wrote: > I would like to point out that we currently fail at handling GSoC > projects and bringing them to completion. In the past I have noticed the same thing with IDLE. Students and mentors act outside of the standard Python development process then

Re: [Python-Dev] Our failure at handling GSoC students

On 8/6/2013 3:26 PM, Antoine Pitrou wrote: I would like to point out that we currently fail at handling GSoC projects and bringing them to completion. One cruel example is the set of PEP 3121 / PEP 384 refactorings done by Robin Schreiber: http://bugs.python.org/issue?%40columns=id%2Cactivity%2

Re: [Python-Dev] a Constant addition to enum

On Tue, 6 Aug 2013 14:36:27 -0700 Eli Bendersky wrote: > On Tue, Aug 6, 2013 at 1:42 PM, Ethan Furman wrote: > > > A question came up on stackoverflow asking about the Planet example and > > the need to have the constant G defined in the method instead of at the > > class level: > > > > http://s

Re: [Python-Dev] a Constant addition to enum

On Tue, Aug 6, 2013 at 1:42 PM, Ethan Furman wrote: > A question came up on stackoverflow asking about the Planet example and > the need to have the constant G defined in the method instead of at the > class level: > > http://stackoverflow.com/q/**17911188/208880

Re: [Python-Dev] The Return Of Argument Clinic

On Mon, 05 Aug 2013 16:53:39 -0700 Larry Hastings wrote: > > On 08/05/2013 02:55 AM, Nick Coghlan wrote: > > On 5 August 2013 18:48, Larry Hastings wrote: > >> Question 0: How should we integrate Clinic into the build process? > > Isn't solving the bootstrapping problem the reason for checking i

[Python-Dev] a Constant addition to enum

A question came up on stackoverflow asking about the Planet example and the need to have the constant G defined in the method instead of at the class level: http://stackoverflow.com/q/17911188/208880 Since methods and descriptors are immune to enumeration my proposed solution created a Constant

Re: [Python-Dev] Our failure at handling GSoC students

On Tue, Aug 6, 2013 at 3:51 PM, Antoine Pitrou wrote: > I definitely agree, but this is part of our failure too. I'd say this is strictly our failure, not the students'. This isn't really a new problem, I don't think, though the shape of this collection of patches makes it obvious. I haven't be

Re: [Python-Dev] Our failure at handling GSoC students

On Tue, 6 Aug 2013 12:43:40 -0700 Eli Bendersky wrote: > On Tue, Aug 6, 2013 at 12:26 PM, Antoine Pitrou wrote: > > > > Hello, > > > > I would like to point out that we currently fail at handling GSoC > > projects and bringing them to completion. > > > > One cruel example is the set of PEP 3121 /

Re: [Python-Dev] Our failure at handling GSoC students

> It is also likely that the mentor gets overworked after the GSoC period is > over, > is unable to finalize the patch and push it... Given that Python development is done using a good DVCS now, it seems that if each manageable chunk of changes is done on a separate branch, the likelihood of acce

Re: [Python-Dev] Our failure at handling GSoC students

On Tue, Aug 6, 2013 at 12:26 PM, Antoine Pitrou wrote: > > Hello, > > I would like to point out that we currently fail at handling GSoC > projects and bringing them to completion. > > One cruel example is the set of PEP 3121 / PEP 384 refactorings done by > Robin Schreiber: > > http://bugs.python

[Python-Dev] Our failure at handling GSoC students

Hello, I would like to point out that we currently fail at handling GSoC projects and bringing them to completion. One cruel example is the set of PEP 3121 / PEP 384 refactorings done by Robin Schreiber: http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%

Re: [Python-Dev] unittest.TestSuite holding references to unittest.TestCase instances too long

Hi Michael, On Tue, Aug 6, 2013 at 4:25 AM, Michael Foord wrote: > unittest itself has changed so extensively since the last release of > unittest2 that I'm not sure whether a completely fresh start for unittest2 > might be needed. (Although I intend to do another bugfix release of this > version

Re: [Python-Dev] PEP 442 clarification for type hierarchies

On Tue, 06 Aug 2013 18:38:51 +0200 Stefan Behnel wrote: > Antoine Pitrou, 06.08.2013 17:49: > > Le Tue, 06 Aug 2013 17:18:59 +0200, > > Stefan Behnel a écrit : > >> If a Python class with a > >> __del__ inherits from an extension type that implements > >> tp_finalize(), then whose tp_finalize() wi

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Antoine Pitrou, 06.08.2013 17:49: > Le Tue, 06 Aug 2013 17:18:59 +0200, > Stefan Behnel a écrit : >> If a Python class with a >> __del__ inherits from an extension type that implements >> tp_finalize(), then whose tp_finalize() will be executed first? > > Then only the Python __del__ gets called.

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

Ryan, 06.08.2013 17:02: > Nice idea, but some of those may break 3rd party libraries like Boost. > Python that have their own equilavent of the Python/C API. Or Even SWIG > might experience trouble in one or two of those. Te idea is that this will be an alternative way of initialising a module tha

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

Nice idea, but some of those may break 3rd party libraries like Boost. Python that have their own equilavent of the Python/C API. Or Even SWIG might experience trouble in one or two of those. Stefan Behnel wrote: >Hi, > >let me revive and summarize this old thread. > >Stefan Behnel, 08.11.2012

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Le Tue, 06 Aug 2013 17:18:59 +0200, Stefan Behnel a écrit : > Antoine Pitrou, 06.08.2013 14:12: > > Le Mon, 05 Aug 2013 22:30:29 +0200, > > Stefan Behnel a écrit : > >> > >> Hmm, it's a bit unfortunate that tp_finalize() maps so directly to > >> __del__(), but I think this can be fixed. In any ca

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Antoine Pitrou, 06.08.2013 14:12: > Le Mon, 05 Aug 2013 22:30:29 +0200, > Stefan Behnel a écrit : >> >> Hmm, it's a bit unfortunate that tp_finalize() maps so directly to >> __del__(), but I think this can be fixed. In any case, each >> tp_finalize() function must only ever be called once, so if a

Re: [Python-Dev] The Return Of Argument Clinic

On Tue, Aug 6, 2013 at 12:59 AM, Nick Coghlan wrote: > On 6 August 2013 09:53, Larry Hastings wrote: > > On 08/05/2013 02:55 AM, Nick Coghlan wrote: > > On 5 August 2013 18:48, Larry Hastings wrote: > > > > Question 0: How should we integrate Clinic into the build process? > > > > Isn't solving

Re: [Python-Dev] PEP 442 clarification for type hierarchies

Le Mon, 05 Aug 2013 22:30:29 +0200, Stefan Behnel a écrit : > > Hmm, it's a bit unfortunate that tp_finalize() maps so directly to > __del__(), but I think this can be fixed. In any case, each > tp_finalize() function must only ever be called once, so if a subtype > inherited the tp_finalize() sl

Re: [Python-Dev] The Return Of Argument Clinic

On Mon, 05 Aug 2013 16:53:39 -0700, Larry Hastings wrote: > Let me put it this way: Which is more surprising to the person > unfamiliar with the code? That this __init__ doesn't get all the > parameters, and the base class __init__ is getting called > automatically? Or that this funny functio

Re: [Python-Dev] Make extension module initialisation more like Python module initialisation

On 6 August 2013 16:03, Stefan Behnel wrote: > Seriously, wouldn't python-dev be just fine for this? It's not like the > import system is going to be rewritten for each minor release from now on. We currently use it whenever we're doing a deep dive into import system arcana, so python-dev only ne