On Fri, Feb 4, 2022, 16:03 Guido van Rossum wrote:
> I wonder if a better solution than that PR wouldn't be to somehow change
> the implementation of _Py_IDENTIFIER() to do that,
>
Yeah, I had the same realization today. I'm going to try it out.
-eric
>
Congrats Christian! It sounds like this will open new avenues for PyPy (and
maybe also for Qt/PySide6).
--Guido
On Thu, Feb 3, 2022 at 4:25 AM Christian Tismer-Sperling <
tis...@stackless.com> wrote:
> Hi Guido et. al.,
>
> since May 2021 I have been working at running PyPy on PySide6,
> which
Trying to cut things short, there's one thing I'd like to correct:
On Thu, Feb 3, 2022 at 9:15 AM Victor Stinner wrote:
> [...]
>
> Another example is that Cython currently calls PyCode_New() to create
> a fake frame object with a filename and line number. IMO it's the
> wrong abstraction
You *can* allocate unicode objects statically. We do it in deepfreeze, and
Eric's PR under discussion here (
https://github.com/python/cpython/pull/30928) does it. I wonder if a better
solution than that PR wouldn't be to somehow change the implementation of
_Py_IDENTIFIER() to do that, and make
On Fri, Feb 4, 2022 at 12:52 AM Eric V. Smith wrote:
>
> On 2/3/2022 12:15 PM, Victor Stinner wrote:
> >
> > IMO if PyObject* becomes a handle, the migration to the HPy API should
> > be much easier.
>
> It seems to me that moving PyObject* to be a handle leaves you in a
> place very similar to
On 2/4/2022 5:37 PM, Eric Snow wrote:
On Thu, Feb 3, 2022 at 3:49 PM Eric Snow wrote:
I suppose I'd like to know what the value of _Py_IDENTIFIER() is for
3rd party modules.
Between Guido, Victor, Stefan, and Sebastian, I'm getting the sense
that a public replacement for _Py_IDENTIFER()
On Thu, Feb 3, 2022 at 3:53 PM Eric V. Smith wrote:
> 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
Eric Snow schrieb am 04.02.22 um 17:35:
On Fri, Feb 4, 2022 at 8:21 AM Stefan Behnel wrote:
Correct. We (intentionally) have our own way to intern strings and do not
depend on CPython's identifier framework.
You're talking about __Pyx_StringTabEntry (and __Pyx_InitString())?
Yes, that's
ACTIVITY SUMMARY (2022-01-28 - 2022-02-04)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7144 (-13)
closed 51222 (+84)
total 58366 (+71)
Open issues
On Thu, Feb 3, 2022 at 3:49 PM Eric Snow wrote:
> I suppose I'd like to know what the value of _Py_IDENTIFIER() is for
> 3rd party modules.
Between Guido, Victor, Stefan, and Sebastian, I'm getting the sense
that a public replacement for _Py_IDENTIFER() would be worth pursuing.
Considering that
On Fri, Feb 4, 2022 at 8:21 AM Stefan Behnel wrote:
> Correct. We (intentionally) have our own way to intern strings and do not
> depend on CPython's identifier framework.
You're talking about __Pyx_StringTabEntry (and __Pyx_InitString())?
-eric
___
On Thu, 2022-02-03 at 15:32 +0100, 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,
On 2/4/22 6:23 AM, Stefan Behnel wrote:
> One recent example is the new error locations in tracebacks, where PEP 657
explicitly lists
> the new "co_positions" field in code objects as an implementation detail of
CPython. If we
> want to implement this in Cython, then there is no other way than
On Fri, Feb 4, 2022 at 12:55 AM Eric V. Smith wrote:
> It seems to me that moving PyObject* to be a handle leaves you in a
> place very similar to HPy. So why not just focus on making HPy suitable
> for developing C extensions, leave the existing C API alone, and
> eventually abandon the
Ronald Oussoren via Python-Dev schrieb am 03.02.22 um 14:46:
On 2 Feb 2022, at 23:41, Eric Snow wrote:
* 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
Petr Viktorin schrieb am 03.02.22 um 13:47:
On 02. 02. 22 11:50, Stefan Behnel wrote:
Maybe we should advertise the two modes more. And make sure that both
work. There are certainly issues with the current state of the "limited
API" implementation, but that just needs work and testing.
I
Victor Stinner schrieb am 03.02.22 um 22:46:
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 =
On 04.02.22 08:52, Christopher Barker wrote:
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
On Thu, Feb 3, 2022 at 11:49 PM Eric Snow wrote:
> I suppose I'd like to know what the value of _Py_IDENTIFIER() is for
> 3rd party modules.
_Py_IDENTIFIER() API is simple and short, Python creates the Python
string object automatically, *and* clears this object at exit. It's
convenient.
On the
19 matches
Mail list logo
