[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API
As someone who maintains a debugger that uses private api’s, I’d like to see some commitment to seeing them not change in micro releases such as 3.11.1 -> 3.11.2. Micro releases should be compatible with other micro releases of the same major.minor release such as 3.11 so that an extension compiled against 3.11.1 will work with 3.11.2. Compatibility was broken (at least) once in a 2.x series (maybe 2.4?) and we started getting reports of people using 2.x.0 were having problems. Fortunately, in that case compiling against 2.x.0 produced an extension that worked against all micro releases. Note that I’m not asking for private api’s not change in major.micro releases such as 3.10 -> 3.11. I know that there can be very good reasons to change private api's because that I probably will have work to do in order to support a new major.micro release. I also don’t think that exposing everything that every extension needs with a non-private api is a good idea because then the internals will be more difficult to change — you’d be signing up to support that api for all future major.micro versions until there’s a compatibility break. John > On Mar 30, 2022, at 11:01 AM, Victor Stinner wrote: > > The internal C API can be used on purpose. But there is no backward > compatibility warranty and it can change anytime. In practice, usually > it only changes in 3.x.0 releases. For example, these private C API > changed in Python 3.9 and Python 3.11 (see my first email in the other > PEP 523 thread). > > To use the internal C API, you have to declare the Py_BUILD_CORE macro > and include an internal C API header file. For > _PyInterpreterState_SetEvalFrameFunc(), it should be: > > #ifndef Py_BUILD_CORE_MODULE > # define Py_BUILD_CORE_MODULE > #endif > #include > #include // _PyInterpreterState_SetEvalFrameFunc() > #include // _PyEval_EvalFrameDefault > > Victor > > On Tue, Mar 29, 2022 at 12:26 AM Jason Ansel via Python-Dev > wrote: >> >> The PyTorch team plans to use PEP 523 as a part of PyTorch 2.0, so this >> proposal may break the next major release of PyTorch. >> >> The related project is TorchDynamo, which can be found here: >> https://github.com/facebookresearch/torchdynamo >> >> We will likely move this into the core of PyTorch closer to release. >> >> If the changed happens, would PyTorch still be able to use the eval frame >> API? Or would it prevent from being used entirely? >> ___ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/RVQ7LDIJ2OYAN4QMIPTI3A3PODGBLNN7/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/OQTAF6CQRKHQPYUY5HWVOTUAEXKHI5WE/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TK27HEVDUWQQZQ4XIKTQLDHWK52ZLHWN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Switching to Discourse
I’ve found that using mailing list mode to lurk on discuss.python.org works well. I’ve set up rules on my local mail client to archive what I don’t want in my inbox; I have 4 rules in place now, though I’m interested in a bit more than what was typically on python-dev. Cheers, John > On Dec 6, 2022, at 5:16 AM, Baptiste Carvello > wrote: > > Hi, > > Le 05/12/2022 à 14:50, Stephen J. Turnbull a écrit : >> >> I'd be sad, but I get the feeling that the only people left >> reading it are "here for the community", not to develop code, … > I think this is indeed true, but that's nothing to be sad about: "being > here for the community" is not wrong or shameful. > > Since forever, python-dev has attracted a large following of enthusiast > Python users, who want to understand the design choices of their > preferred language. This widely shared concern for writing idiomatic > code is a distinguishing trait of the Python community (the whole > culture of "pythonic" code). > > Now maybe this is a place where the mailman devs could help and make a > real difference: what if this list would become, not archive-only, but a > *read-only mirror* of those parts of Discourse that are relevant for > core development? That would mean setting up a pipeline starting with > Discourse's so-called "mailing-list mode", going through the kind of > filter stack that some core developers have been setting up for their > personal use, and feeding into this mailing list. The last part can only > be done with the powers of the mailman admins. > > Being read-only would not be a problem in practice: non core-devs here > read much more than they post (as they should). Being forced to log into > a specific website is an acceptable roadblock once in a while for > posting, just not every day for simply following the discussions. > > Turning this list into a relevant mirror of Discourse is the nicest > course of action for the hundreds of silent readers python-dev has > gathered over the years. All those people *won't* switch to routinely > visiting the Discourse website, no matter how much pushing and wishful > thinking the Steering Council puts into it. Shutting down the list means > kicking them away, more or less overtly. > > Cheers, > Baptiste > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/TXLKFNL3RUFNIU5DELXIJQF3UZOX6DIH/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5C43VUQTF4ERNQ2MPLNUOREDQY7M2IUV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PyDict_SetItem hook
I've written a proof of concept patch to add a hook to PyDict_SetItem at http://bugs.python.org/issue5654 My motivation is to enable watchpoints in a python debugger that are called when an attribute or global changes. I know that this won't cover function locals and objects with slots (as Martin pointed out). We talked about this at the sprints and a few issues came up: * Is this worth it for debugger watchpoint support? This is a feature that probably wouldn't be used regularly but is extremely useful in some situations. * Would it be better to create a namespace dict subclass of dict, use it for modules, classes, & instances, and only allow watches of the subclass instances? * To what extent should non-debugger code use the hook? At one end of the spectrum, the hook could be made readily available for non-debug use and at the other end, it could be documented as being debug only, disabled in python -O, & not exposed in the stdlib to python code. John ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyDict_SetItem hook
Collin Winter wrote: Have you measured the impact on performance? I've tried to test using pystone, but am seeing more differences between runs than there is between python w/ the patch and w/o when there is no hook installed. The highest pystone is actually from the binary w/ the patch, which I don't really believe unless it's some low level code generation affect. The cost is one test of a global variable and then a switch to the branch that doesn't call the hooks. I'd be happy to try to come up with better numbers next week after I get home from pycon. John ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyDict_SetItem hook
Just want to reply quickly because I'm traveling -- I appreciate the feedback from Raymond and others. Part of the reason I created an issue with a proof of concept patch is to get this kind of feedback. I also agree that this shouldn't go in if it slows things down noticeably. I will do some benchmarking and look at the dtrace patches next week to see if there is some sort of more systematic way of adding these types of hooks. John ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
