From stefan_ml at behnel.de Sat Aug 14 04:21:14 2021 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 14 Aug 2021 10:21:14 +0200 Subject: [Cython] Remove Py3.4 support in Cython 3.0? Message-ID: Hi, I looked up where Python 3.4 is still being used. Ubuntu 14.04 ? EOS 2019, EOL April 2022 Debian 8 ? EOL Centos 6 ? EOL Later distribution versions have newer CPythons: Ubuntu 16.04: Py3.5 (EOS April 2021, EOL 2024) Debian 9: Py3.5 (EOL June 2022) Centos 7: Py3.6 (EOL June 2024) I think we can safely drop Py3.4 support already for Cython 3.0. The advantage isn't big, since we still support Py2.7, but we can at least stop testing it, and start relying on the Py3.5 C-API for Py3. Given that Py3.5 is also going out of support in major Linux distributions within a year's time, I'd suggest we drop support for it in Cython 3.1, together with Py2 support, making the minimum version Py3.6. That would mean that we can start using f-strings, dict ordering, and what not. Any objections? Stefan From dalcinl at gmail.com Sat Aug 14 04:55:50 2021 From: dalcinl at gmail.com (Lisandro Dalcin) Date: Sat, 14 Aug 2021 11:55:50 +0300 Subject: [Cython] Remove Py3.4 support in Cython 3.0? In-Reply-To: References: Message-ID: On Sat, 14 Aug 2021 at 11:21, Stefan Behnel wrote: > > Given that Py3.5 is also going out of support in major Linux distributions > within a year's time, I'd suggest we drop support for it in Cython 3.1, > together with Py2 support, making the minimum version Py3.6. That would > mean that we can start using f-strings, dict ordering, and what not. > > Any objections? > Not at all! -- Lisandro Dalcin ============ Senior Research Scientist Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dw-git at d-woods.co.uk Sat Aug 14 04:38:28 2021 From: dw-git at d-woods.co.uk (da-woods) Date: Sat, 14 Aug 2021 09:38:28 +0100 Subject: [Cython] Remove Py3.4 support in Cython 3.0? In-Reply-To: References: Message-ID: <2a407910-3588-1691-efb9-522480c1aeb0@d-woods.co.uk> None from me - nobody on Ubuntu 14.04 (or similar) is going to get Cython 3 from their distribution. And if they're installing Cython manually then they can probably install a newer Python manually. Looking at the stats on PyPI (https://pypistats.org/packages/cython) the numbers of downloads for 3.4 are pretty small (a few hundred). And that's for the stable 0.29.x branch mainly I imagine. I doubt if they're the people that are looking to use the latest thing anyway. David On 14/08/2021 09:21, Stefan Behnel wrote: > Hi, > > I looked up where Python 3.4 is still being used. > > Ubuntu 14.04 ? EOS 2019, EOL April 2022 > Debian 8 ? EOL > Centos 6 ? EOL > > Later distribution versions have newer CPythons: > > Ubuntu 16.04: Py3.5? (EOS April 2021, EOL 2024) > Debian 9: Py3.5? (EOL June 2022) > Centos 7: Py3.6? (EOL June 2024) > > I think we can safely drop Py3.4 support already for Cython 3.0. > > The advantage isn't big, since we still support Py2.7, but we can at > least stop testing it, and start relying on the Py3.5 C-API for Py3. > > Given that Py3.5 is also going out of support in major Linux > distributions within a year's time, I'd suggest we drop support for it > in Cython 3.1, together with Py2 support, making the minimum version > Py3.6. That would mean that we can start using f-strings, dict > ordering, and what not. > > Any objections? > > Stefan > > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel From stefan_ml at behnel.de Sat Aug 14 05:05:13 2021 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 14 Aug 2021 11:05:13 +0200 Subject: [Cython] Remove Py3.4 support in Cython 3.0? In-Reply-To: References: Message-ID: <745219c3-5b4f-fbfe-e3c9-7e9dc17b1be8@behnel.de> This should also have gone to cython-users (not just cython-devel), as it has the larger audience. Stefan Behnel wrote: > Hi, > > I looked up where Python 3.4 is still being used. > > Ubuntu 14.04 ? EOS 2019, EOL April 2022 > Debian 8 ? EOL > Centos 6 ? EOL > > Later distribution versions have newer CPythons: > > Ubuntu 16.04: Py3.5? (EOS April 2021, EOL 2024) > Debian 9: Py3.5? (EOL June 2022) > Centos 7: Py3.6? (EOL June 2024) > > I think we can safely drop Py3.4 support already for Cython 3.0. > > The advantage isn't big, since we still support Py2.7, but we can at least > stop testing it, and start relying on the Py3.5 C-API for Py3. > > Given that Py3.5 is also going out of support in major Linux distributions > within a year's time, I'd suggest we drop support for it in Cython 3.1, > together with Py2 support, making the minimum version Py3.6. That would > mean that we can start using f-strings, dict ordering, and what not. > > Any objections? > > Stefan From greg at krypto.org Tue Aug 17 19:37:39 2021 From: greg at krypto.org (Gregory P. Smith) Date: Tue, 17 Aug 2021 16:37:39 -0700 Subject: [Cython] Fwd: [Python-Dev] Re: Making code object APIs unstable In-Reply-To: References: <9ac03f79-d2ff-0f70-c408-b7fda017f92c@python.org> Message-ID: cython developers, heads up, please read the python-dev thread and respond there. (Most people on python-dev are unlikely to be able to communicate with you via a cc to cython-devel@ due to the current subscribers-only-posting mailing list config.) -gps ---------- Forwarded message --------- From: Gregory P. Smith Date: Tue, Aug 17, 2021 at 4:24 PM Subject: Re: [Python-Dev] Re: Making code object APIs unstable To: Victor Stinner Cc: Guido van Rossum , Nick Coghlan , Python-Dev , +cc: cython-devel background reading for those new to the thread: https://mail.python.org/archives/list/python-dev at python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/ On Tue, Aug 17, 2021 at 9:47 AM Victor Stinner wrote: > Since Cython is a common consumer of this C API, can somone please dig > into Cython to see exactly what it needs in terms of API? How does > Cython create all arguments of the __Pyx_PyCode_New() macro? Does it > copy an existing function to only override some fields, something like > CodeType.replace(field=new_value)? > > If possible, I would prefer that Cython only uses the *public* C API. > Otherwise, it will be very likely that Cython will break at every > single Python release. Cython has a small team to maintain the code > base, whereas CPython evolves much faster with a larger team. > > Victor > I don't claim knowledge of Cython internals, but the two places it appears to call it's __Pyx_PyCode_New macro are: https://github.com/cython/cython/blob/master/Cython/Utility/Exceptions.c#L769 in __Pyx_CreateCodeObjectForTraceback() - this one already has a `#if CYTHON_COMPILING_IN_LIMITED_API` code path option in it. and https://github.com/cython/cython/blob/master/Cython/Compiler/ExprNodes.py#L9722 in CodeObjectNode.generate_result_code() that creates PyCodeObject's for CyFunction instances per its comment. Slightly described in this comment http://google3/third_party/py/cython/files/Cython/Compiler/ExprNodes.py?l=397. I don't see anything obvious mentioning the limited API in that code generator. it'd be best to loop in Cython maintainers for more of an idea of Cython's intents and needs with PyCode_New APIs. I've cc'd cython-devel at python.org. -Greg > On Tue, Aug 17, 2021 at 8:51 AM Gregory P. Smith wrote: > > > > Doing a search of a huge codebase (work), the predominant user of > PyCode_New* APIs appears to be checked in Cython generated code (in all > sorts of third_party OSS projects). It's in the boilerplate that Cython > extensions make use of via it's __Pyx_PyCode_New macro. > https://github.com/cython/cython/blob/master/Cython/Utility/ModuleSetupCode.c#L470 > > > > I saw very few non-Cython uses. There are some, but at a very quick > first glance they appear simple - easy enough to reach out to the projects > with a PR to update their code. > > > > The Cython use will require people to upgrade Cython and regenerate > their code before they can use the Python version that changes these. That > is not an uncommon thing for Cython. It's unfortunate that many projects on > ship generated sources rather than use Cython at build time, but that isn't > _our_ problem to solve. The more often we change internal APIs that things > depend on, the more people will move their projects towards doing the right > thing with regards to either not using said APIs or rerunning an up to date > code generator as part of their build instead of checking in generated > unstable API using sources. > > > > -gps > > > > > > On Mon, Aug 16, 2021 at 8:04 PM Guido van Rossum > wrote: > >> > >> On Mon, Aug 16, 2021 at 4:44 PM Nick Coghlan > wrote: > >>> > >>> [...] > >>> A cloning-with-replacement API that accepted the base code object and > the "safe to modify" fields could be a good complement to the API > deprecation proposal. > >> > >> > >> Yes (I forgot to mention that). > >> > >>> > >>> Moving actual "from scratch" code object creation behind the > Py_BUILD_CORE guard with an underscore prefix on the name would also make > sense, since it defines a key piece of the compiler/interpreter boundary. > >> > >> > >> Yeah, we have _PyCode_New() for that. > >> > >>> > >>> Cheers, > >>> Nick. > >>> > >>> P.S. Noting an idea that won't work, in case anyone else reading the > thread was thinking the same thing: a "PyType_FromSpec" style API won't > help here, as the issue is that the compiler is now doing more work up > front and recording that extra info in the code object for the interpreter > to use. There is no way to synthesise that info if it isn't passed to the > constructor, as it isn't intrinsically recorded in the opcode sequence. > >> > >> > >> That's the API style that _PyCode_New() uses (thanks to Eric who IIRC > pushed for this and implemented it). You gave me an idea now: the C > equivalent to .replace() could use the same input structure; one can leave > fields NULL that should be copied from the original unmodified. > >> > >> -- > >> --Guido van Rossum (python.org/~guido) > >> Pronouns: he/him (why is my pronoun here?) > >> _______________________________________________ > >> Python-Dev mailing list -- python-dev at python.org > >> To unsubscribe send an email to python-dev-leave at python.org > >> https://mail.python.org/mailman3/lists/python-dev.python.org/ > >> Message archived at > https://mail.python.org/archives/list/python-dev at python.org/message/NWYMCDAMS4YRJ7ESXNWQ6MIBSRAZEXEM/ > >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > > _______________________________________________ > > Python-Dev mailing list -- python-dev at python.org > > To unsubscribe send an email to python-dev-leave at python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-dev at python.org/message/67DMIW7NQE6M6LEPLANXKZQEFOFVPBBL/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. > -------------- next part -------------- An HTML attachment was scrubbed... URL: