A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2019-February/156370.html below:

[Python-Dev] Making PyInterpreterState an opaque type

[Python-Dev] Making PyInterpreterState an opaque type [Python-Dev] Making PyInterpreterState an opaque typeJeroen Demeyer J.Demeyer at UGent.be
Tue Feb 19 05:29:08 EST 2019
On 2019-02-19 04:04, Steve Dower wrote:
> On 18Feb.2019 1324, Jeroen Demeyer wrote:
>> For a very concrete example, was it really necessary to put
>> _PyTuple_ITEMS in (4)? That's used in _functoolsmodule.c. Especially
>> given that the very similar PySequence_Fast_ITEMS is in (2), that seems
>> like a strange and arbitrary limiting choice.
>
> The reason to do this is that we can "guarantee" that we've fixed all
> users when we change the internal representation.

I think that CPython should then at least "eat its own dog food" and 
don't use any of the internal functions/macros when implementing the 
stdlib. As I said before: if a function/macro is useful for implementing 
stdlib functionality like "functools" or "json", it's probably useful 
for external modules too.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4