profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ncoghlan/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Nick Coghlan ncoghlan @tritiumdev Australia https://curiousefficiency.org @python core dev, @tritiumdev software architect

ericsnowcurrently/multi-core-python 203

Enabling CPython multi-core parallelism via subinterpreters.

jazzband/contextlib2 33

contextlib2 is a backport of the standard library's contextlib module to earlier Python versions.

jeamland/asciicompat 4

A hybrid bytes/str type for Python.

dstufft/personal-peps 1

Finished or in progress PEPs

ncoghlan/ansible-vagrant-kubernetes 1

Bootstrapping a local k8s environment with Ansible & Vagrant

ncoghlan/contextlib2 1

contextlib2 is a backport of the standard library's contextlib module to earlier Python versions.

di/peps 0

Python Enhancement Proposals

ilevkivskyi/peps 0

Python Enhancement Proposals

kushaldas/peps 0

Python Enhancement Proposals

push eventncoghlan/peps

Nick Coghlan

commit sha 51357b274479bc72855cf8db08b0771ca0cbf4b0

Mention int.to_bytes

view details

push time in 7 days

Pull request review commentpython/peps

PEP 467: Drop the bchr builtin proposal

 that ``bytes(x)`` (where ``x`` is an integer) should behave like the class methods avoids that ambiguity.  +Omitting the originally proposed builtin function+-------------------------------------------------++When submitted to the Steering Council, this PEP proposed the introduction of+a ``bchr`` builtin (with the same behaviour as ``bytes.fromint``), recreating+the ``ord``/``chr``/``unichr`` trio from Python 2 under a different naming+scheme (``ord``/``bchr``/``chr``).++The SC indicated they didn't think this functionality was needed often enough+to justify offering two ways of doing the same thing, especially when one of+those ways was a new builtin function. That part of the proposal was therefore+dropped as being redundant with the ``bytes.fromint`` alternate constructor.++Developers that use this method frequently will instead have the option to+define their own ``bchr = bytes.fromint`` aliases.+ -Open Issue: memoryview-======================+Scope limitation: memoryview+---------------------------- -Updating ``memoryview`` with these new methods is outside the scope of this PEP.+Updating ``memoryview`` with the new item retrieval methods is outside the scope+of this PEP.

This section looked weird to me when I was adding the new design discussion entry, so I tweaked it a bit:

  • it's a deliberate scope limitation, not an open issue
  • only the item retrieval methods (getbyte(), iterbytes()) potentially make sense for memory views, the alternate constructors would never be relevant
ncoghlan

comment created time in 7 days

PullRequestReviewEvent

PR opened python/peps

Reviewers
PEP 467: Drop the bchr builtin proposal

Also make it clearer that memoryview isn't an open issue for the PEP, it's explicitly outside the PEP's scope.

+27 -25

0 comment

1 changed file

pr created time in 7 days

create barnchncoghlan/peps

branch : pep-467-sc-feedback

created branch time in 7 days

PullRequestReviewEvent

Pull request review commentpython/cpython

bpo-44938: Expose PyErr_ChainExceptions in the stable API

 For convenience, some of these functions will always return a     .. versionadded:: 3.5 +.. c:function:: void PyErr_ChainExceptions(PyObject *exc, PyObject *val, PyObject *tb)++   Set the provided exception as the cause for the current exception. If there is no exception+   currently set (:c:func:`PyErr_Occurred` returns ``0``) this function behaves as like :c:func:`PyErr_Restore`, but if an exception is already set, set the context+   associated with it.++   The exception type should be a class. Do not pass an invalid exception type or value. This call+   takes away a reference to each object: you must own a reference to each object before the call+   and after the call you no longer own these references.++   .. warning::++      The caller is responsible for ensuring that this call won't create+      any cycles in the exception context chain.

As per my comment below, the easiest way to violate this requirement is to call the API without setting a new exception first (or clearing the existing one). Buggy code (using my API naming suggestion from above):

PyErr_Fetch(&type, &value, &traceback);
// Exception state is not cleared, no new exception is set
PyErr_RestoreOrChain(type, value, traceback); // Sets exception as its own context

Because the exception might not have been instantiated yet when PyErr_Fetch() is called, there's no easy way for the API to reliably detect this error, so the onus is on the caller to manage the exception state correctly.

pablogsal

comment created time in 8 days

Pull request review commentpython/cpython

bpo-44938: Expose PyErr_ChainExceptions in the stable API

 For convenience, some of these functions will always return a     .. versionadded:: 3.5 +.. c:function:: void PyErr_ChainExceptions(PyObject *exc, PyObject *val, PyObject *tb)++   Set the provided exception as the context for the current exception. If there+   is no exception currently set (:c:func:`PyErr_Occurred` returns ``0``) this+   function behaves like :c:func:`PyErr_Restore`, but if an exception is+   already set, set the provided exception as the context (accessible from+   Python through the :attr:`__context__` attribute of the exception) of the+   one that is currently set.++   The exception type should be a class. Do not pass an invalid exception type+   or value. This function steals a reference to each of its arguments in the+   same fashion as :c:func:`PyErr_Restore` does.++   .. warning::++      The caller is responsible for ensuring that this call won't create+      any cycles in the exception context chain.++   See :ref:`tut-exception-chaining` for more information regarding the+   semantics of exception chaining.++   Example usage:++   .. code-block:: c++      PyObject *type, *value, *traceback;++      /* Fetch the original exception */+      PyErr_Fetch(&type, &value, &traceback);++      /* ... code that might produce other errors ... */++      /* Set the original exception as the context for the new exception, and set the new exception as the current exception */+      PyErr_ChainExceptions(type, value, traceback);

This example is misleading, as if the code doesn't set a new exception, the fetched exception will end up being chained with itself instead of being restored. To safely invoke the new API unconditionally, the code needs to look like this:

    /* Fetch and clear the original exception */
    PyErr_Fetch(&type, &value, &traceback);
    PyErr_Clear();

    /* ... code that might produce other errors ... */

    /* Either restore the original exception, or set it as the context for any new exception */
    PyErr_RestoreOrChain(type, value, traceback);

Skipping the PyErr_Clear() call is only OK if the code definitely sets a new active exception.

pablogsal

comment created time in 8 days

Pull request review commentpython/cpython

bpo-44938: Expose PyErr_ChainExceptions in the stable API

 For convenience, some of these functions will always return a     .. versionadded:: 3.5 +.. c:function:: void PyErr_ChainExceptions(PyObject *exc, PyObject *val, PyObject *tb)++   Set the provided exception as the cause for the current exception. If there+   is no exception currently set (:c:func:`PyErr_Occurred` returns ``0``) this+   function behaves as like :c:func:`PyErr_Restore`, but if an exception is+   already set, set the provided exception as the context (accessible from+   Python through the :attr:`__context__` attribute of the exception) of the+   one that is currently set.

Given the equivalence to PyErr_Restore when no exception is currently set, my public naming suggestion would be PyErr_RestoreOrChain, with the shorthand documentation being "Restores the given exception state, or chains it as the exception context if an exception is already set".

The key point to emphasise is that the function takes the same arguments as PyErr_Restore (retrieved from a prior PyErr_Fetch call), and generally does the same thing, but handles currently set exceptions differently: instead of clearing them, it leaves them in place, and "restores" the given exception as the exception context, rather than as the active exception.

pablogsal

comment created time in 8 days

Pull request review commentpython/cpython

bpo-44938: Expose PyErr_ChainExceptions in the stable API

 For convenience, some of these functions will always return a     .. versionadded:: 3.5 +.. c:function:: void PyErr_ChainExceptions(PyObject *exc, PyObject *val, PyObject *tb)++   Set the provided exception as the cause for the current exception. If there+   is no exception currently set (:c:func:`PyErr_Occurred` returns ``0``) this+   function behaves as like :c:func:`PyErr_Restore`, but if an exception is+   already set, set the provided exception as the context (accessible from+   Python through the :attr:`__context__` attribute of the exception) of the+   one that is currently set.++   The exception type should be a class. Do not pass an invalid exception type+   or value. This function steals a reference to each of its arguments in the

~Stealing references is only common because much of the public API was born as internal APIs, and we often try to avoid redundant refcount adjustments in internal APIs.~

~It took us a long time to realise that stealing references in public APIs makes things confusing for API clients, and can easily lead to double decref bugs (which are more potentially destructive than the object leaks that can arise from missing decref bugs, since deleting objects early can lead to access violations). So I think the new public API should be a wrapper around the internal API that avoids stealing references.~

I changed my mind on this point, as PyErr_Fetch and PyErr_Restore are a matched pair. If we go with my PyErr_RestoreOrChain naming suggestion, then the refcounting semantics of the new API should match those of PyErr_Restore (which is to take back the references that PyErr_Fetch created)

pablogsal

comment created time in 8 days

PullRequestReviewEvent

issue commentjazzband/contextlib2

0.6.0.post1: pytest is failing

From the errors reported, pytest is attempting to run tests based purely on the class name, without checking whether the class actually inherits from unittest.TestCase. That's incompatible with unittest test discovery, and won't work on this test suite.

If you want to run pytest instead, you should be able to provide a pytest.ini file as described in https://stackoverflow.com/a/43349055/597742 that turns off the incorrect auto-discovery process.

kloczek

comment created time in 8 days

pull request commentpython/cpython

bpo-44800: Rename `InterpreterFrame` to `_Py_framedata`

@markshannon @ericsnowcurrently Just nudging this one for another look at the proposed naming convention (frame + frame data) before I invest time in resolving the merge conflict.

I don't really want to escalate this to Python-Dev (as the bikeshedding would potentially be epic), but I don't want to leave the status quo as is either (not only because I personally find it hard to read, but also because Mark's point about implying the existence of two kinds of frame being problematic applies just as much to the current "frame" and "interpreter frame" split as it did to my initial "introspection frames + execution frames" idea).

ncoghlan

comment created time in 13 days

push eventpython/peps

Nick Coghlan

commit sha 9db8dc3e0fde23dd3bc3e7d845b09f975a812637

PEP 558: Update PEP for implementation changes and PEP 667 (#2060) * address remaining review comments from the July threads * Rationale section renamed to Motivation * Design Discussion section renamed to Rationale and Design Discussion * kind enum is guaranteed to be at least 32 bits * fast refs mapping is stored on the underlying frame * delay initial cache refresh for each proxy instance to the first operation that needs it * be specific about which operations always update the cache, and which update it if it hasn't been updated by this proxy instance * eliminate more mentions of the old "dynamic snapshot" terminology * add new rational/discussion section covering PEP 667 (including how the PEP 558 implementation could be turned into a PEP 667 implementation if desired) * make it clearer that proxy instances are ephemeral (lots of stale phrasing with "the" dating from when they stored on the frame) Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>

view details

push time in 21 days

PR merged python/peps

PEP 558: Update PEP for implementation changes and PEP 667 CLA signed
  • address remaining review comments from the July threads
  • Rationale section renamed to Motivation
  • Design Discussion section renamed to Rationale and Design Discussion
  • kind enum is guaranteed to be at least 32 bits
  • fast refs mapping is stored on the underlying frame
  • delay initial cache refresh for each proxy instance to the first operation that needs it
  • be specific about which operations always update the cache, and which update it if it hasn't been updated by this proxy instance
  • eliminate more mentions of the old "dynamic snapshot" terminology
  • add new rationale/discussion section covering PEP 667 (including how the PEP 558 implementation could be turned into a PEP 667 implementation if desired)
  • make it clearer that proxy instances are ephemeral (lots of stale phrasing with "the" dating from when they stored on the frame)
+382 -73

0 comment

1 changed file

ncoghlan

pr closed time in 21 days

push eventncoghlan/peps

Nick Coghlan

commit sha 67c29b7bd9534d150bc2325bd16185f46d6ca692

Working cleanups and tweaks

view details

push time in 21 days

push eventncoghlan/cpython

Nick Coghlan

commit sha 2b27389f10a282901b7c78b7758691501c7e7a2f

Keep track of defined names even on cleared frames

view details

push time in 21 days

push eventncoghlan/peps

Nick Coghlan

commit sha 7b35766cf241b8032c5666e23e15cd240f05e9af

Apply suggestions from code review Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>

view details

push time in 21 days

PR opened python/peps

PEP 558: Update PEP for implementation changes and PEP 667
  • address remaining review comments from the July threads
  • Rationale section renamed to Motivation
  • Design Discussion section renamed to Rationale and Design Discussion
  • kind enum is guaranteed to be at least 32 bits
  • fast refs mapping is stored on the underlying frame
  • delay initial cache refresh for each proxy instance to the first operation that needs it
  • be specific about which operations always update the cache, and which update it if it hasn't been updated by this proxy instance
  • eliminate more mentions of the old "dynamic snapshot" terminology
  • add new rational/discussion section covering PEP 667 (including how the PEP 558 implementation could be turned into a PEP 667 implementation if desired)
  • make it clearer that proxy instances are ephemeral (lots of stale phrasing with "the" dating from when they stored on the frame)
+376 -70

0 comment

1 changed file

pr created time in 21 days

push eventncoghlan/peps

Nick Coghlan

commit sha 42489025cef2012e02eac83fdcff8503e6763095

PEP 558: Update PEP for implementation changes and PEP 667 * address remaining review comments from the July threads * Rationale section renamed to Motivation * Design Discussion section renamed to Rationale and Design Discussion * kind enum is guaranteed to be at least 32 bits * fast refs mapping is stored on the underlying frame * delay initial cache refresh for each proxy instance to the first operation that needs it * be specific about which operations always update the cache, and which update it if it hasn't been updated by this proxy instance * eliminate more mentions of the old "dynamic snapshot" terminology * add new rational/discussion section covering PEP 667 (including how the PEP 558 implementation could be turned into a PEP 667 implementation if desired) * make it clearer that proxy instances are ephemeral (lots of stale phrasing with "the" dating from when they stored on the frame)

view details

push time in 21 days

push eventncoghlan/cpython

Nick Coghlan

commit sha b587a4170179d528d7f699c2a7315c458c807db9

Force enum size

view details

Nick Coghlan

commit sha e1b505d9c4e8b9ed0f36eb8b2046f39c45c5a832

Clarify code comment

view details

push time in 24 days

create barnchncoghlan/peps

branch : pep-558-august-2021-implementation-updates

created branch time in 24 days

pull request commentpython/cpython

[PEP 558 - WIP] bpo-30744: Trace hooks no longer reset closure state

@ericsnowcurrently:

  • I think what the implementation is doing for "not yet created" cell objects aligns with what you say it should be doing. The fast refs entry for a "not yet created" cell object is like the entry for a local variable: a Python integer giving the location of the cell in the fast locals array. It is treated as an unbound name while it is in that state. However, each time it is accessed for any reason, the proxy checks to see if the cell object has been created by MAKE_CELL since the last time the proxy checked. If it has, it fixes up the fast refs entry to refer directly to that cell object instead of to the fast locals array slot. It's still only MAKE_CELL that will ever create the cell object, though - the proxy just promotes it to the fast refs mapping once it notices it has been created.
  • any extra variables that get set are still stored on the underlying frame rather than each proxy object having its own separate storage location. They're just not stored in the fast locals array - they're stored in the same locals dictionary that they're stored in now (which provides backwards compatibility and interoperability with the PyEval_GetLocals() API). That fast locals dictionary is also used to cache the name->value mapping for the fast locals, both for PyEval_GetLocals() compatibility, and to avoid having to make routine operations on the proxy (like checking how many names are currently bound to values) consistently O(n) (instead the proxy refreshes the cache the first time it needs to use it, and then after that assumes it is still up to date - since proxies are cheap to create, the easiest way to refresh them is to throw the old proxy away and make a new one, but there's also an explicit cache sync method defined)
  • yes, the proxy implementation still exposes all the surprisingly visible cell references that LocalsToFast() does, and it makes attempts to write to them actually work. As you say, doing anything else would almost certainly create a compatibility problem at this point. It does mean that calling clear() on the proxy can have more side effects than calling clear() on the frame, but that's consistent with the way PyFrame_LocalsToFast() has historically worked in tracing functions (deleting a key from f_locals would unbind it when returning from the tracing function, regardless of whether it was a local variable or a cell reference)
ncoghlan

comment created time in a month

pull request commentpython/cpython

[PEP 558 - WIP] bpo-30744: Trace hooks no longer reset closure state

I've pushed an update that resolves almost all of my own "PEP 558 TODO" items in the code (and ticked them off in the checklist above as well):

  • the proxy implements the full mutable mapping API (and this support is tested)
  • the proxy now holds off on refreshing the value cache until the first operation that assumes the value cache is up to date (so if you only access individual keys by name, you'll never trigger a full cache refresh, allowing O(1) tracing operation regardless of the number of variables on the frame)
  • the fast refs mapping is now stored on the frame object, so

I will be adding another todo item to the checklist, which is to explicitly test the handling of cleared frames. Implementing proxy.clear() exposed some inconsistencies between the established FastToLocals() logic and the proxy's behaviour when accessing cell variables via a cleared frame, but no unit tests failed when I changed the behaviour to be consistent with the FastToLocals() precedent.

For the merge conflict, I'm hoping to get https://github.com/python/cpython/pull/27525/ merged before I try to sync this branch with the main branch again. It was my first attempt at doing that which prompted me to file bpo-44800 in the first place, as it was quite unclear how the conflicts should be resolved given the currently checked in variable naming conventions.

ncoghlan

comment created time in a month

push eventncoghlan/cpython

Nick Coghlan

commit sha 31493b98315d72850f92eb1935fcc4faa99773d2

Add C API test for the LocalsToFast exception

view details

push time in a month

push eventncoghlan/cpython

Nick Coghlan

commit sha ea5f943e683c558049a81e9214dd874edd7be08b

Add dict union operations to proxy

view details

Nick Coghlan

commit sha fcf99cac737d5a046b42ba515847e41697f3da9b

Implement and test locals proxy clear() method

view details

Nick Coghlan

commit sha 16e05810d412317b8c53014b6fa0a0eae47eb90a

Remove pointless print() call

view details

Nick Coghlan

commit sha c35694981bc3c96b4dede707a476d2efd2958393

Implement proxy pop() tests

view details

Nick Coghlan

commit sha 8a4e7887cf38102cf0f3519cd1d1142c7217c0aa

Implement and test proxy popitem()

view details

Nick Coghlan

commit sha 706eec4076ae902237fa508415e81182dc7883c0

Test popitem with cells and extra variables

view details

Nick Coghlan

commit sha 35a017cfdf7697af26212d156e0111e506092e89

Implement and test setdefault()

view details

Nick Coghlan

commit sha 06c406c9338e5bfe74de50a1307ba8bdebad3a6c

Implement and test proxy __sizeof__()

view details

push time in a month

push eventncoghlan/cpython

Nick Coghlan

commit sha 67c3958c473923d548b6fdc9d7bb66fde7989e6d

Share fast_refs mapping between proxy objects

view details

Nick Coghlan

commit sha 034345fd519784f98d46c216d301b238d3068c25

Remove debugging print

view details

Nick Coghlan

commit sha 3c49ff822b8dbba18db1904caf319271d2b723ad

Defer value cache refresh until needed, start fleshing out dict API tests

view details

push time in a month

pull request commentpython/cpython

bpo-44800: Rename `InterpreterFrame` to `_Py_framedata`

Merge conflict with the new NOTRACE_DISPATCH macro resolved.

ncoghlan

comment created time in a month

push eventncoghlan/cpython

Gautam Chaudhuri

commit sha ad0a8a9c629a7a0fa306fbdf019be63c701a8028

bpo-16580: [doc] Add examples to int.to_bytes and int.from_bytes (GH-27760) * added code equivs. for to_bytes and from_bytes Based on woparry's patch[1] from the relevant issue thread[2]. [1]: https://bugs.python.org/file30372/issue16580.patch [2]: https://bugs.python.org/issue16580 Co-authored-by: Mark Dickinson <dickinsm@gmail.com>

view details

Bar Harel

commit sha 2cb1a6806c0cefab0c3a40fdd428a89a4392570e

bpo-44911: Fixed IsolatedAsyncioTestCase from throwing an exception on leaked tasks (GH-27765)

view details

Irit Katriel

commit sha 62bc716fde20fcb7b47416c7959be9e66df93212

bpo-44895: skip test_no_hang_on_context_chain_cycle2 until the refleak is fixed (GH-27761)

view details

Mark Shannon

commit sha 1a511dc92dd10ee8fc2e5da9f52f795924bdc89a

bpo-44914: Maintain invariants of type version tags. (GH-27773) * Do not invalidate type versions unnecessarily.

view details

Mark Shannon

commit sha 4f51fa9e2d3ea9316e674fb9a9f3e3112e83661c

bpo-44900: Add five superinstructions. (GH-27741) * LOAD_FAST LOAD_FAST * STORE_FAST LOAD_FAST * LOAD_FAST LOAD_CONST * LOAD_CONST LOAD_FAST * STORE_FAST STORE_FAST

view details

Łukasz Langa

commit sha a0a6d39295a30434b088f4b66439bf5ea21a3e4e

bpo-44852: Support ignoring specific DeprecationWarnings wholesale in regrtest (GH-27634)

view details

Guido van Rossum

commit sha 62bd97303eb6d1fb0109e4a57d38c2ba6b0be7ff

Fix a SystemError in code.replace() (#27771) While the comment said 'We don't bother resizing localspluskinds', this would cause .replace() to crash when it happened. (Also types.CodeType(), but testing that is tedious, and this tests all code paths.)

view details

Ken Jin

commit sha d84d2c4985457733602d46dc4ee77290da4e9539

bpo-44914: Add tests for some invariants of tp_version_tag (GH-27774)

view details

Maximilian Hils

commit sha 1512bc21d60f098a9e9f37b44a2f6a9b49a3fd4f

bpo-38956: don't print BooleanOptionalAction's default twice (GH-27672) Co-authored-by: Micky Yun Chan <michan@redhat.com>

view details

Gautam Chaudhuri

commit sha 6a358bb9482f7595b858ea7b800cbe66f0de5fa1

bpo-44903: Removed othergui.rst and list of GUI frameworks (GH-27762)

view details

Hai Shi

commit sha 3e2c643ae0b21f9e596bfd9c8ec99ca546ea8d0f

bpo-42035: Add PyType_GetQualName() to get a type's qualified name. (GH-27551)

view details

Hai Shi

commit sha fcd651d16fc5ac3d07dd3f57f1001a861a2e7d23

bpo-42035: Enhance test_get_type_name() of _testcapi (GH-27649)

view details

Ken Jin

commit sha 96346cb6d0593ef9ec122614347ccb053cd63433

bpo-44889: Specialize LOAD_METHOD with PEP 659 adaptive interpreter (GH-27722) Adds four new instructions: * LOAD_METHOD_ADAPTIVE * LOAD_METHOD_CACHED * LOAD_METHOD_MODULE * LOAD_METHOD_CLASS

view details

Dong-hee Na

commit sha c2c857b40f226575d64e0d56a759cbd799f51e62

bpo-44895: Introduce PYTHONDUMPREFSFILE variable for refcount dumping (GH-27767)

view details

Mark Dickinson

commit sha 4b9a2dcf19e5d13c3bc2afea2de1f65cd994c699

bpo-44698: Restore complex pow behaviour for small integral exponents (GH-27772)

view details

Jakub Kulík

commit sha b1930bf75f276cd7ca08c4455298128d89adf7d1

bpo-44935: enable posix_spawn() on Solaris (GH-27795) Enable posix_spawn() on Solaris

view details

Jefferson Oliveira

commit sha 599f5c8481ca258ca3a5d13eaee7d07a9103b5f2

introduce omitted index default before using it (GH-27775)

view details

meowmeowmeowcat

commit sha 3240bc62f4e0afa09964f3afc845697f0a0806b9

bpo-44508: [Doc] Document failure mode for loop.call_soon_threadsafe (GH-27688) Co-authored-by: Łukasz Langa <lukasz@langa.pl>

view details

Łukasz Langa

commit sha 8cf07d3db3eed02b43350a5f9dbf68f1c839ea82

bpo-44852: Support filtering over warnings without a set message (GH-27793) Additional improvements: - messages which were compiled regular expressions aren't unpacked back into strings for unmatched warnings; - removed unnecessary "if tokens:" check (there's one before the for loop); - took `endswith` calculation out of the for loop.

view details

Victor Stinner

commit sha 6fb62b42f4db56ed5efe0ca4c1059049276c1083

bpo-44949: Fix test_readline auto history tests (#27813)

view details

push time in a month

pull request commentpython/cpython

bpo-44800: Rename `InterpreterFrame` to `_Py_framedata`

@markshannon I have made the requested changes; please review again.

I've updated the PR title and description, since the proposal has changed based on your initial review comments.

I quite like the way the now proposed "frame" (PyFrameObject) vs "frame data" (_Py_framedata) naming convention looks in the code.

For the field prefix selection on the frame data struct, of the 12 fields, 6 didn't have a prefix at all, while 6 shared the f_ prefix with PyFrameObject. Rather than the "maximum churn" option of my original PR (which affected all 12 fields by introducing the xf_ prefix), the latest iteration instead standardises on "no field prefix" for the frame data structs.

ncoghlan

comment created time in a month