Guido van Rossum wrote:
> If you want any kind of traction on this I recommend filing an opinionated
> issue on this (explaining why the current behavior is wrong).
Thanks - I'm asking from the point of view of trying to reimplement it. I don't
actually have a strong opinion on whether the curren
Daniel Moisset wrote:
> I might expect that in a "case D(something=__y)" you get the mangling for
> __y, but I'm not sure what the implementation does now and I'm writing from
> my phone
Yes - that case does what you'd expect.
Thanks for the reply.
___
For this code:
class C:
def f(self, x):
match x:
case D(__something=y):
return y
It appears that the name "__something" isn't mangled. Under most other
circumstances I'd expect this to be mangled to "_C__something". Is this:
* intentional,
* accidental, but how that it's done
Victor Stinner wrote:
> My proposed API targets Python 3.12, it's too late for Python 3.11.
> Maybe for Python 3.11, it's ok to add back private
> _PyFloat_FormatAdvancedWriter and _PyLong_FormatAdvancedWriter
> functions to the public C API to restore Cython performance.
I think at this stage the
Victor Stinner wrote:
> On Mon, May 16, 2022 at 11:40 AM dw-...@d-woods.co.uk wrote:
> > Cython used the private _PyUnicodeWriter API (and stopped using it on
> > Py3.11 when it was hidden more thoroughly)
> > I'm not aware of any change in the the private _PyUnicodeWriter API in
> Python 3.11.
Cython used the private _PyUnicodeWriter API (and stopped using it on Py3.11
when it was hidden more thoroughly) so would probably make use of a public API
to do the same thing. It's an optimization rather than an essential of course
___
Python-Dev mail
Larry Hastings wrote:
> [...]
>
> Now comes the one thing that we might call a "trick". The trick: when
> we allocate the ForwardClass instance C, we make it as big as a class
> object can ever get. (Mark Shannon assures me this is simply "heap
> type", and he knows far more about CPython inte
Petr Viktorin wrote:
> Should we care about hacks/optimizations that rely on having the only
> reference (or all references), e.g. mutating a tuple if it has refcount
> 1? Immortal objects shouldn't break them (the special case simply won't
> apply), but this wording would make them illegal.
> A
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
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 p
Greg Ewing wrote:
> To address this there could be an option to choose between
> "compatible code" and "fast code", with the former restricting
> itself to the stable API.
To some extent, that exists at the moment - many of the real abuses of the
CPython internals can be controlled by setting C d
> Will all packages that use Cython have to upgrade Cython to work with 3.10?
For this particular issue you'll only have to upgrade if you use "profiling" (I
doubt that many packages routinely build with Cython profiling turned on).
However, it's possible there are other 3.10 bugfixes in Cython
Are you sure Cython is still broken? It looks like it was fixed back in May
(https://github.com/cython/cython/issues/4153) and all the tests look to be
passing on the 3.10-dev CI run for Cython. I think it only affected the
profiling feature on Cython (which most people will have turned off) so
13 matches
Mail list logo
