Mailman 3 October 2021 - Python-Dev

PEP 670: Convert macros to functions in the Python C API
by Victor Stinner Nov. 24, 2021

Nov. 24, 2021

Hi, Erlend and me wrote a PEP to move away from macros in the Python C API. We are now waiting for feedback :-) Read the PEP online: https://www.python.org/dev/peps/pep-0670/ There is a copy of the PEP below for inline replies. Victor --- PEP: 670 Title: Convert macros to functions in the Python C API Author: Erlend Egeberg Aasland <erlend.aasland(a)protonmail.com>, Victor Stinner <vstinner(a)python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 19-Oct-2021 Python-Version: 3.11 Abstract ======== Convert macros to static inline functions or regular functions. Remove the return value of macros having a return value, whereas they should not, to aid detecting bugs in C extensions when the C API is misused. Some function arguments are still cast to ``PyObject*`` to prevent emitting new compiler warnings. Rationale ========= The use of macros may have unintended adverse effects that are hard to avoid, even for experienced C developers. Some issues have been known for years, while others have been discovered recently in Python. Working around macro pitfalls makes the macro coder harder to read and to maintain. Converting macros to functions has multiple advantages: * By design, functions don't have macro pitfalls. * Arguments type and return type are well defined. * Debuggers and profilers can retrieve the name of inlined functions. * Debuggers can put breakpoints on inlined functions. * Variables have a well defined scope. * Code is usually easier to read and to maintain than similar macro code. Functions don't need the following workarounds for macro pitfalls: * Add parentheses around arguments. * Use line continuation characters if the function is written on multiple lines. * Add commas to execute multiple expressions. * Use ``do { ... } while (0)`` to write multiple statements. Converting macros and static inline functions to regular functions makes these regular functions accessible to projects which use Python but cannot use macros and static inline functions. Macro Pitfalls ============== The `GCC documentation <https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html>`_ lists several common macro pitfalls: - Misnesting - Operator precedence problems - Swallowing the semicolon - Duplication of side effects - Self-referential macros - Argument prescan - Newlines in arguments Performance and inlining ======================== Static inline functions is a feature added to the C99 standard. Modern C compilers have efficient heuristics to decide if a function should be inlined or not. When a C compiler decides to not inline, there is likely a good reason. For example, inlining would reuse a register which require to save/restore the register value on the stack and so increase the stack memory usage or be less efficient. Debug build ----------- When Python is built in debug mode, most compiler optimizations are disabled. For example, Visual Studio disables inlining. Benchmarks must not be run on a Python debug build, only on release build: using LTO and PGO is recommended for reliable benchmarks. PGO helps the compiler to decide if function should be inlined or not. Force inlining -------------- The ``Py_ALWAYS_INLINE`` macro can be used to force inlining. This macro uses ``__attribute__((always_inline))`` with GCC and Clang, and ``__forceinline`` with MSC. So far, previous attempts to use ``Py_ALWAYS_INLINE`` didn't show any benefit and were abandoned. See for example: `bpo-45094 <https://bugs.python.org/issue45094>`_: "Consider using ``__forceinline`` and ``__attribute__((always_inline))`` on static inline functions (``Py_INCREF``, ``Py_TYPE``) for debug build". When the ``Py_INCREF()`` macro was converted to a static inline functions in 2018 (`commit <https://github.com/python/cpython/commit/2aaf0c12041bcaadd7f2cc5a54450eefd7…>`__), it was decided not to force inlining. The machine code was analyzed with multiple C compilers and compiler options: ``Py_INCREF()`` was always inlined without having to force inlining. The only case where it was not inlined was the debug build. See discussion in the `bpo-35059 <https://bugs.python.org/issue35059>`_: "Convert ``Py_INCREF()`` and ``PyObject_INIT()`` to inlined functions". Disable inlining ---------------- On the other side, the ``Py_NO_INLINE`` macro can be used to disable inlining. It is useful to reduce the stack memory usage. It is especially useful on a LTO+PGO build which is more aggressive to inline code: see `bpo-33720 <https://bugs.python.org/issue33720>`_. The ``Py_NO_INLINE`` macro uses ``__attribute__ ((noinline))`` with GCC and Clang, and ``__declspec(noinline)`` with MSC. Specification ============= Convert macros to static inline functions ----------------------------------------- Most macros should be converted to static inline functions to prevent `macro pitfalls`_. The following macros should not be converted: * Empty macros. Example: ``#define Py_HAVE_CONDVAR``. * Macros only defining a number, even if a constant with a well defined type can better. Example: ``#define METH_VARARGS 0x0001``. * Compatibility layer for different C compilers, C language extensions, or recent C features. Example: ``#define Py_ALWAYS_INLINE __attribute__((always_inline))``. Convert static inline functions to regular functions ---------------------------------------------------- The performance impact of converting static inline functions to regular functions should be measured with benchmarks. If there is a significant slowdown, there should be a good reason to do the conversion. One reason can be hiding implementation details. Using static inline functions in the internal C API is fine: the internal C API exposes implemenation details by design and should not be used outside Python. Cast to PyObject* ----------------- When a macro is converted to a function and the macro casts its arguments to ``PyObject*``, the new function comes with a new macro which cast arguments to ``PyObject*`` to prevent emitting new compiler warnings. So the converted functions still accept pointers to structures inheriting from ``PyObject`` (ex: ``PyTupleObject``). For example, the ``Py_TYPE(obj)`` macro casts its ``obj`` argument to ``PyObject*``:: #define _PyObject_CAST_CONST(op) ((const PyObject*)(op)) static inline PyTypeObject* _Py_TYPE(const PyObject *ob) { return ob->ob_type; } #define Py_TYPE(ob) _Py_TYPE(_PyObject_CAST_CONST(ob)) The undocumented private ``_Py_TYPE()`` function must not be called directly. Only the documented public ``Py_TYPE()`` macro must be used. Later, the cast can be removed on a case by case basis, but that is out of scope for this PEP. Remove the return value ----------------------- When a macro is implemented as an expression, it has an implicit return value. In some cases, the macro must not have a return value and can be misused in third party C extensions. See `bpo-30459 <https://bugs.python.org/issue30459>`_ for the example of ``PyList_SET_ITEM()`` and ``PyCell_SET()`` macros. It is not easy to notice this issue while reviewing macro code. These macros are converted to functions using the ``void`` return type to remove their return value. Removing the return value aids detecting bugs in C extensions when the C API is misused. Backwards Compatibility ======================= Removing the return value of macros is an incompatible API change made on purpose: see the `Remove the return value`_ section. Rejected Ideas ============== Keep macros, but fix some macro issues -------------------------------------- Converting macros to functions is not needed to `remove the return value`_: casting a macro return value to ``void`` also fix the issue. For example, the ``PyList_SET_ITEM()`` macro was already fixed like that. Macros are always "inlined" with any C compiler. The duplication of side effects can be worked around in the caller of the macro. People using macros should be considered "consenting adults". People who feel unsafe with macros should simply not use them. Examples of hard to read macros =============================== _Py_NewReference() ------------------ Example showing the usage of an ``#ifdef`` inside a macro. Python 3.7 macro (simplified code):: #ifdef COUNT_ALLOCS # define _Py_INC_TPALLOCS(OP) inc_count(Py_TYPE(OP)) # define _Py_COUNT_ALLOCS_COMMA , #else # define _Py_INC_TPALLOCS(OP) # define _Py_COUNT_ALLOCS_COMMA #endif /* COUNT_ALLOCS */ #define _Py_NewReference(op) ( \ _Py_INC_TPALLOCS(op) _Py_COUNT_ALLOCS_COMMA \ Py_REFCNT(op) = 1) Python 3.8 function (simplified code):: static inline void _Py_NewReference(PyObject *op) { _Py_INC_TPALLOCS(op); Py_REFCNT(op) = 1; } PyObject_INIT() --------------- Example showing the usage of commas in a macro. Python 3.7 macro:: #define PyObject_INIT(op, typeobj) \ ( Py_TYPE(op) = (typeobj), _Py_NewReference((PyObject *)(op)), (op) ) Python 3.8 function (simplified code):: static inline PyObject* _PyObject_INIT(PyObject *op, PyTypeObject *typeobj) { Py_TYPE(op) = typeobj; _Py_NewReference(op); return op; } #define PyObject_INIT(op, typeobj) \ _PyObject_INIT(_PyObject_CAST(op), (typeobj)) The function doesn't need the line continuation character. It has an explicit ``"return op;"`` rather than a surprising ``", (op)"`` at the end of the macro. It uses one short statement per line, rather than a single long line. Inside the function, the *op* argument has a well defined type: ``PyObject*``. References ========== * `bpo-45490 <https://bugs.python.org/issue45490>`_: [meta][C API] Avoid C macro pitfalls and usage of static inline functions (October 2021). * `What to do with unsafe macros <https://discuss.python.org/t/what-to-do-with-unsafe-macros/7771>`_ (March 2021). * `bpo-43502 <https://bugs.python.org/issue43502>`_: [C-API] Convert obvious unsafe macros to static inline functions (March 2021). Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. -- Night gathers, and now my watch begins. It shall not end until my death.

6 19

Oh wow, this is really impressive
by Steven D'Aprano Nov. 8, 2021

Nov. 8, 2021

I was using Python 3.10 and got this NameError when I mistyped a name: NameError: name 'KeyboardInterrupted' is not defined. Did you mean: 'KeyboardInterrupt'? It even works for attribute errors too. That's fantastic! This is a really amazing useability improvement, thank you everyone who was involved! I literally squeed :-) I just may spend a few days deliberately mistyping names in the REPL just to see this :-) -- Steve

4 3

September Steering Council update
by Pablo Galindo Salgado Oct. 31, 2021

Oct. 31, 2021

I’ve just published the September steering council update, also included below: https://github.com/python/steering-council/blob/main/updates/2021-09-steeri… Just as a reminder, if you have any questions or concerns, feel free to contact us or open an issue in the SC repo: https://github.com/python/steering-council *September 6* - There was no SC meeting on September 6 as it was a USA/Canada holiday (Labor Day). *September 13* - The Steering Council met with Łukasz, the Developer-in-Residence. The group discussed dealing with review requests and folks not giving Łukasz enough time to review before things are merged. - The group briefly discussed Ezio's progress as the PM for the GitHub Issues migration and that the group would meet with Ezio on the 20th of Sept. - The SC discussed the Exception Groups PEP & Nathaniel's counter-proposal. The group decided that more time was needed so they will discuss this more at their Sept 20th meeting. *September 20* - The Steering Council met with Ezio and got an update on his progress with the migration. The group and Ezio agreed that by Oct 1 the plan is to have a test repo with a subset of issues in it for a small group to test and provide feedback on. - The Steering Council discussed [PEP 654]( https://www.python.org/dev/peps/pep-0654/)( Exception Groups and except*) and after some extensive deliberation, the group decided to accept. - Thomas sent out the notification. - The Steering Council discussed [PEP 649]( https://www.python.org/dev/peps/pep-0649/)( Deferred Evaluation Of Annotations Using Descriptors) by Larry Hastings. The group decided that we have to tie the typing language to the Python language. The group discussed the potential of an informational PEP from the SC. - Pablo informed the SC that there will be a release party on Twitch for 3.10 co-organized with the people from the Python discord server. *September 27* - Steering Council met with the Developer-in-Residence for their every- other- week check-in. The group discussed what Łukasz is working on, the status of typing PEPs and CPython survey questions for the Python Developer Survey. - The SC discussed [PEP 649]( https://www.python.org/dev/peps/pep-0649/)(Deferred Evaluation Of Annotations Using Descriptors) by Larry Hastings and decided a broader discussion needed to happen with python-dev. The group is inclined to accept 649 but there is no clear path on how to handle the transition so community discussion is needed. Regards from rainy London, Pablo Galindo Salgado

1 0

Type annotations, PEP 649 and PEP 563
by Thomas Wouters Oct. 31, 2021

Oct. 31, 2021

(For visibility, posted both to python-dev and Discourse.) Over the last couple of months, ever since delaying PEP 563’s default change in 3.10 <https://mail.python.org/archives/list/python-dev@python.org/message/CLVXXPQ…>, the Steering Council has been discussing and deliberating over PEP 563 (Postponed Evaluation of Annotations) <https://www.python.org/dev/peps/pep-0563/>, PEP 649 (Deferred Evaluation Of Annotations Using Descriptors) <https://www.python.org/dev/peps/pep-0649/>, and type annotations in general. We haven’t made a decision yet, but we want to give everyone an update on where we’re at, what we’re thinking and why, see if there’s consensus on any of this, and perhaps restart the discussion around the options. First off, as Barry already mentioned in a different thread <https://mail.python.org/archives/list/python-dev@python.org/message/4TY3MVJ…>, the SC does not want to see type annotations as separate from the Python language. We don’t think it would be good to have the syntax or the semantics diverge, primarily because we don’t think users would see them as separate. Any divergence would be hard to explain in documentation, hard to reason about when reading code, and hard to delineate, to describe what is allowed where. There’s a lot of nuance in this position (it doesn’t necessarily mean that all valid syntax for typing uses has to have sensible semantics for non-typing uses), but we’ll be working on something to clarify that more, later. We also believe that the runtime uses of type annotations, which PEP 563 didn’t really anticipate, are valid uses that Python should support. If function annotations and type annotations had evolved differently, such as being strings from the start, PEP 563 might have been sufficient. It’s clear runtime uses of type annotations serve a real, sensible purpose, and Python benefits from supporting them. By and large, the SC views PEP 649 as a better way forward. If PEP 563 had never come along, it would be a fairly easy decision to accept PEP 649. We are still inclined to accept PEP 649. That would leave the consideration about what to do with PEP 563 and existing from __future__ import annotations directives. As far as we can tell, there are two reasons for code to want to use PEP 563: being able to conveniently refer to names that aren’t available until later in the code (i.e. forward references), and reducing the overhead of type annotations. If PEP 649 satisfies all of the objectives of PEP 563, is there a reason to keep supporting PEP 563’s stringified annotations? Are there any practical, real uses of stringified annotations that would not be served by PEP 649's deferred annotations? If we no longer need to support PEP 563, can we simply make from __future__ import annotations enable PEP 649? We still may want a new future import for PEP 649 as a transitory measure, but we could make PEP 563's future import mean the same thing, without actually stringifying annotations. (The reason to do this would be to reduce the combinatorial growth of the support matrix, and to simplify the implementation of the parser.) This would affect code that expects annotations to always be strings, but such code would have to be poking directly at function objects (the __annotations__ attribute), instead of using the advertised ways of getting at annotations (like typing.get_type_hints()). This question in particular is one in which the SC isn't yet of one mind. Keeping the future import and stringified annotations around is certainly an option, but we’re worried about the cost of the implementation, the support cost, and the confusion for users (specifically, it is a future import that will never become the future). If we do keep them, how long would we keep them around? Should we warn about their use? If we warn about the future import, is the noise and confusion this generates going to be worth it? If we don't warn about them, how will we ever be able to turn them off? One thing we’re thinking of specifically for the future import, and for other deprecations in Python, is to revisit the deprecation and warning policy. We think it’s pretty clear that the policy we have right now doesn’t exactly work. We used to have noisy DeprecationWarnings, which were confusing to end users when they were not in direct control of the code. We now have silent-by-default DeprecationWarnings, where the expectation is that test frameworks surface these warnings. This avoids the problem of end users being confused, but leaves the problem of the code’s dependencies triggering the warning, and thus still warns users (developers) not necessarily in a position to fix the problem, which in turn leads to them silencing the warning and moving on. We need a better way to reach the users in a position to update the code. One idea is to rely on linters and IDEs to provide this signal, possibly with a clear upgrade path for the code (e.g. a 2to3-like fixer for a specific deprecation). Support for deprecations happened to be brought up on the typing-sig mailing list not too long ago <https://mail.python.org/archives/list/typing-sig@python.org/thread/E24WTMQU…>, as an addition to the pytype type checker and hopefully others (full disclosure, Yilei is a team-mate of Thomas’s at Google). This sounds like a reasonably user-friendly approach, but it would require buy-in from linter/IDE developers, or an officially supported “Python linter” project that we control. There’s also the question of support timelines: most tooling supports a wider range of Python versions than just the two years that we use in our deprecation policy. Perhaps we need to revisit the policy, and consider deprecation timelines based on how many Python versions library developers usually want to support. The SC continues to discuss the following open questions, and we welcome your input on them: 1. Is it indeed safe to assume PEP 649 satisfies all reasonable uses of PEP 563? Are there cases of type annotations for static checking or runtime use that PEP 563 enables, which would break with PEP 649? 2. Is it safe to assume very little code would be poking directly at __annotations__ attributes of function objects; effectively, to declare them implementation details and let them not be strings even in code that currently has the annotations future import? 3. Is the performance of PEP 649 and PEP 563 similar enough that we can outright discount it as a concern? Does anyone actually care about the overhead of type annotations anymore? Are there other options to alleviate this potential issue (like a process-wide switch to turn off annotations)? 4. If we do not need to keep PEP 563 support, which would be a lot easier on code maintenance and our support matrix, do we need to warn about the semantics change? Can we silently accept (and ignore) the future import once PEP 649 is in effect? 5. If we do need a warning, how loud, and how long should it be around? At the end of the deprecation period, should the future import be an error, or simply be ignored? 6. Are there other options we haven’t thought of for dealing with deprecations like this one? Like I said, the SC isn’t done deliberating on any of this. The only decisions we’ve made so far is that we don’t see the typing language as separate from Python (and thus won’t be blanket delegating typing PEPs to a separate authority), and we don’t see type annotations as purely for static analysis use. For the whole SC, Thomas. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

8 12

Tips on C and the CPython Codebase
by Abdur-Rahmaan Janhangeer Oct. 31, 2021

Oct. 31, 2021

Greetings list, I am going to start tinkering with the Python source again (on Linux) I previously built the source etc using Visual Studio on Windows Now the EFL ui libs re-ignited my passion for C while playing with python-efl And Chris last proposal made me want to re-play with the CPython codebase I dedicate time for Open Source as a maintainer but also as a learner. So i'd like to ask so as to maximise my chances playing around with CPython - Any well grounded C tutorial to recommend? I know CPP but need a recommendation for C which is easy to follow and goes deep the C way. Or really any tutorial/s which are helpful like code styles or any series or ... - Any coding environment which you recommend? - For devs guide i know there is the official docs, and VStinner's unofficial but very helpful guide and a core dev's book published. Is there anything to know? - Any more tips around? I guess sooner or later people figure out things but i'd be very happy to have some C tips which will certainly provide a speed boost. Thanks in advance! Kind Regards, Abdur-Rahmaan Janhangeer about <https://compileralchemy.github.io/> | blog <https://www.pythonkitchen.com> github <https://github.com/Abdur-RahmaanJ> Mauritius

1 0

The list.sort(reverse=True) method not consistent with description
by Raymond Bisdorff Oct. 31, 2021

Oct. 31, 2021

Dear Python developers, The help(list) shows in a python console the following documentation string for the list.sort() method. sort(self, /, *, key=None, reverse=False) | Sort the list in ascending order and return None. | | The sort is in-place (i.e. the list itself is modified) and stable (i.e. the | order of two equal elements is **maintained**). Please notice the following inconsistency in Python3.10.0 and before of a sort(reverse=True) result: >>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd'), (3, 'e')] >>> L.sort(reverse=True) >>> L >>> [(3, 'e'), (2, 'd'), (2, 'b'), (1, 'c'), (1, 'a')] it should be: >>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd'), (3, 'e')] >>> reverseTuplesSort(L) [(3, 'e'), (2, 'b'), (2, 'd'), (1, 'a'), (1, 'c')] Same inconsistency appears when using a sorting key. Passing easily unnoticed may produce unexpected and potentially wrong ranking results. Best Regards, RB -- 50, Bvd G.-D. Charlotte L-1330 Luxembourg GD Luxembourg (Europe) (+352) 621 175 242

7 9

raising a io exception when fileno is requested on a tarfile FileInFile
by makapuf2＠gmail.com Oct. 30, 2021

Oct. 30, 2021

Hi, When you call extractfile() on a TarFile, the result is a buffered version of a _FileInFile pseudo-file. When fileno() is called on this resulting file, fileno() it not exist (understandably) and an AttributeError is raised. I would like to suggest raising an io.UnsupportedOperation instead, so that file would act more like other file-like objects.

2 1

Should the definition of an "(async) iterator" include __iter__?
by Brett Cannon Oct. 29, 2021

Oct. 29, 2021

Over in https://github.com/python/typeshed/issues/6030 I have managed to kick up a discussion over what exactly an "iterator" is. If you look at https://docs.python.org/3/library/functions.html#iter you will see the docs say it "Return[s] an iterator <https://docs.python.org/3/glossary.html#term-iterator> object." Great, but you go the glossary definition of "iterator" at https://docs.python.org/3/glossary.html#term-iterator you will see it says "[i]terators are required to have an __iter__() <https://docs.python.org/3/reference/datamodel.html#object.__iter__> method" which neither `for` nor `iter()` actually enforce. Is there something to do here? Do we loosen the definition of "iterator" to say they *should* define __iter__? Leave it as-is with an understanding that we know that it's technically inaccurate for iter() but that we want to encourage people to define __iter__? I'm assuming people don't want to change `for` and `iter()` to start requiring __iter__ be defined if we decided to go down the "remove the __aiter__ requirement" from aiter() last week. BTW all of this applies to async iterators as well.

10 26

Summary of Python tracker Issues
by Python tracker Oct. 29, 2021

Oct. 29, 2021

ACTIVITY SUMMARY (2021-10-22 - 2021-10-29) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7249 (+50) closed 50157 (+46) total 57406 (+96) Open issues with patches: 2868 Issues opened (77) ================== #45235: argparse does not preserve namespace with subparser defaults https://bugs.python.org/issue45235 reopened by paul.j3 #45396: Custom frozen modules get ignored. https://bugs.python.org/issue45396 reopened by eric.snow #45563: inspect.getframeinfo() doesn't handle frames without lineno https://bugs.python.org/issue45563 reopened by lemburg #45578: Missing tests for the dis module https://bugs.python.org/issue45578 opened by nanjekyejoannah #45580: argparse.ArgumentParser.add_mutually_exclusive_group : metavar https://bugs.python.org/issue45580 opened by AbcSxyZ #45581: [sqlite3] raise MemoryError if sqlite3_open_v2() returns SQLIT https://bugs.python.org/issue45581 opened by erlendaasland #45582: Rewrite getpath.c in Python https://bugs.python.org/issue45582 opened by steve.dower #45584: Clarifying truncating in documentation https://bugs.python.org/issue45584 opened by Arthur-Milchior #45585: Gzipping subprocess output produces invalid .gz file https://bugs.python.org/issue45585 opened by mherrmann.at #45587: argparse add_argument_group: distinguish title and description https://bugs.python.org/issue45587 opened by SelfAdjointOperator #45588: cached_method similar to cached_property to cache with classes https://bugs.python.org/issue45588 opened by martenlienen #45589: webbrowser does not handle opens under Windows WSL properly https://bugs.python.org/issue45589 opened by guido.fioravantti #45590: distutils: Upload failed (400): Invalid value for blake2_256_d https://bugs.python.org/issue45590 opened by jwilk #45592: NamespaceLoader does not implement create_module or exec_modul https://bugs.python.org/issue45592 opened by FFY00 #45593: SpooledTemporaryFile.truncate returns None https://bugs.python.org/issue45593 opened by rooter #45594: Feature Request: add EHOSTUNREACH subclass to ConnectionError https://bugs.python.org/issue45594 opened by ntc2 #45597: os.path.realpath returns invalid path for junction pointing to https://bugs.python.org/issue45597 opened by grv87 #45598: setup.py grep_headers_for() is broken by design https://bugs.python.org/issue45598 opened by christian.heimes #45599: Please officially support %G, %V and %u directives in time lib https://bugs.python.org/issue45599 opened by Raphael #45600: First sentence in docs for os.environ https://bugs.python.org/issue45600 opened by andrei.avk #45602: The grammar misses links that are present everywhere else https://bugs.python.org/issue45602 opened by Arthur-Milchior #45606: pathlib.Path.glob() does not list dangling symlink when patter https://bugs.python.org/issue45606 opened by raek #45607: Make it possible to enrich an exception's error message https://bugs.python.org/issue45607 opened by iritkatriel #45609: Specialize STORE_SUBSCR https://bugs.python.org/issue45609 opened by Dennis Sweeney #45610: Cookies with longer paths are listed before cookies with short https://bugs.python.org/issue45610 opened by IYism #45611: pprint - low width overrides depth folding https://bugs.python.org/issue45611 opened by iansedano #45613: [sqlite3] set threadsafety attribute based on default SQLite t https://bugs.python.org/issue45613 opened by erlendaasland #45614: traceback of exception with non-unicode __module__ https://bugs.python.org/issue45614 opened by iritkatriel #45615: Missing test for type of error when printing traceback for non https://bugs.python.org/issue45615 opened by iritkatriel #45616: Python Launcher Matches 3.10 instead of 3.1 https://bugs.python.org/issue45616 opened by Marsfan #45617: sys.stdin does not iterate correctly on '\r' line separator https://bugs.python.org/issue45617 opened by kbrazil #45618: Documentation builds fail with Sphinx 3.2.1 https://bugs.python.org/issue45618 opened by Maciej Olko #45619: Mentioning structural pattern matching in the list of binding https://bugs.python.org/issue45619 opened by Arthur-Milchior #45622: BlockingIOError: [Errno 11] Resource temporarily unavailable w https://bugs.python.org/issue45622 opened by florinspatar #45623: static build is broken https://bugs.python.org/issue45623 opened by egorpugin #45625: Add support for top-level await https://bugs.python.org/issue45625 opened by Fred #45626: Email part with content type message is multipart. https://bugs.python.org/issue45626 opened by jdhowroyd #45630: Dump CodeObject API for debugging https://bugs.python.org/issue45630 opened by penguin_wwy #45631: missing unittests for overlapping dest when using subparsers https://bugs.python.org/issue45631 opened by paul.j3 #45632: Strange readline save history behaviour in site.py https://bugs.python.org/issue45632 opened by doraeric #45633: Py_GT listed twice in Doc/extending/newtypes.rst https://bugs.python.org/issue45633 opened by mdk #45634: [sqlite3] don't combine error checks when adding integer const https://bugs.python.org/issue45634 opened by erlendaasland #45635: Tidy up error handling in traceback.c / python run.c https://bugs.python.org/issue45635 opened by iritkatriel #45636: Merge BINARY_*/INPLACE_* into BINARY_OP/INPLACE_OP https://bugs.python.org/issue45636 opened by brandtbucher #45637: The fallback to find the current frame in the gdb helpers fail https://bugs.python.org/issue45637 opened by pablogsal #45638: Does ccbench still require 2.6 compatibility? https://bugs.python.org/issue45638 opened by skip.montanaro #45639: Support modern image formats in MIME types https://bugs.python.org/issue45639 opened by adamkonrad #45640: Production tokens are not clickable https://bugs.python.org/issue45640 opened by Arthur-Milchior #45642: Unable to save https://bugs.python.org/issue45642 opened by craig.dowkes #45643: SIGSTKFLT is missing from the signals module on Linux https://bugs.python.org/issue45643 opened by gdr(a)garethrees.org #45644: Make json.tool soak up input before opening output for writing https://bugs.python.org/issue45644 opened by CharString #45646: Star expression in comprehension wrongly indicates to use or_e https://bugs.python.org/issue45646 opened by Arthur-Milchior #45647: "expression" is erroneous in the doc https://bugs.python.org/issue45647 opened by Arthur-Milchior #45648: Better tp_version_tag overflow checks in specializer https://bugs.python.org/issue45648 opened by kj #45649: Add tarinfo.Path https://bugs.python.org/issue45649 opened by FFY00 #45650: cgitb does not emit CGI headers when format='text' https://bugs.python.org/issue45650 opened by kierdavis #45651: -X frozen_modules not defaulting to "off" on Windows when runn https://bugs.python.org/issue45651 opened by eric.snow #45652: co_filename does not match __file__ for frozen stdlib modules https://bugs.python.org/issue45652 opened by eric.snow #45653: Freeze the encodings module. https://bugs.python.org/issue45653 opened by eric.snow #45654: Freeze the runpy module. https://bugs.python.org/issue45654 opened by eric.snow #45656: argparse bug: prefix_chars argument to add_argument_group does https://bugs.python.org/issue45656 opened by samwyse #45658: Implement FrozenImporter.get_source() https://bugs.python.org/issue45658 opened by eric.snow #45659: Add FrozenImporter.get_filename(). https://bugs.python.org/issue45659 opened by eric.snow #45660: Freeze the argparse module. https://bugs.python.org/issue45660 opened by eric.snow #45661: [meta] Freeze commonly used stdlib modules. https://bugs.python.org/issue45661 opened by eric.snow #45662: Incorrect repr of InitVar of a type alias https://bugs.python.org/issue45662 opened by serhiy.storchaka #45663: is_dataclass() does not work for dataclasses which are subclas https://bugs.python.org/issue45663 opened by serhiy.storchaka #45664: resolve_bases() and new_class() do not work with type alias of https://bugs.python.org/issue45664 opened by serhiy.storchaka #45665: Problems caused by isinstance(list[int], type) returning True https://bugs.python.org/issue45665 opened by serhiy.storchaka #45666: Warning: "'swprintf' : format string '%s' requires an argument https://bugs.python.org/issue45666 opened by sobolevn #45667: Better error message on failing to create a venv due to failin https://bugs.python.org/issue45667 opened by mdk #45668: Some PGO tests are failing when building with --enable-optimiz https://bugs.python.org/issue45668 opened by christian.heimes #45669: An 'ascii_alphanumerics' variable is missing in the 'strings' https://bugs.python.org/issue45669 opened by pauloxnet #45670: New .mapping attribute is broken for some existing uses of dic https://bugs.python.org/issue45670 opened by jab #45671: str(CancelledError()) is empty https://bugs.python.org/issue45671 opened by lilydjwg #45672: Mutation tests results of typing.py https://bugs.python.org/issue45672 opened by sobolevn #45673: argparse error with option with optional value https://bugs.python.org/issue45673 opened by paolobenve Most recent 15 issues with no replies (15) ========================================== #45673: argparse error with option with optional value https://bugs.python.org/issue45673 #45670: New .mapping attribute is broken for some existing uses of dic https://bugs.python.org/issue45670 #45669: An 'ascii_alphanumerics' variable is missing in the 'strings' https://bugs.python.org/issue45669 #45668: Some PGO tests are failing when building with --enable-optimiz https://bugs.python.org/issue45668 #45667: Better error message on failing to create a venv due to failin https://bugs.python.org/issue45667 #45666: Warning: "'swprintf' : format string '%s' requires an argument https://bugs.python.org/issue45666 #45664: resolve_bases() and new_class() do not work with type alias of https://bugs.python.org/issue45664 #45663: is_dataclass() does not work for dataclasses which are subclas https://bugs.python.org/issue45663 #45662: Incorrect repr of InitVar of a type alias https://bugs.python.org/issue45662 #45660: Freeze the argparse module. https://bugs.python.org/issue45660 #45656: argparse bug: prefix_chars argument to add_argument_group does https://bugs.python.org/issue45656 #45652: co_filename does not match __file__ for frozen stdlib modules https://bugs.python.org/issue45652 #45651: -X frozen_modules not defaulting to "off" on Windows when runn https://bugs.python.org/issue45651 #45650: cgitb does not emit CGI headers when format='text' https://bugs.python.org/issue45650 #45648: Better tp_version_tag overflow checks in specializer https://bugs.python.org/issue45648 Most recent 15 issues waiting for review (15) ============================================= #45669: An 'ascii_alphanumerics' variable is missing in the 'strings' https://bugs.python.org/issue45669 #45668: Some PGO tests are failing when building with --enable-optimiz https://bugs.python.org/issue45668 #45666: Warning: "'swprintf' : format string '%s' requires an argument https://bugs.python.org/issue45666 #45664: resolve_bases() and new_class() do not work with type alias of https://bugs.python.org/issue45664 #45663: is_dataclass() does not work for dataclasses which are subclas https://bugs.python.org/issue45663 #45662: Incorrect repr of InitVar of a type alias https://bugs.python.org/issue45662 #45648: Better tp_version_tag overflow checks in specializer https://bugs.python.org/issue45648 #45646: Star expression in comprehension wrongly indicates to use or_e https://bugs.python.org/issue45646 #45644: Make json.tool soak up input before opening output for writing https://bugs.python.org/issue45644 #45643: SIGSTKFLT is missing from the signals module on Linux https://bugs.python.org/issue45643 #45640: Production tokens are not clickable https://bugs.python.org/issue45640 #45639: Support modern image formats in MIME types https://bugs.python.org/issue45639 #45637: The fallback to find the current frame in the gdb helpers fail https://bugs.python.org/issue45637 #45636: Merge BINARY_*/INPLACE_* into BINARY_OP/INPLACE_OP https://bugs.python.org/issue45636 #45634: [sqlite3] don't combine error checks when adding integer const https://bugs.python.org/issue45634 Top 10 most discussed issues (10) ================================= #45548: Update Modules/Setup https://bugs.python.org/issue45548 23 msgs #44828: tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 M https://bugs.python.org/issue44828 14 msgs #45588: cached_method similar to cached_property to cache with classes https://bugs.python.org/issue45588 13 msgs #30082: hide command prompt when using subprocess.Popen with shell=Fal https://bugs.python.org/issue30082 10 msgs #45618: Documentation builds fail with Sphinx 3.2.1 https://bugs.python.org/issue45618 9 msgs #43656: TracebackException or StackSummary.extract with capture_locals https://bugs.python.org/issue43656 8 msgs #45113: [subinterpreters][C API] Add a new function to create PyStruct https://bugs.python.org/issue45113 8 msgs #45545: chdir __exit__ is not safe https://bugs.python.org/issue45545 7 msgs #45356: Calling `help` executes @classmethod @property decorated metho https://bugs.python.org/issue45356 5 msgs #45524: Cross-module dataclass inheritance breaks get_type_hints https://bugs.python.org/issue45524 5 msgs Issues closed (45) ================== #2733: mmap resize fails on anonymous memory https://bugs.python.org/issue2733 closed by tim.golden #14170: print unicode string error in win8 cmd console https://bugs.python.org/issue14170 closed by tim.golden #17569: urllib2 urlopen truncates https pages after 32768 characters https://bugs.python.org/issue17569 closed by iritkatriel #24151: test_pydoc fails https://bugs.python.org/issue24151 closed by ned.deily #28737: Document that tp_dealloc handler must call PyObject_GC_UnTrack https://bugs.python.org/issue28737 closed by lukasz.langa #31594: Make bytes and bytearray maketrans accept dictionaries as firs https://bugs.python.org/issue31594 closed by iritkatriel #39679: functools: singledispatchmethod doesn't work with classmethod https://bugs.python.org/issue39679 closed by lukasz.langa #40210: ttk.Combobox focus-out event inheritage https://bugs.python.org/issue40210 closed by iritkatriel #40915: multiple problems with mmap.resize() in Windows https://bugs.python.org/issue40915 closed by tim.golden #45020: Freeze all modules imported during startup. https://bugs.python.org/issue45020 closed by eric.snow #45305: Unexpected record of call_args_list when passing mutable objec https://bugs.python.org/issue45305 closed by andrei.avk #45355: Use sizeof(_Py_CODEUNIT) instead of literal 2 for the size of https://bugs.python.org/issue45355 closed by serhiy.storchaka #45388: Use JUMP_FORWARD for all forward jumps. https://bugs.python.org/issue45388 closed by Mark.Shannon #45395: Frozen stdlib modules are discarded if custom frozen modules a https://bugs.python.org/issue45395 closed by eric.snow #45438: inspect not capturing type annotations created by __class_geti https://bugs.python.org/issue45438 closed by serhiy.storchaka #45502: Fix test_shelve and make it discoverable https://bugs.python.org/issue45502 closed by serhiy.storchaka #45504: [argparse] Entering a partial config_parser flag works with su https://bugs.python.org/issue45504 closed by paul.j3 #45506: Out of source tree builds failing on main - test_importlib oth https://bugs.python.org/issue45506 closed by gregory.p.smith #45530: Improve listobject.c's unsafe_tuple_compare() https://bugs.python.org/issue45530 closed by tim.peters #45562: python -d creates lots of tokenizer messages https://bugs.python.org/issue45562 closed by pablogsal #45566: dataclasses��s `test_frozen_pickle` does not use all possible https://bugs.python.org/issue45566 closed by eric.smith #45571: Modules/makesetup uses wrong CFLAGS for *shared* https://bugs.python.org/issue45571 closed by christian.heimes #45574: Warning: ��print_escape�� defined but not used https://bugs.python.org/issue45574 closed by pablogsal #45579: [list.append(i) for i in list] causes high resources usage https://bugs.python.org/issue45579 closed by rhettinger #45583: Documentation of int() in datamodel.rst is out of date https://bugs.python.org/issue45583 closed by lukasz.langa #45586: Use starred expressions in subscripts https://bugs.python.org/issue45586 closed by Dennis Sweeney #45591: PathFinder does not find namespace packages children https://bugs.python.org/issue45591 closed by FFY00 #45595: [Build] Make extensions depend on header files https://bugs.python.org/issue45595 closed by christian.heimes #45596: Python opens the ./<string> file on exception while using -c https://bugs.python.org/issue45596 closed by iritkatriel #45601: test_tk and test_ttk_guionly fail with resource not availiable https://bugs.python.org/issue45601 closed by zach.ware #45603: [Windows] account privileges and updating Python packages https://bugs.python.org/issue45603 closed by eryksun #45604: multiprocessing.log_to_stderr missing documentation for parame https://bugs.python.org/issue45604 closed by lukasz.langa #45605: Return False from __contains__ method if object not hashable f https://bugs.python.org/issue45605 closed by serhiy.storchaka #45608: [sqlite3] some DB-API attributes are undocumented https://bugs.python.org/issue45608 closed by lukasz.langa #45612: [doc] add sqlite3 module docstring https://bugs.python.org/issue45612 closed by lukasz.langa #45620: A misleading url in 'Floating Point Arithmetic' page https://bugs.python.org/issue45620 closed by eric.smith #45621: Small fixes to mmap https://bugs.python.org/issue45621 closed by tim.golden #45624: test_graphlib.py depends on iteration order of sets https://bugs.python.org/issue45624 closed by lukasz.langa #45627: OpenSSL 1.1.1 still implements some disable-flags for Blake2, https://bugs.python.org/issue45627 closed by Alexandru Ardelean #45628: TimedRotatingFileHandler backupCount not working https://bugs.python.org/issue45628 closed by vinay.sajip #45629: Tools/freeze needs tests in the test suite. https://bugs.python.org/issue45629 closed by eric.snow #45641: Error In opening a file through tkinter on macOS Monterey https://bugs.python.org/issue45641 closed by terry.reedy #45645: Deep recursion terminates script execution with no error (Wind https://bugs.python.org/issue45645 closed by steve.dower #45655: List of PEPs at top of typing docs is too long to be readable https://bugs.python.org/issue45655 closed by kj #45657: Enum behavior when values are functions https://bugs.python.org/issue45657 closed by ronpandolfi

1 0

PEP 3118 C APIs
by Joannah Nanjekye Oct. 29, 2021

Oct. 29, 2021

Last year I opened the following issues, to implement int PyObject_CopyToObject() and PyObject *PyObject_GetMemoryView(PyObject *obj). They were meant to be as part of PEP 3118, I wonder if they are worth an effort now. https://bugs.python.org/issue39835 https://bugs.python.org/issue39836 Joannah -- Best, Joannah Nanjekye *"You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program." Alan J. Perlis*

2 1