[Python-Dev] Re: Making code object APIs unstable
Guido van Rossum schrieb am 13.08.21 um 19:24: In 3.11 we're changing a lot of details about code objects. Part of this is the "Faster CPython" work, part of it is other things (e.g. PEP 657 -- Fine Grained Error Locations in Tracebacks). As a result, the set of fields of the code object is changing. This is fine, the structure is part of the internal API anyway. But there's a problem with two public API functions, PyCode_New() and PyCode_NewWithPosArgs(). As we have them in the main (3.11) branch, their signatures are incompatible with previous versions, and they have to be since the set of values needed to create a code object is different. (The types.CodeType constructor signature is also changed, and so is its replace() method, but these aren't part of any stable API). Unfortunately, PyCode_New() and PyCode_NewWithPosArgs() are part of the PEP 387 stable ABI. What should we do? A. We could deprecate them, keep (restore) their old signatures, and create crippled code objects (no exception table, no endline/column tables, qualname defaults to name). B. We could deprecate them, restore the old signatures, and always raise an error when they are called. C. We could just delete them. D. We could keep them, with modified signatures, and to heck with ABI compatibility for these two. E. We could get rid of PyCode_NewWithPosArgs(), update PyCode() to add the posonlyargcount (which is the only difference between the two), and d*mn the torpedoes. F. Like (E), but keep PyCode_NewWithPosArgs() as an alias for PyCode_New() (and deprecate it). If these weren't part of the stable ABI, I'd choose (E). [...] I also vote for (E). The creation of a code object is tied to interpreter internals and thus shouldn't be (or have been) declared stable. I think the only problem with that argument is that code objects are required for frames. You could argue the same way about frames, but then it becomes really tricky to, you know, create frames for non-Python code. Since we're discussing this in the context of PEP 657, I wonder if there's a better way to create tracebacks from C code, other than creating fake frames with fake code objects. Cython uses code objects and frames for the following use cases: - tracing generated C code at the Python syntax level - profiling C-implemented functions - tracebacks for C code Having a way to do these three efficiently (i.e. with close to zero runtime overhead) without having to reach into internals of the interpreter state, code objects and frames, would be nice. Failing that, I'm ok with declaring the relevant structs and C-API functions non-stable and letting Cython use them as such, as we always did. Stefan ___ 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/XYNNMH57O7CYWHYKTD3ELZTM3B4M53HL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: API's to interface python with Eclipse to execute and debug C/C++ Source files.
On Thu, Aug 19, 2021 at 04:27:19AM +, Chandrakant Shrimantrao wrote: > Hi, > We would like to know if there is any option available to execute and debug( > setting break point and delete break point) C/C++ Source files Python API's > inside Eclipse IDE after interfacing Pydev with Eclipse. This is a good question for PyDev Eclipse Plugin. As far as I know, tI have not seen breakpoints for C/C++ with Pydev Eclipse, but I am not regular use of PyDev. For debugging Python's C Source files, I found Visual Studio Code's support for Makefile, C and Python to be useful. Thanks, Senthil ___ 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/LVCGHVRPODLI3SFXTNF6A537F5PVLM66/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP-535 (Rich comparison chaining) Discussion?
On Tue, Aug 31, 2021 at 8:57 AM Angus Hollands wrote: > Should look more like > ```python > x = np.array(...) > y = x[2 < x < 8] > ``` > Is there any interest in pushing this PEP along? > My personal opinion is, it is worth discussing again. I could see the benefits this brings to Numpy Arrays. The PEP itself was deferred based on boolean overload dislike than the short-circuit or chaining operator preference. -- Senthil ___ 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/ENJYFXADZXDU7RZBD5RJTPS6ZE7YFNMN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP-535 (Rich comparison chaining) Discussion?
Link to the PEP: https://www.python.org/dev/peps/pep-0535/ On Tue, Aug 31, 2021 at 8:52 AM Angus Hollands wrote: > Hi all, > > PEP 535 was deferred until Python 3.8. I would like to discuss the PEP > given that some time has passed, and I _personally_ would benefit from its > acceptance. > > > ## A little about me: > As a reasonably long-time Python user (well, 16 years), I have gradually > moved from using only the core language to working within the DSLs (NumPy > et al.) of the Scientific Python ecosystem. Most recently, I've been using > Awkward Arrray (https://github.com/scikit-hep/awkward-1.0), which > generalises the regular NumPy array programming paradigm into "jagged" data > structures, and was initially aimed at the High Energy Physics (HEP) > domain. > > > ## TL;DR of the PEP's Motivations: > Various aspects of NumPy's API have become a "lingua-franca" in the > Scientific Python domain, such as strongly-overloaded index operations. One > such overload allows "mask arrays" — arrays with boolean entries > corresponding to a per-element mask — to select a subset of the array. > These mask arrays are conveniently built from the rich comparison operators > that Python supports, e.g. > ```python > x = np.array(...) > y = x[(2 < x) & (x < 8)] > ``` > > As discussed in PEP 535, the limitation on comparison chaining (namely > that it is not possible for rich comparisons) makes the above syntax more > clunky than it might otherwise be. The main repercussion of this limitation > is lower readability: > - operator precedence of bitwise and/or requires a reasonable number of > parentheses ( > https://docs.python.org/3/reference/expressions.html#operator-precedence) > - repetition of the rich-object (array) > > With PEP 535 (and the necessary library changes), this would look more like > ```python > x = np.array(...) > y = x[2 < x < 8] > ``` > This is already well described in the PEP, so I'll leave the example there! > > > ## Community Survey > The Oct 2020 Python Developers Survey ( > https://www.jetbrains.com/lp/python-developers-survey-2020/) suggests > that 62% of respondents use NumPy. Additionally, 37% of respondents list > "Simple syntax, syntactic sugar, easy to learn" and 30% list "Easy to write > & read code, high-level language" amongst their three most liked features > in the Python language (to clarify, these answers may overlap by > respondent!) > > >From these results, I would make a tentative case that this PEP would > have a reasonable impact on the Python community, given that libraries > benefitting from this proposal (e.g. NumPy) are used by a "majority" of > those surveyed. > > > ## Conclusion > This is a bit of a long opener to this list (apologies!). Is there any > interest in pushing this PEP along? > > Thanks, > Angus Hollands > ___ > 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/ET7BPR57Q6MT6TUG4SXPSALRC3P3ZY35/ > 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/RGK7JOEO6BY44EEG67LBYAUOPWKLDWYS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP-535 (Rich comparison chaining) Discussion?
Hi all, PEP 535 was deferred until Python 3.8. I would like to discuss the PEP given that some time has passed, and I _personally_ would benefit from its acceptance. ## A little about me: As a reasonably long-time Python user (well, 16 years), I have gradually moved from using only the core language to working within the DSLs (NumPy et al.) of the Scientific Python ecosystem. Most recently, I've been using Awkward Arrray (https://github.com/scikit-hep/awkward-1.0), which generalises the regular NumPy array programming paradigm into "jagged" data structures, and was initially aimed at the High Energy Physics (HEP) domain. ## TL;DR of the PEP's Motivations: Various aspects of NumPy's API have become a "lingua-franca" in the Scientific Python domain, such as strongly-overloaded index operations. One such overload allows "mask arrays" — arrays with boolean entries corresponding to a per-element mask — to select a subset of the array. These mask arrays are conveniently built from the rich comparison operators that Python supports, e.g. ```python x = np.array(...) y = x[(2 < x) & (x < 8)] ``` As discussed in PEP 535, the limitation on comparison chaining (namely that it is not possible for rich comparisons) makes the above syntax more clunky than it might otherwise be. The main repercussion of this limitation is lower readability: - operator precedence of bitwise and/or requires a reasonable number of parentheses (https://docs.python.org/3/reference/expressions.html#operator-precedence) - repetition of the rich-object (array) With PEP 535 (and the necessary library changes), this would look more like ```python x = np.array(...) y = x[2 < x < 8] ``` This is already well described in the PEP, so I'll leave the example there! ## Community Survey The Oct 2020 Python Developers Survey (https://www.jetbrains.com/lp/python-developers-survey-2020/) suggests that 62% of respondents use NumPy. Additionally, 37% of respondents list "Simple syntax, syntactic sugar, easy to learn" and 30% list "Easy to write & read code, high-level language" amongst their three most liked features in the Python language (to clarify, these answers may overlap by respondent!) >From these results, I would make a tentative case that this PEP would have a >reasonable impact on the Python community, given that libraries benefitting >from this proposal (e.g. NumPy) are used by a "majority" of those surveyed. ## Conclusion This is a bit of a long opener to this list (apologies!). Is there any interest in pushing this PEP along? Thanks, Angus Hollands ___ 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/ET7BPR57Q6MT6TUG4SXPSALRC3P3ZY35/ Code of Conduct: http://python.org/psf/codeofconduct/
