Mailing List Archive

I saw Python projects injecting fake frames for XML and JSON parsers,
maybe also configuration file (.ini?) parsers. So text files which
have line numbers ;-)

On Wed, Sep 1, 2021 at 7:33 PM Pablo Galindo Salgado
<pablogsal@gmail.com> wrote:
> I don't think we should think on those terms. We certainly don't want to be on a case
> where yet again we cannot change the internals because we have an official C-API exposed.

PyCode_New() is annoying since it requires to provide *all* arguments.
I'm thinking of an Frame API which only allows to set 2 values:
filename and line number. Nothing else.

Something like: frame = PyFrame_New(filename, lineno).

Victor
--
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-leave@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/AII6O6ZXEENM7FJH3JRJIPTG4BRKJ3G5/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, 2 Sep 2021, 7:08 am Victor Stinner, <vstinner@python.org> wrote:

> I saw Python projects injecting fake frames for XML and JSON parsers,
> maybe also configuration file (.ini?) parsers. So text files which
> have line numbers ;-)
>
> On Wed, Sep 1, 2021 at 7:33 PM Pablo Galindo Salgado
> <pablogsal@gmail.com> wrote:
> > I don't think we should think on those terms. We certainly don't want to
> be on a case
> > where yet again we cannot change the internals because we have an
> official C-API exposed.
>
> PyCode_New() is annoying since it requires to provide *all* arguments.
> I'm thinking of an Frame API which only allows to set 2 values:
> filename and line number. Nothing else.
>
> Something like: frame = PyFrame_New(filename, lineno).
>


Perhaps "PyCode_FromLocation(file name, lineno)" for the new "good enough
to satisfy trace hooks and exception tracebacks" API? These are needed when
creating function-like (et al) objects from extension module code, not just
for runtime frames.

And then explicitly define which code object fields are expected to always
be populated and which are expected to be None on emulated code objects
that don't contain Python byte code? (e.g. some fields should be zero or
the empty tuple, rather than being set to None)

Cheers,
Nick.


>

On 2/09/21 4:46 am, Victor Stinner wrote:
> If creating a fake frame is a common use case, we can maybe write a
> public C API for that. For example, I saw parser injecting frames to
> show the file name and line number of the parsed file in the
> traceback.

The way I would like to see this addressed is to make it possible
to attach a filename and line number directly to a traceback object,
without needing a frame or code object at all.

Creating a fake frame and code object just to do this is IMO an
ugly hack that should not be necessary.

--
Greg

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/XWX7EXJQ3JJRAL26YFR3GSSMLGSCEH2V/
Code of Conduct: http://python.org/psf/codeofconduct/

On 01. 09. 21 22:28, Guido van Rossum wrote:
> I apologize, I keep making the same mistake.
>
> The PyCode_New[WithPosArgs] functions are *not* in the stable ABI or in
> the limited API, so there's no need to petition the SC, nor do I need
> Petr's approval.
>
> We may be bound by backwards compatibility for the *cpython* API, but I
> think that if Cython is okay if we just break this we should be fine.
> Users of the CPython API are expected to recompile for each new version,
> and if someone were to be using these functions with the old set of
> parameters the compiler would give them an error.

The cpython CPI is still covered by the backwards compatibility policy
(PEP 387). You do need to ask the SC to skip the two-year deprecation
period.

I don't see an issue with the exception being granted, but I do think it
should be rubber-stamped as a project-wide decision.


> So let's just choose (E) and d*mn backwards compatibility for these two
> functions.
>
> That means:
> - Get rid of PyCode_NewWithPosArgs altogether
> - PyCode_New becomes unstable (and gets a new posinlyargcount argument)

... but still remains available and documented, just with a note that it
may change in minor versions. Right?


> On Wed, Sep 1, 2021 at 11:52 AM Guido van Rossum <guido@python.org
> <mailto:guido@python.org>> wrote:
>
> (context)
>
> 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). [...]
>
>
> On Tue, Aug 31, 2021 at 7:07 PM Stefan Behnel <stefan_ml@behnel.de
> <mailto:stefan_ml@behnel.de>> wrote:
>
> 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 you're one of the few people who call those functions, and
> if even you think it's okay to break backward compatibility here, I
> think we should just talk to the SC to be absolved of having these
> two in the stable ABI. (Petr, do you agree? Without your backing I
> don't feel comfortable even asking for this.)
>
> 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.
>
>
> Note there's nothing in the stable ABI to create frames. There are
> only functions to *get* an existing frame, to inspect a frame, and
> to eval it. In any case even if there was a stable ABI function to
> create a frame from a code object, one could argue that it's
> sufficient to be able to get an existing code object from e.g. a
> function object.
>
> 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.
>
>
> I think others have answered this already -- in any case it's not
> the immediate subject of this thread, and I don't have a strong
> opinion on it.
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> /Pronouns: he/him //(why is my pronoun here?)/
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>
>
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> /Pronouns: he/him //(why is my pronoun here?)/
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/LYIFIVPSFGS2OFIRKAYKGOAVKJTDNAHD/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, 2 Sep 2021 13:31:32 +1200
Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
> On 2/09/21 4:46 am, Victor Stinner wrote:
> > If creating a fake frame is a common use case, we can maybe write a
> > public C API for that. For example, I saw parser injecting frames to
> > show the file name and line number of the parsed file in the
> > traceback.
>
> The way I would like to see this addressed is to make it possible
> to attach a filename and line number directly to a traceback object,
> without needing a frame or code object at all.

Tracebacks are linked in a single direction, to go the other direction
you need to walk the frames attached to the traceback. If there is no
frame on the traceback, you cannot go the other direction.

So a (fake or not) frame object is still desirable, IMHO.

Regards

Antoine.


_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/GJH33BQBHXMC6PGTHDY7TOQDRTCRXCCV/
Code of Conduct: http://python.org/psf/codeofconduct/

On 2/09/21 7:46 pm, Antoine Pitrou wrote:
> Tracebacks are linked in a single direction, to go the other direction
> you need to walk the frames attached to the traceback.
>
> So a (fake or not) frame object is still desirable, IMHO.

Could we at least remove the necessity for a fake code object?

--
Greg

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/TDLCJHNQSPNE7UXEJ33PV2VNQOPUFUT7/
Code of Conduct: http://python.org/psf/codeofconduct/

FWIW I've applied for an exception from the two-release deprecation policy
from the SC:
https://github.com/python/steering-council/issues/75

On Thu, Sep 2, 2021 at 1:12 AM Greg Ewing <greg.ewing@canterbury.ac.nz>
wrote:

> On 2/09/21 7:46 pm, Antoine Pitrou wrote:
> > Tracebacks are linked in a single direction, to go the other direction
> > you need to walk the frames attached to the traceback.
> >
> > So a (fake or not) frame object is still desirable, IMHO.
>
> Could we at least remove the necessity for a fake code object?
>
> --
> Greg
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/TDLCJHNQSPNE7UXEJ33PV2VNQOPUFUT7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On Thu, Sep 2, 2021 at 11:15 PM Guido van Rossum <guido@python.org> wrote:
> FWIW I've applied for an exception from the two-release deprecation policy from the SC:
> https://github.com/python/steering-council/issues/75

On the PyPI top 5000 packages, 136 contain "PyCode" in the source. I
didn't check how many are using Cython.

yarl-1.6.3.tar.gz
wsaccel-0.6.3.tar.gz
wordcloud-1.8.1.tar.gz
uvloop-0.16.0.tar.gz
tslearn-0.5.2.tar.gz
uamqp-1.4.1.tar.gz
tweedledum-1.1.0.tar.gz
tinycss-0.4.tar.gz
thriftpy-0.3.9.tar.gz
thriftpy2-0.4.14.tar.gz
Theano-PyMC-1.1.2.tar.gz
Theano-1.0.5.tar.gz
TA-Lib-0.4.21.tar.gz
tables-3.6.1.tar.gz
ssh2-python-0.26.0.tar.gz
srsly-2.4.1.tar.gz
ssh-python-0.9.0.tar.gz
statsmodels-0.12.2.tar.gz
sphinx-gallery-0.9.0.tar.gz
sktime-0.7.0.tar.gz
Shapely-1.7.1.tar.gz
wxPython-4.1.1.tar.gz
scikit-image-0.18.2.tar.gz
sasl-0.3.1.tar.gz
scikit-surprise-1.1.1.tar.gz
s2sphere-0.2.5.tar.gz
ruptures-1.1.4.tar.gz
runstats-2.0.0.tar.gz
ruamel.yaml.clib-0.2.6.tar.gz
reedsolo-1.5.4.tar.gz
recordclass-0.15.1.tar.gz
reportlab-3.6.1.tar.gz
rasterio-1.2.6.tar.gz
rapidfuzz-1.4.1.tar.gz
qiskit-terra-0.18.1.tar.gz
pyzmq-22.2.1.tar.gz
pyxDamerauLevenshtein-1.7.0.tar.gz
PyWavelets-1.1.1.tar.gz
python-crfsuite-0.9.7.tar.gz
py_spy-0.3.8.tar.gz
pysimdjson-4.0.2.tar.gz
pysam-0.16.0.1.tar.gz
pypcap-1.2.3.tar.gz
pyngrok-5.0.6.tar.gz
PyLBFGS-0.2.0.13.tar.gz
pyjq-2.5.2.tar.gz
pyhacrf-datamade-0.2.5.tar.gz
pyflux-0.4.15.tar.gz
pygame-2.0.1.tar.gz
pyemd-0.5.1.tar.gz
pydevd-2.4.1.tar.gz
pydevd-pycharm-212.5080.18.tar.gz
plyvel-1.3.0.tar.gz
pmdarima-1.8.2.tar.gz
peewee-3.14.4.tar.gz
paramiko-2.7.2.tar.gz
osmium-3.2.0.tar.gz
orderedset-2.0.3.tar.gz
numpydoc-1.1.0.tar.gz
numdifftools-0.9.40.tar.gz
numba-0.53.1.tar.gz
numcodecs-0.8.1.tar.gz
NetfilterQueue-0.8.1.tar.gz
neobolt-1.7.17.tar.gz
Naked-0.1.31.tar.gz
mypy-0.910.tar.gz
msgpack-python-0.5.6.tar.gz
msgpack-1.0.2.tar.gz
mojimoji-0.0.11.tar.gz
mpi4py-3.1.1.tar.gz
matrixprofile-1.1.10.tar.gz
marisa-trie-0.7.7.tar.gz
lupa-1.9.tar.gz
lxml-4.6.3.tar.gz
lsm-db-0.6.4.tar.gz
linearmodels-4.24.tar.gz
lightfm-1.16.tar.gz
Levenshtein-0.13.0.tar.gz
leven-1.0.4.tar.gz
lda-2.0.0.tar.gz
jsonobject-0.9.10.tar.gz
jq-1.2.1.tar.gz
JPype1-1.3.0.tar.gz
jenkspy-0.2.0.tar.gz
implicit-0.4.4.tar.gz
imgui-1.3.0.tar.gz
imbalanced-learn-0.8.0.tar.gz
imagecodecs-2021.7.30.tar.gz
httptools-0.3.0.tar.gz
httpretty-1.1.4.tar.gz
hmmlearn-0.2.6.tar.gz
hdbscan-0.8.27.tar.gz
gssapi-1.6.14.tar.gz
grpcio-tools-1.39.0.tar.gz
grpcio-1.39.0.tar.gz
graphene-federation-0.1.0.tar.gz
GPy-1.10.0.tar.gz
gluonnlp-0.10.0.tar.gz
gevent-21.8.0.tar.gz
gensim-4.0.1.tar.gz
fuzzyset-0.0.19.tar.gz
fuzzysearch-0.7.3.tar.gz
frozendict-2.0.6.tar.gz
flower-1.0.0.tar.gz
Fiona-1.8.20.tar.gz
fastrlock-0.6.tar.gz
fastparquet-0.7.1.tar.gz
fastdtw-0.3.4.tar.gz
fastavro-1.4.4.tar.gz
edlib-1.3.8.post2.tar.gz
editdistance-0.5.3.tar.gz
econml-0.12.0.tar.gz
dtaidistance-2.3.2.tar.gz
DoubleMetaphone-0.1.tar.gz
django-localflavor-3.1.tar.gz
dependency-injector-4.35.2.tar.gz
dedupe-hcluster-0.3.8.tar.gz
dedupe-2.0.8.tar.gz
ddtrace-0.51.2.tar.gz
cytoolz-0.11.0.tar.gz
Cython-0.29.24.tar.gz
correctionlib-2.0.0.tar.gz
clickhouse-driver-0.2.1.tar.gz
cityhash-0.2.3.post9.tar.gz
cchardet-2.1.7.tar.gz
causalml-0.11.1.tar.gz
Cartopy-0.19.0.post1.tar.gz
av-8.0.3.tar.gz
asyncpg-0.24.0.tar.gz
astral-2.2.tar.gz
arch-5.0.1.tar.gz
arcgis-1.9.0.tar.gz
altgraph-0.17.tar.gz
aiokafka-0.7.1.tar.gz
aiohttp-3.7.4.post0.tar.gz
affinegap-1.11.tar.gz

Victor
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/6RO2WFU5Q7UQDVL72IRMT4T6L4GEAKB6/
Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, Sep 3, 2021 at 4:12 PM Victor Stinner <vstinner@python.org> wrote:

> On Thu, Sep 2, 2021 at 11:15 PM Guido van Rossum <guido@python.org> wrote:
> > FWIW I've applied for an exception from the two-release deprecation
> policy from the SC:
> > https://github.com/python/steering-council/issues/75
>
> On the PyPI top 5000 packages, 136 contain "PyCode" in the source. I
> didn't check how many are using Cython.
>

Most of them. :-)

I wrote a script that to do a similar search on the 4000 most popular
packages, disregarding Cython-generated files (these have "/* Generated by
Cython <version> */" in their first line). Now the list collapsed to this:

Cython-3.0a7.tar.gz: 11 hits in 3 files
frozendict-2.0.6.tar.gz: 14 hits in 8 files
gevent-21.8.0.tar.gz: 1 hits in 1 files
JPype1-1.3.0.tar.gz: 1 hits in 1 files
mypy-0.910.tar.gz: 2 hits in 1 files
reportlab-3.6.1.tar.gz: 1 hits in 1 files
setuptools-9.1.tar.gz: 1 hits in 1 files

Of these:

Cython: obviously :-)
frozendict: calls PyCode_NewEmpty; seems to include modified CPython headers
gevent: Uses Cython's __Pyx_PyCode_New in a generated .h file
JPype: calls PyCode_NewEmpty
mypy: PyCode_NewEmpty mentioned in a comment
reportlab: calls PyCode_NewEmpty
setuptools: in a file generated by Pyrex (Cython's predecessor)

There wasn't a single call to PyCode_NewWithPosOnlyArgs in any of these
apart from Cython.

In addition, I just heard from the SC that they've approved the exception.
So we will remove these two APIs from 3.11 without deprecation. I've filed
https://bugs.python.org/issue45122 to get this done (looking for
volunteers).

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

Oh, I didn't know this *existing* C API function:

PyCode_NewEmpty(const char *filename, const char *funcname, int firstlineno)

So Cython could be modified to use it, no?

Victor

On Tue, Sep 7, 2021 at 12:44 AM Guido van Rossum <guido@python.org> wrote:
>
> On Fri, Sep 3, 2021 at 4:12 PM Victor Stinner <vstinner@python.org> wrote:
>>
>> On Thu, Sep 2, 2021 at 11:15 PM Guido van Rossum <guido@python.org> wrote:
>> > FWIW I've applied for an exception from the two-release deprecation policy from the SC:
>> > https://github.com/python/steering-council/issues/75
>>
>> On the PyPI top 5000 packages, 136 contain "PyCode" in the source. I
>> didn't check how many are using Cython.
>
>
> Most of them. :-)
>
> I wrote a script that to do a similar search on the 4000 most popular packages, disregarding Cython-generated files (these have "/* Generated by Cython <version> */" in their first line). Now the list collapsed to this:
>
> Cython-3.0a7.tar.gz: 11 hits in 3 files
> frozendict-2.0.6.tar.gz: 14 hits in 8 files
> gevent-21.8.0.tar.gz: 1 hits in 1 files
> JPype1-1.3.0.tar.gz: 1 hits in 1 files
> mypy-0.910.tar.gz: 2 hits in 1 files
> reportlab-3.6.1.tar.gz: 1 hits in 1 files
> setuptools-9.1.tar.gz: 1 hits in 1 files
>
> Of these:
>
> Cython: obviously :-)
> frozendict: calls PyCode_NewEmpty; seems to include modified CPython headers
> gevent: Uses Cython's __Pyx_PyCode_New in a generated .h file
> JPype: calls PyCode_NewEmpty
> mypy: PyCode_NewEmpty mentioned in a comment
> reportlab: calls PyCode_NewEmpty
> setuptools: in a file generated by Pyrex (Cython's predecessor)
>
> There wasn't a single call to PyCode_NewWithPosOnlyArgs in any of these apart from Cython.
>
> In addition, I just heard from the SC that they've approved the exception. So we will remove these two APIs from 3.11 without deprecation. I've filed https://bugs.python.org/issue45122 to get this done (looking for volunteers).
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)



--
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-leave@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/VQOKM6V7UJA2M6LBZ4JPHLVRK3OCHNRU/
Code of Conduct: http://python.org/psf/codeofconduct/

Guido van Rossum schrieb am 07.09.21 um 00:44:
> In addition, I just heard from the SC that they've approved the exception.
> So we will remove these two APIs from 3.11 without deprecation.
Erm, hang on – when I wrote that I'm fine with *changing* them, I wasn't
thinking of actually *removing* them. At least not both. PyCode_NewEmpty()
isn't a good replacement since it takes low level arguments … char* instead
of Python strings. It's good for the simple use case that it was written
for (and Cython already uses it for that), but not so great for anything
beyond that.

What I could try is to create only a single dummy code object and then
always call .replace() on it to create new ones. But that seems hackish and
requires managing yet another bit of global state across static and
generated code parts.

I could also switch to _PyCode_New(), though it's not exactly what I would
call an attractive option, both for usability reasons and its future API
stability. (Cython also still generates C89 code, i.e. no partial struct
initialisations.)

Any suggestions?

Stefan

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/B6WFHGVAASF4MFUMPIHBZEUCPXVANU7D/
Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Sep 7, 2021 at 10:00 AM Stefan Behnel <stefan_ml@behnel.de> wrote:

> Guido van Rossum schrieb am 07.09.21 um 00:44:
> > In addition, I just heard from the SC that they've approved the
> exception.
> > So we will remove these two APIs from 3.11 without deprecation.
>


> Erm, hang on – when I wrote that I'm fine with *changing* them, I wasn't
> thinking of actually *removing* them. At least not both. PyCode_NewEmpty()
> isn't a good replacement since it takes low level arguments … char*
> instead
> of Python strings. It's good for the simple use case that it was written
> for (and Cython already uses it for that), but not so great for anything
> beyond that.
>

Is the issue that you want to specify a few additional simple arguments, or
that you already have unicode objects and you don't want to have them
converted back to char * (which will then be converted to new unicode
objects by PyCode_NewEmpty)?


> What I could try is to create only a single dummy code object and then
> always call .replace() on it to create new ones. But that seems hackish
> and
> requires managing yet another bit of global state across static and
> generated code parts.
>

I can't argue with the need for an extra bit of global state, but to me,
calling .replace() is not hackish, it's the best way to create new code
objects -- it works for older Python versions and will keep working in the
future.


> I could also switch to _PyCode_New(), though it's not exactly what I would
> call an attractive option, both for usability reasons and its future API
> stability. (Cython also still generates C89 code, i.e. no partial struct
> initialisations.)
>

That's too bad. With the new struct initializations it's actually more
usable and more stable going forward.


> Any suggestions?
>
> Stefan
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/B6WFHGVAASF4MFUMPIHBZEUCPXVANU7D/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>