[Python-Dev] Re: Regressions caused the recent work on ceval.c and frame objects
Are you sure Cython is still broken? It looks like it was fixed back in May (https://github.com/cython/cython/issues/4153) and all the tests look to be passing on the 3.10-dev CI run for Cython. I think it only affected the profiling feature on Cython (which most people will have turned off) so probably won't cause widespread breakage. Which is not to say that you shouldn't fix the issue, but I don't think it's a disaster from Cython's point of view. ___ 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/B6OLXTTP5KQVNFLZD2WWV4YSYNSUZX6Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Regressions caused the recent work on ceval.c and frame objects
> Will all packages that use Cython have to upgrade Cython to work with 3.10? For this particular issue you'll only have to upgrade if you use "profiling" (I doubt that many packages routinely build with Cython profiling turned on). However, it's possible there are other 3.10 bugfixes in Cython - I'm not completely sure. I think the easiest way to know is to try to build a package for 3.10. ___ 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/52VFBHR7AHTXPLC434E4BPXNXVUU3SVF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
Greg Ewing wrote: > To address this there could be an option to choose between > "compatible code" and "fast code", with the former restricting > itself to the stable API. To some extent, that exists at the moment - many of the real abuses of the CPython internals can be controlled by setting C defines. For the particular feature that caused this discussion the majority of the uses can be turned off by defining CYTHON_USE_EXC_INFO_STACK=0 and CYTHON_FAST_THREAD_STATE=0. (There's still a few uses relating to coroutines, but those too flags are sufficient to get Cython to build itself and Numpy on Python 3.11a4). Obviously it could still be better. But the desire to support PyPy (and the beginnings of the limited API) mean that Cython does actually have alternate "clean" code-paths for a lot of cases. ___ 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/Q3IQUKU35GNCUXBCK55JZ3B42LSVS2M2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
Guido van Rossum wrote: > My question for you is if you're willing to write up a list of things in > CPython that you depend on. Or is this just something you're not willing to > commit to? It would be nice to know which it is, just so the CPython team > knows what we're up against. I'm happy to prepare a list of CPython internals that Cython uses. Obviously there's no guarantee that it'll be complete (just because it involves lots of manually finding things in code so is full of human error) or that it doesn't change in future. But a list would at least let everyone know where they stand. ___ 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/T5LVLMEW4I5QKJLS55PBV62EKBIN7M2O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Moving away from _Py_IDENTIFIER().
Victor Stinner wrote: > On Wed, Feb 2, 2022 at 11:49 PM Eric Snow ericsnowcurren...@gmail.com wrote: > In the top 5000 PyPI projects, I found 11 projects using them: > * Cython-0.29.26 (and so indirect most projects using Cython) I believe Cython is (for once) a false alarm here. I don't think it uses any of those functions. It has a comment that contains "_PyObject_LookupAttrId" - https://github.com/cython/cython/blob/8d2df028bf9536942b60670bf0aa80d6acc7464a/Cython/Utility/ObjectHandling.c#L1061 - This is a bit of code that we'd adapted from CPython and the comment just explains what the original line is. It's possible I've missed something of course, in which case let me know. David ___ 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/5WICJJ5GYJE54JKPG56UY33YHHFQROHX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 2)
Petr Viktorin wrote: > Should we care about hacks/optimizations that rely on having the only > reference (or all references), e.g. mutating a tuple if it has refcount > 1? Immortal objects shouldn't break them (the special case simply won't > apply), but this wording would make them illegal. > AFAIK CPython uses this internally, but I don't know how > prevalent/useful it is in third-party code. For what it's worth Cython does this for string concatenation to concatenate in place if possible (this optimization was copied from CPython). It could be disabled relatively easily if it became a problem (it's already CPython only and version checked so it'd just need another upper-bound version check). ___ 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/CDNQK5RMXSLLYFNIXRORL7GTKU6B4BVR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 4: The wonderful third option
Larry Hastings wrote: > [...] > > Now comes the one thing that we might call a "trick". The trick: when > we allocate the ForwardClass instance C, we make it as big as a class > object can ever get. (Mark Shannon assures me this is simply "heap > type", and he knows far more about CPython internals than I ever will.) It's possible that I'm misunderstanding the allocation mechanism (and it sounds like you've discussed it with people that know a lot more about the internals than me), but if C is an instance of the metaclass then surely you have to know the metaclass to know this. And it looks like the metaclass can definitely be a C type (and thus have a C struct defining an instance). A presumably the metaclass could be a variable size C type (i.e. like tuple), so possibly not even known until the instance is made. David ___ 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/Y4DXOFP6CFX3GKPLFP5MYTOEESRSBW7O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: New public PyUnicodeBuilder C API
Cython used the private _PyUnicodeWriter API (and stopped using it on Py3.11 when it was hidden more thoroughly) so would probably make use of a public API to do the same thing. It's an optimization rather than an essential of course ___ 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/2PWRAACTQVGDYEYBQXERBHOMSAOKIKF3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: New public PyUnicodeBuilder C API
Victor Stinner wrote: > On Mon, May 16, 2022 at 11:40 AM dw-...@d-woods.co.uk wrote: > > Cython used the private _PyUnicodeWriter API (and stopped using it on > > Py3.11 when it was hidden more thoroughly) > > I'm not aware of any change in the the private _PyUnicodeWriter API in > Python 3.11. It was _PyFloat_FormatAdvancedWriter and _PyLong_FormatAdvancedWriter that got moved internally to somewhere Cython couldn't easily get them I think. (https://github.com/python/cpython/commit/0a883a76cda8205023c52211968bcf87bd47fd6e and https://github.com/python/cpython/commit/5f09bb021a2862ba89c3ecb53e7e6e95a9e07e1d). Obviously it would be possible to include the internal headers and re-enable it though - just turning it off was the quickest way to get it working at the time though > Is it just that Cython no longer wants to use private > APIs? No such luck I'm afraid! The current policy is something like: if possible we should have a back-up option to avoid the private API, ideally controlled by a C define. I think that's a fairly good compromise - it lets Cython benefit from the internal APIs but provides an easy fix if they change. Obviously that policy isn't applied perfectly yet... ___ 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/STZOK7UZ64NMZNYZFOQZ25HNGVVURIE7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: New public PyUnicodeBuilder C API
Victor Stinner wrote: > My proposed API targets Python 3.12, it's too late for Python 3.11. > Maybe for Python 3.11, it's ok to add back private > _PyFloat_FormatAdvancedWriter and _PyLong_FormatAdvancedWriter > functions to the public C API to restore Cython performance. I think at this stage they should be left where they are. I can see why they were made private > If a public API is added to "build a string", maybe it would > make sense to add these "advanced formatter" functions to the public C > API? I think that the Cython is most likely to use a public string builder API for string formatting (for example fstrings). To me that suggests it'd be useful for a public API to include number formatting. Uses like concatenating strings in a loop are a little harder to optimize just because it'd be hard to identify when to switch a variable from stringbuilder to string seemlessly and invisibly to a user. So we'd probably only use it for single expressions (of which formatting is the most obvious) ___ 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/HCEUV7BKAG4RBWFEX4FOWJKL3OKHKDT2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Structural pattern matching and mangling private names
For this code: class C: def f(self, x): match x: case D(__something=y): return y It appears that the name "__something" isn't mangled. Under most other circumstances I'd expect this to be mangled to "_C__something". Is this: * intentional, * accidental, but how that it's done it's the defined behaviour, * or a defect? It doesn't seem like it's explicitly tested for in test_patma.py either way. Thanks David ___ 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/LILLO3MBTVY6ZQT3VNUVXATEPS3ASGQF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Structural pattern matching and mangling private names
Daniel Moisset wrote: > I might expect that in a "case D(something=__y)" you get the mangling for > __y, but I'm not sure what the implementation does now and I'm writing from > my phone Yes - that case does what you'd expect. Thanks for the reply. ___ 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/3BALIBTV3ATAEC6G5ZJKAFBASZG4B5AP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Structural pattern matching and mangling private names
Guido van Rossum wrote: > If you want any kind of traction on this I recommend filing an opinionated > issue on this (explaining why the current behavior is wrong). Thanks - I'm asking from the point of view of trying to reimplement it. I don't actually have a strong opinion on whether the current behaviour is wrong - I'd just like to know if I should match it. >From that point of view I've deviated from your advice slightly and created a >PR instead to add a test for the current behaviour >(https://github.com/python/cpython/pull/94500). Hopefully that'll either fix >it is "intended" or stir up a different decision. I'm happy with either >outcome. David ___ 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/DBAJEVHAR6QD7HHECUESU6ZMPQKLBSC5/ Code of Conduct: http://python.org/psf/codeofconduct/
