+1 for overall.
On Thu, Feb 3, 2022 at 7:45 AM Eric Snow wrote:
>
>
> I'd also like to actually get rid of _Py_IDENTIFIER(), along with
> other related API including ~14 (private) C-API functions. Dropping
> all that helps reduce maintenance costs. However, at least one PyPI
> project
I'm sorry, I was overwhelmed and didn't find the time until now to answer
this. A lot was already said about this, so I'll just briefly explain below
(inline).
On Sat, Jan 29, 2022 at 2:38 AM Victor Stinner wrote:
> On Fri, Jan 28, 2022 at 6:28 PM Guido van Rossum wrote:
> > I think we will
Victor Stinner schrieb am 02.02.22 um 23:23:
On Wed, Feb 2, 2022 at 3:54 PM Stefan Behnel wrote:
So people using stable Python versions like Python 3.10 would not need
Cython, but people testing the "next Python" (Python 3.11) would not
have to manually removed generated C code.
That sounds
I'm planning on moving us to a simpler, more efficient alternative to
_Py_IDENTIFIER(), but want to see if there are any objections first
before moving ahead. Also see https://bugs.python.org/issue46541.
_Py_IDENTIFIER() was added in 2011 to replace several internal string
object caches and to
On Wed, Feb 2, 2022 at 3:41 PM Eric Snow wrote:
> I'd also like to actually get rid of _Py_IDENTIFIER(), along with
> other related API including ~14 (private) C-API functions.
FTR, here is the (private/internal) C-API affected by getting rid of
_Py_IDENTIFIER():
* 21 C-API functions with
On Wed, Feb 2, 2022 at 3:54 PM Stefan Behnel wrote:
> > So people using stable Python versions like Python 3.10 would not need
> > Cython, but people testing the "next Python" (Python 3.11) would not
> > have to manually removed generated C code.
>
> That sounds like an environment variable might
Ronald Oussoren via Python-Dev schrieb am 02.02.22 um 16:44:
On 2 Feb 2022, at 11:50, Stefan Behnel wrote:
Petr Viktorin schrieb am 02.02.22 um 10:22:
- "normal" public API, covered by the backwards compatibility policy (users
need to recompile for every minor release, and watch for
> Maybe we should advertise the two modes more. And make sure that both work.
>
> That would be great — as a long time Cython user, I didn’t know they
existed. To be fair, long-time means I figured out something that works
years ago, and have kept doing that ever since.
It might also help to make
> On 2 Feb 2022, at 11:50, Stefan Behnel wrote:
>
> Petr Viktorin schrieb am 02.02.22 um 10:22:
>> Moving off the internal (unstable) API would be great, but I don't think
>> Cython needs to move all the way to the limited API.
>> There are three "levels" in the C API:
>> - limited API, with
Petr Viktorin schrieb am 02.02.22 um 10:22:
Moving off the internal (unstable) API would be great, but I don't think
Cython needs to move all the way to the limited API.
There are three "levels" in the C API:
- limited API, with long-term ABI compatibility guarantees
That's what
Victor Stinner schrieb am 02.02.22 um 11:35:
I wish that there would be a 3rd option: ship C code generated by
Cython *but* run Cython if this C code "looks" outdated, for example
if building the C code fails with a compiler error.
So, one thing I did yesterday was to make sure that .c files
On Wed, Feb 2, 2022 at 9:25 AM wrote:
> 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
I wish that there would be a 3rd option: ship C code generated by
Cython *but* run Cython if this C code "looks" outdated, for example
if building the C code fails with a compiler error.
So people using stable Python versions like Python 3.10 would not need
Cython, but people testing the "next
On 01. 02. 22 16:42, Christian Heimes wrote:
On 01/02/2022 16.08, Victor Stinner wrote:
--
I would prefer to introduce C API incompatible changes differently:
first fix Cython, and *then* introduce the change.
- (1) Propose a Cython PR and get it merged
- (2) Wait until a new Cython version
On 02/02/2022 09.19, dw-...@d-woods.co.uk wrote:
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
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
16 matches
Mail list logo
