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
> >>>
[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.
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?
>>
>> T
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 revi
> 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
Re
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
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, tackl
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
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 bef
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 additio
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 exemplar
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 ex
12 matches
Mail list logo
