From stefan_ml at behnel.de Sun Apr 12 06:24:59 2020 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 12 Apr 2020 12:24:59 +0200 Subject: [Cython] Cython 3.0 alpha 1 released Message-ID: <48665f8f-dd38-65cd-b495-0d28c65814f5@behnel.de> Dear Cython users and devs, today, I'm happy to announce the first alpha release of Cython 3.0. https://pypi.org/project/Cython/3.0a1/ It took us a while to get to this point, well more than a year's time, but we received a lot of help along the way, most notably from David Woods, Jeroen Demeyer and Matti Picus. Thanks a lot, and also to the many other contributors! For this release, we already have 182 closed issues and merged PRs, including 109 PRs contributed by non-core devs! ** What is Cython 3.0? Cython 3.0 is our effort to bring Cython up to date with modern Python 3, after an 18 year long development history. According to the Python mailing list archive [1] and Greg's download directory [2], Cython's predecessor Pyrex 0.1 was announced and released to the public on April 4th, 2002. Cython is finally coming of age. :) ** So, what's new? Too much. Way too much for this announcement. Cython 3.0 comes with a very long list of new features, bug fixes and modernisations, a few of which are backwards incompatible, but in a good way. See the latest changelog: https://github.com/cython/cython/blob/master/CHANGES.rst Here's a short teaser list anyway: - Python 3 semantics by default, legacy Python 2 semantics via directive. - No more deprecated NumPy C-API usage. - Unicode module names, imports, and identifiers (PEP-3131, PEP-489). - Support for the fast vectorcall protocol (PEP-590). - Inlined properties on external cdef classes. - Faster dispatch for fused functions. - First steps towards supporting CPython's stable ABI (PEP-384). ** How alpha is it? Well. It's not complete yet [3]. It still has some known issues. There are still some unmerged PRs waiting. Support for the limited API is ? limited. But, it's in a good shape and probably ready enough for you to make use of all those cool new features. Please give it a try and report back if you find issues that we can still improve on in the upcoming pre-releases. PRs very welcome! As always, if it works for you, use it. Generate your C code locally with it, test it, then ship it to your users. Once the code is compiled, they don't even have to know that you've used an alpha version. :) Have fun, Stefan [1] https://mail.python.org/pipermail/python-list/2002-April/126661.html [2] https://www.csse.canterbury.ac.nz/greg.ewing/python/Pyrex/oldtar/ [3] https://github.com/cython/cython/milestone/58 From volker.weissmann at gmx.de Wed Apr 22 14:44:16 2020 From: volker.weissmann at gmx.de (=?UTF-8?Q?Volker_Wei=c3=9fmann?=) Date: Wed, 22 Apr 2020 20:44:16 +0200 Subject: [Cython] Help with cygdb bug Message-ID: <47aa78a2-9db8-8940-2c4d-03339362410a@gmx.de> Hello, cy exec print(localvar) currently does not work. And I need your help to fix it. If I'm not mistaken, the function "_fill_locals_dict" in libcython.py is supposed to find and set all local variables. The "for name, cyvar in iterator:" correctly iterates over all local variables, but cyvar.type is not PythonObject but CObject. The cython line "localvar= 49" gets translated to the C-line "__pyx_v_localvar = 49;". Notice how the type of__pyx_v_localvar is long and not a static PyObject*? . If an equivalent "static PyObject*" would exist in the C-code, I would know how to make 'cy exec print(localvar)' work (the reason why global variables work, is because they are of type static PyObject*). I see two ways to make `cy exec print(localvar)` work: 1. Let cygdb generate C-code to convert a long (or any other type) to an equivalent static PyObject* (For long's it would be __Pyx_PyInt_From_long). Then let cygdb execute this code by running gdb.parse_and_eval(code). Then read the resulting variable with something like code = ''' ??????????????????? (PyObject *) PyDict_SetItem( ??????????????????????? (PyObject *) %d, ??????????????????????? (PyObject *) %d, ??????????????????????? (PyObject *) %s) ??????????????? ''' % (local_dict_pointer, pystringp, cname) gdb.parse_and_eval(code) 2. Compile the argument of cy exec (in this case "print(localvar)") to C-code (while getting the local variables right) and run it using gdb.parse_and_eval(code). Ideally, cy exec var=123 should work like cy set var=123. Example to reproduce it: codefile.pyx: def func(): ??? localvar = 49 ??? print(localvar) func() setup.py: #!/usr/bin/env python from setuptools import setup, Extension from Cython.Build import cythonize extensions = Extension('codefile', sources=['codefile.pyx']) setup( ??? author = 'Volker Weissmann', ??? author_email = 'volker.weissmann at gmx.de', ??? ext_modules = cythonize( ??????? extensions, ??????? gdb_debug=True, ??? ), ) .cygdbinit: cy break codefile:3 cy run cy print localvar To reproduce it, run: python setup.py build_ext --inplace cygdb . -- -q --args python -c "import codefile" With a debug version of Python. From stefan_ml at behnel.de Thu Apr 23 08:30:49 2020 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 23 Apr 2020 14:30:49 +0200 Subject: [Cython] Help with cygdb bug In-Reply-To: <47aa78a2-9db8-8940-2c4d-03339362410a@gmx.de> References: <47aa78a2-9db8-8940-2c4d-03339362410a@gmx.de> Message-ID: Hi Volker! Volker Wei?mann schrieb am 22.04.20 um 20:44: > cy exec print(localvar) > > currently does not work. And I need your help to fix it. Do you mean "cy exec print(x)" or "cy print x" here? (The latter is what you used in your example at the end.) > If I'm not mistaken, the function "_fill_locals_dict" in libcython.py is > supposed to find and set all local variables. > > The "for name, cyvar in iterator:" correctly iterates over all local > variables, but cyvar.type is not PythonObject but CObject. > > The cython line "localvar= 49" gets translated to the C-line > "__pyx_v_localvar = 49;". Notice how the type of__pyx_v_localvar is long > and not a static PyObject*? . If an equivalent "static PyObject*" would > exist in the C-code, I would know how to make 'cy exec print(localvar)' > work (the reason why global variables work, is because they are of type > static PyObject*). I think I could live with the Python code "print(localvar)" not working, as long as I have something like "p localvar" and "pyo localvar". I guess the issue here is the name mangling, which should happen automatically. Can't we map "cy print x" to "p __pyx_v_x" for C types and "pyo __pyx_v_x" for Python object types? (And, isn't that how it works right now?) > I see two ways to make `cy exec print(localvar)` work: > > 1. Let cygdb generate C-code to convert a long (or any other type) to an > equivalent static PyObject* (For long's it would be > __Pyx_PyInt_From_long). Then let cygdb execute this code by running > gdb.parse_and_eval(code). Then read the resulting variable with > something like > > code = ''' > ??????????????????? (PyObject *) PyDict_SetItem( > ??????????????????????? (PyObject *) %d, > ??????????????????????? (PyObject *) %d, > ??????????????????????? (PyObject *) %s) > ??????????????? ''' % (local_dict_pointer, pystringp, cname) > > gdb.parse_and_eval(code) I'd rather not go take that route. If it's a C value, gdb should be able to print it. We should better not go through Python here. > 2. Compile the argument of cy exec (in this case "print(localvar)") to > C-code (while getting the local variables right) and run it using > gdb.parse_and_eval(code). > > > Ideally, cy exec var=123 should work like cy set var=123. That seems a cool feature ? but also a lot of implementation work. My gut feeling is that there may be tons of special cases where code needs to be adapted somehow before or after the code generation in order to make it do what users would expect it to do. I'd rather like to avoid complexity where we can. Stefan From stefan_ml at behnel.de Thu Apr 23 11:39:20 2020 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 23 Apr 2020 17:39:20 +0200 Subject: [Cython] Cython 3.0 alpha 2 released In-Reply-To: <48665f8f-dd38-65cd-b495-0d28c65814f5@behnel.de> References: <48665f8f-dd38-65cd-b495-0d28c65814f5@behnel.de> Message-ID: Hi all, here's the second alpha. I hope we got all major regressions fixed for this release that were reported since alpha 1. Download: https://pypi.org/project/Cython/3.0a2/ Changelog: https://github.com/cython/cython/blob/master/CHANGES.rst Have fun, Stefan Stefan Behnel schrieb am 12.04.20 um 12:24: > Dear Cython users and devs, > > today, I'm happy to announce the first alpha release of Cython 3.0. > > https://pypi.org/project/Cython/3.0a1/ > > It took us a while to get to this point, well more than a year's time, but > we received a lot of help along the way, most notably from David Woods, > Jeroen Demeyer and Matti Picus. Thanks a lot, and also to the many other > contributors! For this release, we already have 182 closed issues and > merged PRs, including 109 PRs contributed by non-core devs! > > > ** What is Cython 3.0? > > Cython 3.0 is our effort to bring Cython up to date with modern Python 3, > after an 18 year long development history. According to the Python mailing > list archive [1] and Greg's download directory [2], Cython's predecessor > Pyrex 0.1 was announced and released to the public on April 4th, 2002. > > Cython is finally coming of age. :) > > > ** So, what's new? > > Too much. Way too much for this announcement. Cython 3.0 comes with a very > long list of new features, bug fixes and modernisations, a few of which are > backwards incompatible, but in a good way. See the latest changelog: > > https://github.com/cython/cython/blob/master/CHANGES.rst > > Here's a short teaser list anyway: > - Python 3 semantics by default, legacy Python 2 semantics via directive. > - No more deprecated NumPy C-API usage. > - Unicode module names, imports, and identifiers (PEP-3131, PEP-489). > - Support for the fast vectorcall protocol (PEP-590). > - Inlined properties on external cdef classes. > - Faster dispatch for fused functions. > - First steps towards supporting CPython's stable ABI (PEP-384). > > > ** How alpha is it? > > Well. It's not complete yet [3]. It still has some known issues. There are > still some unmerged PRs waiting. Support for the limited API is ? limited. > > But, it's in a good shape and probably ready enough for you to make use of > all those cool new features. Please give it a try and report back if you > find issues that we can still improve on in the upcoming pre-releases. PRs > very welcome! > > As always, if it works for you, use it. Generate your C code locally with > it, test it, then ship it to your users. Once the code is compiled, they > don't even have to know that you've used an alpha version. :) > > > Have fun, > > Stefan > > > > [1] https://mail.python.org/pipermail/python-list/2002-April/126661.html > [2] https://www.csse.canterbury.ac.nz/greg.ewing/python/Pyrex/oldtar/ > [3] https://github.com/cython/cython/milestone/58 From stefan_ml at behnel.de Thu Apr 23 13:47:51 2020 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 23 Apr 2020 19:47:51 +0200 Subject: [Cython] [cython-users] Problems with "private" functions/methods in Cython 3.0a2 In-Reply-To: <11959701-bef8-259d-1a78-f630178cb05a@googlemail.com> References: <11959701-bef8-259d-1a78-f630178cb05a@googlemail.com> Message-ID: <0e790956-48e3-24d0-5916-386db10e91b7@behnel.de> Hi, thanks for the very detailed report. I'm CC-ing cython-devel, but let's keep the discussion for this on the cython-users list. The background here is Github issue 1382 and PR 3123 https://github.com/cython/cython/issues/1382 https://github.com/cython/cython/pull/3123 This was newly merged for alpha 2, and I consider it somewhat provisional. It makes "private" Python names follow Python semantics, but if that poses excessive breakage for existing code, then we'll have to find a pragmatic way to deal with it. 'Toni Barth' via cython-users schrieb am 23.04.20 um 19:07: > I just updated Cython from 3.0a1 to 3.0a2 in one of my projects and > noticed that it seems to introduce issues with private > functions/methods, means methods with leading __. > > I noticed two cases which now fail in my project. I'm however unsure if > thats supposed to happen or if its a problem with the new Cython build. > > > Case 1: private function not declared > > > crash.pxd: > > > cpdef __foo() > > cdef class Bar: > ? cpdef run(Bar self) > > > crash.pyx: > > > cpdef __foo(): > ? print("foo") > > cdef class Bar: > ? cpdef run(Bar self): > ??? __foo() > > ??? print("bar") > > > Running this with the following command: > > py -3 -c "import pyximport;pyximport.install();import > crash;crash.Bar().run()" > > > Result: > > crash.c > C:\Program Files (x86)\Microsoft Visual > Studio\Shared\Python36_64\lib\site-packages\Cython\Compiler\Main.py:344: > FutureWarning: Cython directive 'language_level' not set, using '3str' > for now (Py3). This has changed from earlier releases! File: > D:\crash\crash.pxd > ? tree = Parsing.p_module(s, pxd, full_module_name) > > Error compiling Cython file: > ------------------------------------------------------------ > ... > cpdef __foo(): > ? print("foo") > > cdef class Bar: > ? cpdef run(Bar self): > ??? __foo() > ?? ^ > ------------------------------------------------------------ > > crash.pyx:6:4: undeclared name not builtin: __foo At least this looks like a bug to me. Global module names should not be impacted by this change. > Error compiling Cython file: > ------------------------------------------------------------ > ... > cpdef __foo(): > ? print("foo") > > cdef class Bar: > ? cpdef run(Bar self): > ??? __foo() > ?? ^ > ------------------------------------------------------------ > > crash.pyx:6:4: '__foo' redeclared > > Error compiling Cython file: > ------------------------------------------------------------ > ... > cpdef __foo() > ?????????? ^ > ------------------------------------------------------------ > > crash.pxd:1:12: Previous declaration is here Lovely :) > Another problem, probably related, occurs when trying to override a > private method in a derived class: > > > Case 2: overriding private class methods > > > base.pxd: > > > cdef class Base: > ? cdef void __foo(Base self) > ? cpdef run(Base self) > > > base.pyx: > > > cdef class Base: > > ? cdef void __foo(Base self): > ??? print("foo!") > ? > ? cpdef run(Base self): > ??? self.__foo() > > > extend.pxd: > > > from base cimport Base > > cdef class Extend(Base): > ? pass > > > extend.pyx: > > > cdef class Extend(Base): > > ? cdef void __foo(Extend self): > ??? print("bar") > > Running with the following command: > > py -3 -c "import pyximport;pyximport.install();import > extend;extend.Extend().run()" > > > Results in the following output: > > > extend.c > C:\Program Files (x86)\Microsoft Visual > Studio\Shared\Python36_64\lib\site-packages\Cython\Compiler\Main.py:344: > FutureWarning: Cython directive 'language_level' not set, using '3str' > for now (Py3). This has changed from earlier releases! File: > D:\crash\extend.pxd > ? tree = Parsing.p_module(s, pxd, full_module_name) > > Error compiling Cython file: > ------------------------------------------------------------ > ... > cdef class Extend(Base): > > ? cdef void __foo(Extend self): > ????? ^ > ------------------------------------------------------------ > > extend.pyx:3:7: C method '_Extend__foo' not previously declared in > definition part of extension type 'Extend' This, OTOH, is intended. Private methods are not meant to be inherited and overridden. That's what makes them "private" :) That's consistent with Python semantics. I think it's somewhat up for debate if this should apply in the same way to cdef classes as for Python classes. But from a language design point of view, having this kind of difference between the two seems a bad idea. Do you feel like argueing against this? :) Stefan From dw-git at d-woods.co.uk Thu Apr 23 14:47:35 2020 From: dw-git at d-woods.co.uk (da-woods) Date: Thu, 23 Apr 2020 19:47:35 +0100 Subject: [Cython] [cython-users] Problems with "private" functions/methods in Cython 3.0a2 In-Reply-To: <0e790956-48e3-24d0-5916-386db10e91b7@behnel.de> References: <11959701-bef8-259d-1a78-f630178cb05a@googlemail.com> <0e790956-48e3-24d0-5916-386db10e91b7@behnel.de> Message-ID: <8a6bd70b-9c26-597f-5db8-2c71131e0a3c@d-woods.co.uk> Hi, (Sent to both cython-devel and cython-users. However, I'm not subscribed to users I think, so please forward if it doesn't reach there). On closer inspection I believe both are following Python behaviour (and thus behaving correctly). In Python any `__name_preceded_by_double_underscores` used within a class ends up looking up `_Classname__name_preceded_by_double_underscores`. Therefore in case 1 it's looking up `_Bar__foo` and not finding it. Therefore, I think it is the "correct" thing to do. This proved a pain with the `__pyx_unpickle` functions that Cython generates. In the end I just disabled it for `__pyx_` names, which I guess could be called hypocrisy . David On 23/04/2020 18:47, Stefan Behnel wrote: > Hi, > > thanks for the very detailed report. > > I'm CC-ing cython-devel, but let's keep the discussion for this on the > cython-users list. > > The background here is Github issue 1382 and PR 3123 > > https://github.com/cython/cython/issues/1382 > > https://github.com/cython/cython/pull/3123 > > This was newly merged for alpha 2, and I consider it somewhat provisional. > It makes "private" Python names follow Python semantics, but if that poses > excessive breakage for existing code, then we'll have to find a pragmatic > way to deal with it. > > > 'Toni Barth' via cython-users schrieb am 23.04.20 um 19:07: >> I just updated Cython from 3.0a1 to 3.0a2 in one of my projects and >> noticed that it seems to introduce issues with private >> functions/methods, means methods with leading __. >> >> I noticed two cases which now fail in my project. I'm however unsure if >> thats supposed to happen or if its a problem with the new Cython build. >> >> >> Case 1: private function not declared >> >> >> crash.pxd: >> >> >> cpdef __foo() >> >> cdef class Bar: >> ? cpdef run(Bar self) >> >> >> crash.pyx: >> >> >> cpdef __foo(): >> ? print("foo") >> >> cdef class Bar: >> ? cpdef run(Bar self): >> ??? __foo() >> >> ??? print("bar") >> >> >> Running this with the following command: >> >> py -3 -c "import pyximport;pyximport.install();import >> crash;crash.Bar().run()" >> >> >> Result: >> >> crash.c >> C:\Program Files (x86)\Microsoft Visual >> Studio\Shared\Python36_64\lib\site-packages\Cython\Compiler\Main.py:344: >> FutureWarning: Cython directive 'language_level' not set, using '3str' >> for now (Py3). This has changed from earlier releases! File: >> D:\crash\crash.pxd >> ? tree = Parsing.p_module(s, pxd, full_module_name) >> >> Error compiling Cython file: >> ------------------------------------------------------------ >> ... >> cpdef __foo(): >> ? print("foo") >> >> cdef class Bar: >> ? cpdef run(Bar self): >> ??? __foo() >> ?? ^ >> ------------------------------------------------------------ >> >> crash.pyx:6:4: undeclared name not builtin: __foo > At least this looks like a bug to me. Global module names should not be > impacted by this change. > > >> Error compiling Cython file: >> ------------------------------------------------------------ >> ... >> cpdef __foo(): >> ? print("foo") >> >> cdef class Bar: >> ? cpdef run(Bar self): >> ??? __foo() >> ?? ^ >> ------------------------------------------------------------ >> >> crash.pyx:6:4: '__foo' redeclared >> >> Error compiling Cython file: >> ------------------------------------------------------------ >> ... >> cpdef __foo() >> ?????????? ^ >> ------------------------------------------------------------ >> >> crash.pxd:1:12: Previous declaration is here > Lovely :) > > > >> Another problem, probably related, occurs when trying to override a >> private method in a derived class: >> >> >> Case 2: overriding private class methods >> >> >> base.pxd: >> >> >> cdef class Base: >> ? cdef void __foo(Base self) >> ? cpdef run(Base self) >> >> >> base.pyx: >> >> >> cdef class Base: >> >> ? cdef void __foo(Base self): >> ??? print("foo!") >> >> ? cpdef run(Base self): >> ??? self.__foo() >> >> >> extend.pxd: >> >> >> from base cimport Base >> >> cdef class Extend(Base): >> ? pass >> >> >> extend.pyx: >> >> >> cdef class Extend(Base): >> >> ? cdef void __foo(Extend self): >> ??? print("bar") >> >> Running with the following command: >> >> py -3 -c "import pyximport;pyximport.install();import >> extend;extend.Extend().run()" >> >> >> Results in the following output: >> >> >> extend.c >> C:\Program Files (x86)\Microsoft Visual >> Studio\Shared\Python36_64\lib\site-packages\Cython\Compiler\Main.py:344: >> FutureWarning: Cython directive 'language_level' not set, using '3str' >> for now (Py3). This has changed from earlier releases! File: >> D:\crash\extend.pxd >> ? tree = Parsing.p_module(s, pxd, full_module_name) >> >> Error compiling Cython file: >> ------------------------------------------------------------ >> ... >> cdef class Extend(Base): >> >> ? cdef void __foo(Extend self): >> ????? ^ >> ------------------------------------------------------------ >> >> extend.pyx:3:7: C method '_Extend__foo' not previously declared in >> definition part of extension type 'Extend' > This, OTOH, is intended. Private methods are not meant to be inherited and > overridden. That's what makes them "private" :) That's consistent with > Python semantics. > > I think it's somewhat up for debate if this should apply in the same way to > cdef classes as for Python classes. But from a language design point of > view, having this kind of difference between the two seems a bad idea. > > Do you feel like argueing against this? :) > > Stefan > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel From stefan_ml at behnel.de Thu Apr 23 16:32:06 2020 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 23 Apr 2020 22:32:06 +0200 Subject: [Cython] [cython-users] Problems with "private" functions/methods in Cython 3.0a2 In-Reply-To: <8a6bd70b-9c26-597f-5db8-2c71131e0a3c@d-woods.co.uk> References: <11959701-bef8-259d-1a78-f630178cb05a@googlemail.com> <0e790956-48e3-24d0-5916-386db10e91b7@behnel.de> <8a6bd70b-9c26-597f-5db8-2c71131e0a3c@d-woods.co.uk> Message-ID: da-woods schrieb am 23.04.20 um 20:47: > On closer inspection I believe both are following Python behaviour (and > thus behaving correctly). In Python any > `__name_preceded_by_double_underscores` used within a class ends up looking > up `_Classname__name_preceded_by_double_underscores`. Therefore in case 1 > it's looking up `_Bar__foo` and not finding it. Hmm, right. Py3.6 gives me this: >>> class T: ... def f(self): return __xyz ... >>> __xyz = 2 >>> T().f() Traceback (most recent call last): File "", line 1, in File "", line 2, in f NameError: name '_T__xyz' is not defined > Therefore, I think it is the "correct" thing to do. > > This proved a pain with the `__pyx_unpickle` functions that Cython > generates. In the end I just disabled it for `__pyx_` names, which I guess > could be called hypocrisy . Yeah, it seems correct then. Meaning, new code will benefit from the lack of differences with normal Python behaviour. The question is: how bad is it for existing code, and how can we either keep things working or make it easy for users to adapt? Should we implement some kind of fallback lookup that still finds unmangled global names if they exist? I mean, double-underscore names are not entirely unheard of in C code and C libraries. The Python behaviour redners their usage from within classes more difficult. Stefan From dw-git at d-woods.co.uk Thu Apr 23 16:54:48 2020 From: dw-git at d-woods.co.uk (da-woods) Date: Thu, 23 Apr 2020 21:54:48 +0100 Subject: [Cython] [cython-users] Problems with "private" functions/methods in Cython 3.0a2 In-Reply-To: References: <11959701-bef8-259d-1a78-f630178cb05a@googlemail.com> <0e790956-48e3-24d0-5916-386db10e91b7@behnel.de> <8a6bd70b-9c26-597f-5db8-2c71131e0a3c@d-woods.co.uk> Message-ID: Hopefully I've succeeded in subscribing correctly so I can now post to both groups... On 23/04/2020 21:32, Stefan Behnel wrote: > The question is: how bad is it for existing code, and how can we either > keep things working or make it easy for users to adapt? Should we implement > some kind of fallback lookup that still finds unmangled global names if > they exist? > > I mean, double-underscore names are not entirely unheard of in C code and C > libraries. The Python behaviour redners their usage from within classes > more difficult. > I think this could actually be a real problem for people trying to interact with C libraries.? I'd favour a fallback that finds unmangled cdef/c names only (and maybe gives a helpful warning but no match if a Python name is found). That gives 100% compatibility on the Python side, but a sensible fallback on the C side. From stefan_ml at behnel.de Thu Apr 23 17:36:55 2020 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 23 Apr 2020 23:36:55 +0200 Subject: [Cython] [cython-users] Problems with "private" functions/methods in Cython 3.0a2 In-Reply-To: References: <11959701-bef8-259d-1a78-f630178cb05a@googlemail.com> <0e790956-48e3-24d0-5916-386db10e91b7@behnel.de> <8a6bd70b-9c26-597f-5db8-2c71131e0a3c@d-woods.co.uk> Message-ID: <36f1eb7f-3818-2946-baa4-ddb6e66ef89b@behnel.de> da-woods schrieb am 23.04.20 um 22:54: > On 23/04/2020 21:32, Stefan Behnel wrote: >> The question is: how bad is it for existing code, and how can we either >> keep things working or make it easy for users to adapt? Should we implement >> some kind of fallback lookup that still finds unmangled global names if >> they exist? >> >> I mean, double-underscore names are not entirely unheard of in C code and C >> libraries. The Python behaviour redners their usage from within classes >> more difficult. >> > I think this could actually be a real problem for people trying to interact > with C libraries.? I'd favour a fallback that finds unmangled cdef/c names > only (and maybe gives a helpful warning but no match if a Python name is > found). That gives 100% compatibility on the Python side, but a sensible > fallback on the C side. Ok, I think this is worth a ticket by now. Let's discuss this over there. https://github.com/cython/cython/issues/3544 Stefan From stefan_ml at behnel.de Mon Apr 27 12:36:29 2020 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 27 Apr 2020 18:36:29 +0200 Subject: [Cython] Cython 3.0 alpha 3 released In-Reply-To: References: <48665f8f-dd38-65cd-b495-0d28c65814f5@behnel.de> Message-ID: <4aefcbc6-011f-ebe0-76eb-28878dff7b35@behnel.de> ? and a third alpha is out, with several fixes (thanks!) for reported regressions and issues (thanks!), as well as streamlined GIL handling in nogil functions that contain "with gil" sections. Download: https://pypi.org/project/Cython/3.0a3/ Changelog: https://github.com/cython/cython/blob/master/CHANGES.rst This release was brought to you with the invaluable help of Yusuf Cat Stevens and Deutsche Bahn. Thanks to everyone out there who's doing their job keeping others alive/healthy/undepressed/fed/mobile/connected/working/? in these (for many people) difficult days. Stefan Stefan Behnel schrieb am 23.04.20 um 17:39: > Hi all, > > here's the second alpha. I hope we got all major regressions fixed for this > release that were reported since alpha 1. > > Download: > https://pypi.org/project/Cython/3.0a2/ > > Changelog: > https://github.com/cython/cython/blob/master/CHANGES.rst > > Have fun, > Stefan > > > > Stefan Behnel schrieb am 12.04.20 um 12:24: >> Dear Cython users and devs, >> >> today, I'm happy to announce the first alpha release of Cython 3.0. >> >> https://pypi.org/project/Cython/3.0a1/ >> >> It took us a while to get to this point, well more than a year's time, but >> we received a lot of help along the way, most notably from David Woods, >> Jeroen Demeyer and Matti Picus. Thanks a lot, and also to the many other >> contributors! For this release, we already have 182 closed issues and >> merged PRs, including 109 PRs contributed by non-core devs! >> >> >> ** What is Cython 3.0? >> >> Cython 3.0 is our effort to bring Cython up to date with modern Python 3, >> after an 18 year long development history. According to the Python mailing >> list archive [1] and Greg's download directory [2], Cython's predecessor >> Pyrex 0.1 was announced and released to the public on April 4th, 2002. >> >> Cython is finally coming of age. :) >> >> >> ** So, what's new? >> >> Too much. Way too much for this announcement. Cython 3.0 comes with a very >> long list of new features, bug fixes and modernisations, a few of which are >> backwards incompatible, but in a good way. See the latest changelog: >> >> https://github.com/cython/cython/blob/master/CHANGES.rst >> >> Here's a short teaser list anyway: >> - Python 3 semantics by default, legacy Python 2 semantics via directive. >> - No more deprecated NumPy C-API usage. >> - Unicode module names, imports, and identifiers (PEP-3131, PEP-489). >> - Support for the fast vectorcall protocol (PEP-590). >> - Inlined properties on external cdef classes. >> - Faster dispatch for fused functions. >> - First steps towards supporting CPython's stable ABI (PEP-384). >> >> >> ** How alpha is it? >> >> Well. It's not complete yet [3]. It still has some known issues. There are >> still some unmerged PRs waiting. Support for the limited API is ? limited. >> >> But, it's in a good shape and probably ready enough for you to make use of >> all those cool new features. Please give it a try and report back if you >> find issues that we can still improve on in the upcoming pre-releases. PRs >> very welcome! >> >> As always, if it works for you, use it. Generate your C code locally with >> it, test it, then ship it to your users. Once the code is compiled, they >> don't even have to know that you've used an alpha version. :) >> >> >> Have fun, >> >> Stefan >> >> >> >> [1] https://mail.python.org/pipermail/python-list/2002-April/126661.html >> [2] https://www.csse.canterbury.ac.nz/greg.ewing/python/Pyrex/oldtar/ >> [3] https://github.com/cython/cython/milestone/58 > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel >