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

2013-08-07 Thread martin 

Zitat von Antoine Pitrou :



One cruel example is the set of PEP 3121 / PEP 384 refactorings done by
Robin Schreiber:


I personally dont consider it failed, yet. I still plan to integrate
them, hopefully for 3.4.


Robin has produced many patches that seem to reach the stated goal
(refactor C extension modules to take advantage of the latest PEPs
about module initialization and extension types definition).
Unfortunately, tackling both goals at the same time produces big
patches with a lot of churn; and it is also not obvious the PEP 384
refactoring is useful for the stdlib (while the PEP 3121 refactoring
definitely is).


Choice of supporting PEP 384 was deliberate. It will change all
types into heap types, which is useful for multiple-interpreter
support and GC.



What didn't produce an alarm during Robin's work is that GSoC work is
done in private.


It wasn't really done in private. Robin posted to python-dev, anybody
who would have been interested could have joined discussions.


It is also
likely that the mentor gets overworked after the GSoC period is over,
is unable to finalize the patch and push it, and other core devs have a
hard time catching up on the work and don't know what the shortcomings
are.


It's indeed unfortunate that RL interfered with my Python contributions.
I apologize for that.

However, anybody who wanted to catch up could have
contacted Robin or myself. As overworked as we all are,
nobody did.

Regards,
Martin




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-07 Thread martin 

Zitat von Eli Bendersky :



I would like to point out something that stands out in this list of issues:
such a method of producing dozens of patches simultaneously is extremely
unwise, unless there's a crucial piece of history I'm missing. It is much
more prudent to start with one or two exemplary modules, and if those fully
pass code review, send out patches for others. The reason is obvious - code
review may turn up problems or requests for change. Going backwards to
modify 57 patches is not something anyone would want to do.


Robin did exactly that: submit a few patches first, receive feedback,
submit more patches. At the end of the project,he submitted his
entire work.

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-07 Thread Alexander Belopolsky 
On Wed, Aug 7, 2013 at 4:09 AM,  wrote:

> ..
>> What didn't produce an alarm during Robin's work is that GSoC work is
>> done in private.
>>
>
> It wasn't really done in private. Robin posted to python-dev, anybody
> who would have been interested could have joined discussions.


True.  In addition, Robin's work was posted at bugs.python.org and received
reviews.


> However, anybody who wanted to catch up could have
> contacted Robin or myself. As overworked as we all are,
> nobody did.
>

Not true.  See .
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-07 Thread martin 

Zitat von Lennart Regebro :


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?


It wasn't really done in private, not more than any other contribution.
A PEP was accepted before the project even started.

Regards,
Martin




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-07 Thread Alexander Belopolsky 
On Wed, Aug 7, 2013 at 4:34 AM,  wrote:
>
> Robin did exactly that: submit a few patches first, receive feedback,
> submit more patches. At the end of the project,he submitted his
> entire work.


That's not how the history looks on the tracker.  Robin submitted ~50
patches before I suggested that "we should start with the "xx" modules."
 Then he did submit patches to the example modules, but have never
responded to my reviews.

http://bugs.python.org/issue15787
http://bugs.python.org/issue15848
http://bugs.python.org/issue15849
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-07 Thread Antoine Pitrou 
Le Wed, 07 Aug 2013 10:09:16 +0200,
mar...@v.loewis.de a écrit :
> 
> > Robin has produced many patches that seem to reach the stated goal
> > (refactor C extension modules to take advantage of the latest PEPs
> > about module initialization and extension types definition).
> > Unfortunately, tackling both goals at the same time produces big
> > patches with a lot of churn; and it is also not obvious the PEP 384
> > refactoring is useful for the stdlib (while the PEP 3121 refactoring
> > definitely is).
> 
> Choice of supporting PEP 384 was deliberate. It will change all
> types into heap types, which is useful for multiple-interpreter
> support and GC.

If I'm not mistaken, static C types shouln't benefit much from GC,
since they only reference C functions.
Also, PyType_FromSpec() makes reference counting delicate when
subclasses are allowed.

> > What didn't produce an alarm during Robin's work is that GSoC work
> > is done in private.
> 
> It wasn't really done in private. Robin posted to python-dev, anybody
> who would have been interested could have joined discussions.

I'm sorry if I misremembered how things happened. However, it's clear
that the produced patches (including their number) cause problems for
reviewers, and very few of them have been integrated.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-07 Thread Ethan Furman 

On 08/07/2013 01:54 AM, Alexander Belopolsky wrote:


That's not how the history looks on the tracker.  Robin submitted ~50 patches before 
I suggested that "we should start
with the "xx" modules."  Then he did submit patches to the example modules, but 
have never responded to my reviews.


Dumb question, but does he know how to publish his responses?  It took me a week to figure that out.  Of course, it 
would be up to him to ask why his responses weren't being acknowledged.  (I'm speaking of the reitvald tool.)


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-07 Thread Victor Stinner 
> Also the socket library creates sockets with inheritable handles by
default.  Apparently there isn't a reliable way to make sockets
non-inheritable because anti-virus/firewall software can interfere:
>
>
http://stackoverflow.com/questions/12058911/can-tcp-socket-handles-be-set-not-inheritable

Recent versions of Windows provide an atomic flag to create a
non-inheritable socket. I hope that the falg is respected even with
antivirus/firewall.

For older versions of Windows, I don't see what Python can do. Is it a
blocker point for the PEP?

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-07 Thread Alexander Belopolsky 
On Wed, Aug 7, 2013 at 1:12 PM, Ethan Furman  wrote:
>
> Dumb question, but does he know how to publish his responses?  ... (I'm
speaking of the reitvald tool.)


The patches that I reviewed: #15390 (datetime), #15848 (xxsubtype), and
 #15849 (xxmodule) did not have Reitvald "review" links.  I reviewed them
in the tracker comments.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-07 Thread Stefan Behnel 
Stefan Behnel, 06.08.2013 18:38:
> 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. It should call
>> super().__del__() manually, to ensure the extension type's
>> tp_finalize gets called.
> 
> Ok, but then all I have to do in order to disable C level finalisation for
> a type is to inherit from it and provide an empty __del__ method.

Oh, and if the Python subtype calls super().__del__() twice, then there is
no longer a guarantee that the finalisers only get executed once, right?

I think it's time for at least a very visible warning in the docs that the
behaviour is only 'guaranteed' for types that cannot be subtyped from
Python, and that Python subtypes are free to break up the call chain in
whatever way they like.

Stefan


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] xml.etree.ElementTree.IncrementalParser (was: ElementTree iterparse string)

2013-08-07 Thread Stefan Behnel 
[from python-ideas]

Antoine Pitrou, 07.08.2013 08:04:
> Take a look at IncrementalParser:
> http://docs.python.org/dev/library/xml.etree.elementtree.html#incremental-parsing

Hmm, that seems to be a somewhat recent addition (April 2013). I would have
preferred hearing about it before it got added.

I don't like the fact that it adds a second interface to iterparse() that
allows injecting arbitrary content into the parser. You can now run
iterparse() to read from a file, and at an arbitrary iteration position,
send it a byte string to parse from, before it goes reading more data from
the file. Or take out some events before iteration continues.

I think the implementation should be changed to make iterparse() return
something that wraps an IncrementalParser, not something that is an
IncrementalParser.

Also, IMO it should mimic the interface of the TreeBuilder, which calls the
data reception method "data()" and the termination method "close()". There
is no reason to add yet another set of methods names just to do what others
do already.

Stefan


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-07 Thread Antoine Pitrou 
On Thu, 08 Aug 2013 06:08:55 +0200
Stefan Behnel  wrote:
> Stefan Behnel, 06.08.2013 18:38:
> > 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. It should call
> >> super().__del__() manually, to ensure the extension type's
> >> tp_finalize gets called.
> > 
> > Ok, but then all I have to do in order to disable C level finalisation for
> > a type is to inherit from it and provide an empty __del__ method.
> 
> Oh, and if the Python subtype calls super().__del__() twice, then there is
> no longer a guarantee that the finalisers only get executed once, right?

The guarantee is that the *interpreter* will call __del__ once. You're
free to call it many times yourself, it's just a method.
(but super() itself is supposed to do the right thing, if you're using
it properly)

And, by the way, I'd like to stress again the parallel with __init__:
tp_init can also be called several times if the user calls __init__
manually.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com