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 weren't found by review nor by tests. Though that was admittedly a long time. Still, such a project can really sap reviewer resources for relatively little benefit. On Thu, Jul 10, 2014 at 12:59 PM, Brett Cannon wrote:

[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 some unforeseen technical problem which stalled development?

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_ho... -- went through and updated the stdlib to follow the new practices introduced in the two PEPs. Not sure if there was some policy decision made that updating the code wasn't worth it or people simply didn't get around to applying the patches.

-Brett

...

For these and any other open issues if you need some Windows testing doing please feel free to put me on the nosy list and ask for a test run.

-- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language.

Mark Lawrence

--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ brett%40python.org

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

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 stalled development?

I tried to bring some sanity to that effort by opening a "meta issue":

http://bugs.python.org/issue15787

My enthusiasm, however, vanished after I reviewed the refactoring for the datetime module:

http://bugs.python.org/issue15390

My main objections are to following PEP 384 (Stable ABI) within stdlib modules. I see little benefit for the stdlib (which is shipped fresh with every new version of Python) from following those guidelines.

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*. For example, the docs problem, where it's hard to tell whether an API is part of the stable ABI or not, or the performance problem Stefan mentions. 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 otherwise supporting the limited API is easier than supporting the whole thing). Cheers, Nick.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

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 otherwise supporting the limited API is easier than supporting the whole thing).

There are two features to be gained for the standard library from that A. with proper module shutdown support, it will be possible to release objects that are currently held in C global/static variables, as the C global variables will go away. This, in turn, is a step forward in the desire to allow for proper leak-free interpreter shutdown, and in the desire to base interpreter shutdown on GC. B. with proper use of heap types (instead of the static type objects), support for the multiple-interpreter feature will be improved, since type objects will be per-interpreter, instead of being global. This, in turn, is desirable since otherwise state changes can leak from one interpreter to the other. So I still maintain that the change is desirable even for the standard library. Regards, Martin

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 against ABI-related changes in principle, but I think these changes should be carefully considered on a case by case basis and not applied wholesale.