This is very cool Chris -- thanks!
One question:
and with the amazing result of speed:
>
> PyPy 3.8 works
> 10 times faster than the identical code on Python 3.10
> and
> 5.5 times slower than the same example in C++ Qt.
>
Is this primarily Python-QT interaction? or computing the mande
On 2/3/2022 12:15 PM, Victor Stinner wrote:
I'm working bottom-to-top: prepare PyObject and PyVarObject to become
opaque, *and* top-to-bottom: prepare subclasses (structures
"inheriting" from PyObject and PyVarObject) to become opaque like
PyFrameObject.
IMO if PyObject* becomes a handle, the mi
We needed to tame some angry buildbots, but after a small fight, we won
with just some scratches! Here you have a shiny new alpha release: Python
3.11.0a5.
https://www.python.org/downloads/release/python-3110a5/
**This is an early developer preview of Python 3.11**
# Major new features of the 3.
On Thu, Feb 3, 2022 at 4:01 PM Guido van Rossum wrote:
> Why not read through some of that code and see what they are doing with it?
Yep, I'm planning on it.
> I imagine one advantage is that _Py_IDENTIFIER() can be used entirely local
> to a function.
Yeah, they'd have to put something like t
On Thu, Feb 3, 2022 at 7:26 AM Victor Stinner wrote:
> In bpo-39465, I made the _PyUnicode_FromId() compatible with running
> sub-interpreters in parallel (one GIL per interpreter).
>
> A "static" PyUnicodeObject would have to share the reference count
> between sub-interpreters, whereas Py_INCREF
On Thu, Feb 3, 2022 at 2:50 PM Eric Snow
wrote:
> On Wed, Feb 2, 2022 at 11:50 PM Inada Naoki
> wrote:
> > It would be nice to provide something similar to _PY_IDENTIFIER, but
> > designed (and documented) for 3rd party modules like this.
>
> I suppose I'd like to know what the value of _Py_IDEN
On Wed, Feb 2, 2022 at 4:46 PM Guido van Rossum wrote:
A few notes in this:
> Maybe we need to help there. For example IIRC conda-forge will build conda
> packages -- maybe we should offer a service like that for wheels?
>
Yes, conda-forge used a complex CI system to build binaries conda packa
On Thu, Feb 3, 2022 at 7:17 AM Victor Stinner wrote:
> In the top 5000 PyPI projects, I found 11 projects using them:
> [snip[
> They use the these 17 functions:
Thanks! That is super helpful.
> If the _Py_IDENTIFIER() API is removed, it would be *nice* to provide
> a migrate path (tool?) to he
On Thu, Feb 3, 2022 at 6:46 AM Ronald Oussoren wrote:
> Although my gut feeling is that adding a the CI check you mention is good
> enough and adding the tooling for generating code isn’t worth the additional
> complexity.
Yeah, I came to the same conclusion. :)
-eric
___
On Wed, Feb 2, 2022 at 11:50 PM Inada Naoki wrote:
> It would be nice to provide something similar to _PY_IDENTIFIER, but
> designed (and documented) for 3rd party modules like this.
I suppose I'd like to know what the value of _Py_IDENTIFIER() is for
3rd party modules. They can already use PyUn
Oh right, Cython seems to be a false positive.
A code search found 3 references to __Pyx_PyObject_LookupSpecial():
PYPI-2022-01-26-TOP-5000/Cython-0.29.26.tar.gz:
Cython-0.29.26/Cython/Compiler/ExprNodes.py: lookup_func_name =
'__Pyx_PyObject_LookupSpecial'
PYPI-2022-01-26-TOP-5000/Cython-0.29.26
On Wed, Feb 2, 2022 at 2:48 PM Eric Snow
wrote:
> 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
On Thu, Feb 3, 2022 at 6:31 AM Victor Stinner wrote:
> On Wed, Feb 2, 2022 at 11:43 PM Eric Snow
> wrote:
> > My plan is to replace our use of _Py_IDENTIFIER() with statically
> > initialized string objects (as fields under _PyRuntimeState). That
> > involves the following:
> >
> > * add a PyUn
On Thu, Feb 3, 2022 at 6:37 AM Victor Stinner wrote:
> By the way, Argument Clinic now produces way faster calling
> conventions than hand-written METH_VARARGS with PyArg_ParseTuple(). It
> would be make this tool available to 3rd party projects.
>
> Either extract it and put it on PyPI, but it m
On Thu, Feb 3, 2022 at 9:27 AM Victor Stinner wrote:
> Hi Guido,
>
[SNIP]
>
> On Thu, Feb 3, 2022 at 1:40 AM Guido van Rossum wrote:
>
>
[SNIP]
> >
> > Maybe we need to help there. For example IIRC conda-forge will build
> conda packages -- maybe we should offer a service like that for whee
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
Hi Guido,
My "north star", as you say, is the HPy "design" (not the actual HPy
API). I would like to convert PyObject* to opaque handles:
dereferencing a PyObject* pointer would simply fail with a compiler
error.
I'm working bottom-to-top: prepare PyObject and PyVarObject to become
opaque, *and*
By the way, Argument Clinic now produces way faster calling
conventions than hand-written METH_VARARGS with PyArg_ParseTuple(). It
would be make this tool available to 3rd party projects.
Either extract it and put it on PyPI, but it means that Python will
need to Python and pip install something t
On Wed, Feb 2, 2022 at 11:43 PM Eric Snow wrote:
> My plan is to replace our use of _Py_IDENTIFIER() with statically
> initialized string objects (as fields under _PyRuntimeState). That
> involves the following:
>
> * add a PyUnicodeObject field (not a pointer) to _PyRuntimeState for
> each strin
On Wed, Feb 2, 2022 at 11:49 PM Eric Snow wrote:
> FTR, here is the (private/internal) C-API affected by getting rid of
> _Py_IDENTIFIER():
>
> * 21 C-API functions with `_Py_Identifer` parameters - would be dropped
>+ _PyUnicode_FromId()
>+ _PyUnicode_EqualToASCIIId()
>+ _PyObject_Cal
> On 2 Feb 2022, at 23:41, Eric Snow wrote:
>
> I
[…]
>
> Cons:
>
> * a little less convenient: adding a global string requires modifying
> a separate file from the one where you actually want to use the string
> * strings can get "orphaned" (I'm planning on checking in CI)
> * some strings m
On 02. 02. 22 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 long-term ABI compatibi
Hi Guido et. al.,
since May 2021 I have been working at running PyPy on PySide6,
which was a difficult undertaking, since PyPy internally is quite
a bit different.
I declared the project to be ready-to-use when the Mandelbrot
example of the PySide examples
(examples/corelib/threads/mandelbro
23 matches
Mail list logo
