> the module, and its types, can only be initialized once per process
For reference, the Python version where this limitation can be lifted
*relatively easily* is 3.10 (which adds API for type/module association, like
Closed #2345 as completed via #2674.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2345#event-10561805933
You are receiving this because you are subscribed to this thread.
Message ID:
___
The PR is up at https://github.com/rpm-software-management/rpm/pull/2674.
I'd appreciate help with CMake -- I'm not familiar with it and I don't exactly
know what I want from it in terms of versions and options :)
--
Reply to this email directly or view it on GitHub:
Yup, too busy, mostly with a certain security issue.
I've actually picked this up again just last week (but left for a conference on
Thursday). It's now on the top of my TODO list :)
--
Reply to this email directly or view it on GitHub:
Hey, it's been quiet on this front for quite a while. Is this a case of "too
busy with other things", or is there something more to it? Just asking in case
somebody else wants to pickup this work.
--
Reply to this email directly or view it on GitHub:
> AIUI there's no functionality change, except for the init-only-once part?
Init once, dropping 3.1, and mutable type objects (the PoC uses
[`Py_TPFLAGS_IMMUTABLETYPE`](https://docs.python.org/3/c-api/typeobj.html#Py_TPFLAGS_IMMUTABLETYPE`)
but that's 3.10+ only).
And the unknown unknowns –
I had a brief look at the PoC and I don't see anything fundamentally offending
in there, more to the contrary (for one, I will not miss those gigantic
PyTypeObject initializers). I didn't fine-comb the changes but AIUI there's no
functionality change, except for the init-only-once part? In that
Yes I understood about dropping 3.1, but I'm saying we really do not need to
support all those old versions either. So I'm just saying that Python 3.7 would
be an entirely reasonable minimum version to support.
--
Reply to this email directly or view it on GitHub:
I'm only asking to drop Python 3.1.
With the change, a single Stable ABI `.so` would support Python 3.10+ (or even
3.7+), but for older Pythons you could still build version-specific extensions,
like now.
Sorry I didn't make that easy to skim.
--
Reply to this email directly or view it on
"Must build on RHEL latest" is the unwritten rule, so if RHEL 9 has 3.9 then
that would be a "hard limit" on how new we can go.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2345#issuecomment-1380214446
You are receiving this because
>From my perspective, the minimum *I* care about is Python 3.9, since that's
>the RHEL 9 minimum. I would _like_ to have Python 3.6 if we can work it to
>maintain SLE 15 too, but if there's a big QoL enhancement, I'm okay with just
>Python 3.9+.
--
Reply to this email directly or view it on
I'll need to digest this all for a bit, but just a quick note on this:
> I know there's a 3.7+ feature I'd rather rely on for the initial
> implementation, and RPM probably wants to keep 3.6 support.
A feature that makes a big difference makes shooting for 3.7 totally
reasonable.
--
Reply
OK!
A proof of concept is [at my
fork](https://github.com/rpm-software-management/rpm/compare/master...encukou:rpm:python-stable-abi-poc).
The diff is big but most changes are rather mechanical. Read below for context.
How would you prefer me to contribute this? Polish it and submit one big PR,
I've always considered the Python API instability between minor versions a
massive pain in the behind, so I'm glad to hear this is being addressed - I
haven't been paying attention to Python world so this is (good) news to me.
So yes, this would be most welcome unless it turns out to somehow
An alternative would be to use CFFI.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2345#issuecomment-1379331440
You are receiving this because you are subscribed to this thread.
Message ID:
In general, this seems interesting to me, though I'm curious about the caveats.
(I also generally wonder why this isn't just being introduced as a Python 4 so
we can switch Python to major versioned directories instead of major+minor
versioned directories...)
--
Reply to this email directly
Hello,
RPM is typically built/installed as a system component, and the Python bindings
are tied to a particular minor (3.x) version of Python. Using the bindings with
other Python versions is difficult.
I'd like to solve the issue for `rpm` and similar bindings to “system”
packages. There's a
17 matches
Mail list logo
