On 14 Jul 2014 11:41, "Brett Cannon" wrote:
>
>
> I agree for PEP 3121 which is the initialization/finalization work. The
stable ABi is not necessary. So maybe we should re-examine the patches and
accept the bits that clean up init/finalization and leave out any
ABi-related changes.
Martin's rig
On Mon, Jul 14, 2014 at 11:41 AM, Brett Cannon wrote:
> So maybe we should re-examine the patches and accept the bits that clean
> up init/finalization and leave out any ABI-related changes.
This is precisely what I suggested two years ago.
http://bugs.python.org/issue15390#msg170249
I am not
On Mon Jul 14 2014 at 11:27:34 AM, "Martin v. Löwis"
wrote:
> Am 12.07.14 17:19, schrieb Nick Coghlan:
> > Using the stable ABI for standard library extensions also serves to
> > decouple them further from the internal details of the CPython runtime,
> > making it more likely they will be able to
Am 12.07.14 17:19, schrieb Nick Coghlan:
> Using the stable ABI for standard library extensions also serves to
> decouple them further from the internal details of the CPython runtime,
> making it more likely they will be able to run correctly on alternative
> interpreters (since emulating or other
On Sat, Jul 12, 2014 at 11:19 AM, Nick Coghlan wrote:
> The main downside of "do as we say, not as we do" in this case is that we
> miss out on the feedback loop of what the stable ABI is like to *use*.
I good start for improving the situation would be to convert the extension
module templates
On 10 Jul 2014 19:59, "Alexander Belopolsky"
wrote:
>
>
> On Thu, Jul 10, 2014 at 2:59 PM, Mark Lawrence
wrote:
>>
>> I'm just curious as to why there are 54 open issues after both of these
PEPs have been accepted and 384 is listed as finished. Did we hit some
unforeseen technical problem which
Brett Cannon wrote:
> No, the PEPs were fine and were accepted properly. A huge portion of the open
> issues are from Robin Schreiber who as part of GSoC 2012 -- https://
> www.google-melange.com/gsoc/project/details/google/gsoc2012/robin_hood/
> 5668600916475904 -- went through and updated the st
On 07/10/2014 04:57 PM, Alexander Belopolsky wrote:
On Thu, Jul 10, 2014 at 2:59 PM, Mark Lawrence wrote:
I'm just curious as to why there are 54 open issues after both of
these PEPs have been accepted and 384 is listed as finished. Did
we hit some unforeseen technical problem which stalled d
On Thu, Jul 10, 2014 at 2:59 PM, Mark Lawrence
wrote:
> I'm just curious as to why there are 54 open issues after both of these
> PEPs have been accepted and 384 is listed as finished. Did we hit some
> unforeseen technical problem which stalled development?
I tried to bring some sanity to tha
I don't know the details, but I suspect that was the result of my general
guideline "don't start projects cleaning up lots of stdlib code just to
satisfy some new style rule or just to use a new API" -- which came from
hard-won experience where such a cleanup project introduced some new bugs
that w
[for those that don't know, 3121 is extension module inti/finalization and
384 is the stable ABI]
On Thu Jul 10 2014 at 3:47:03 PM, Mark Lawrence
wrote:
> I'm just curious as to why there are 54 open issues after both of these
> PEPs have been accepted and 384 is listed as finished. Did we hit
I'm just curious as to why there are 54 open issues after both of these
PEPs have been accepted and 384 is listed as finished. Did we hit some
unforeseen technical problem which stalled development?
For these and any other open issues if you need some Windows testing
doing please feel free to
Andrew Svetlov wrote:
> Maybe it's good point to update PEP?
> "accepted; may not be implemented yet" sounds a bit confusing.
That's the status though - the PEP is accepted, implementation is ongoing.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
-
What real status of this document?
As I figured out py3k trunk uses this ones.
Most part of 'battery included' modules don't use this feature,
leaving m_traverse, m_clear and m_free NULL pointers.
There are only exception: _io.
But looks like all underground python machinery is already ported to
Hi,
In the mailing list archive I see a message that this PEP was
implemented, dated June 10. However, while everything else PEP
describes does seem to be in SVN, I cannot find PyType_Copy().
Is this function still planned for Python 3000, or are there
any simple alternatives? Or are modules jus
15 matches
Mail list logo
