instead of Compilation directive (Option
2.). I am not sure it this point makes sense, only in case that we
want to keep changes by @da-woods
<mailto:dw-...@d-woods.co.uk> improves the code internals.
I would like to have an agreement on this topic before moving forward
with other comments in t
Hi,
I try not to think too hard about build systems because I don't really
understand them. But:
Most people will probably want to do this from setup.py instead of
calling an executable, so that's probably the most important interface.
I do agree we need something that can be run from the c
Hi Miro,
Sorry for the slightly slow reply.
When I tried to check this I can definitely see compile errors in the
error output from the test. It looks like you're getting a link error
though. I'm just going to do a PR to try to fix that. I'll ping you on
GitHub when that's done.
David
I don't think we've kept the "good first issue" tag on Github rigorously
up-to-date, but see if there's anything tagged with that.
Here are a few ideas:
* The easiest thing to modify is probably the declarations in
Cython/Includes to wrap the C and C++ standard libraries and the Python
C API.
I agree with most of this.
> I also consider Cython 3.1 a prime target for better Limited API
support.
Yes - but I wouldn't treat complete support as a blocker (I don't think
this is what you meant though).
There's a separate question about what we consider the minimum viable
Limited API v
I'm a bit late in replying to this but here are some unordered thoughts.
* I'm fairly relaxed about using `Py_BUILD_CORE` if useful - I think we
mostly do have good fallback paths for most things so can adapt quickly
when stuff changes.
* CYTHON_USE_CPYTHON_CORE_DETAILS sounds reasonable, but i
On 20/09/2023 10:27, Stefan Behnel wrote:
So – disable the feature in Python 3.11 and later? (Currently it's
disabled in 3.12+.)
That seems sensible.
I think the other question is 0.29.x. On Python 3.11+ it silently
produces code that crashes at runtime. We should probably disable it
there
9.x | fast_gil is better | fast_gil is worse | fast_gil crashes
| fast_gil crashes
master | fast_gil is better | fast_gil is better | fast_gil is worse
| fast_gil is worse (but off by default)
On 19/09/2023 20:38, da-woods wrote:
I think the detail that was missing is you need to add
I think the detail that was missing is you need to add the `#cython:
fast_gil = True` to enable it.
For me:
Python 3.9 and 3.10 are basically identical (on master)
**test_gil_already_held**
with fast_gil
Running the test...
took 0.175062894821167
without
Running the test...
took 0.1097679138183
On 14/08/2023 20:06, matus valo wrote:
BTW, I think that the Cython documentation is lacking this change:
https://cython.readthedocs.io/en/latest/src/userguide/migrating_to_cy30.html#python-semantics
There's a segment further down on "Class-private name mangling". I think
if we wanted to men
Hi Matus,
This'll be related to
https://github.com/cython/cython/commit/abeb082098c13e243a2e2658f9eb45f1c151b091
Just an example (in Python, not Cython, but the Cython behaviour should
now be the same):
class C:
... def f(self, __kwd):
... print(locals())
...
>>> C().f(1)
{'self':
So my superficial thoughts:
1. The buffer protocol has two bits. The first says "given this
predictable memory layout, you can look up an item in memory with these
rules"; the second describes what the items in memory are. I think
you're only proposing to change the second part of it. I'd enco
On 20/05/2023 10:59, Stefan Behnel wrote:
It's probably a good time to have a final call for merges. Promoting
and voting for PRs is welcome.
I've flagged a couple of PRs for possible merging. They're both fairly
minor Python-compatibility fixes so it probably isn't a disaster if
they're mi
Hi Matus,
I made a change to optimize dispatch of fused memoryview types. I
suspect that's inadvertently caused the change. I have a reasonable idea
what needs to be fixed, but would need to investigate properly.
I don't think it's an intended change.
David
On 23/04/2023 12:14, matus valo
Hi,
I'm not sure if it's necessary to for me to reply to this, but: thanks.
Hopefully some of the features will be (or already have been) useful to
people.
David
On 31/07/2022 10:15, Stefan Behnel wrote:
Hi everyone,
with the release of the first 3.0 alpha that supports Python 3.11
(aptly
Hi Matus,
I've had a look at your documentation PRs and merged 2/3 of them, so
hopefully that's some progress.
The other's are a little larger and a little outside my expertise so
it'd need a much more detailed look before I was confident doing
anything. I only got the power to merge things
On 26/10/2021 07:53, Stefan Behnel wrote:
Am 26. Oktober 2021 07:54:10 MESZ schrieb Lisandro Dalcin:
In any case, if you know how and can implement the __future__ import,
that
would be great. Otherwise, valid Python3 code using that import
currently fails to compile in Cython.
Probably just an
I suspect the answer to this is still "wait and see" but: do we have an
opinion on what we want to do about annotations in Cython 3.
Currently we're targetting PEP-563 behaviour. To me it looks fairly
likely that this won't be what Python decides on. I guess the likely
outcomes are "status quo
favour of keeping one simpler option. But the code to do this mostly
already exists (somewhere)
On 25/10/2021 19:11, da-woods wrote:
> [...]
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
None from me - nobody on Ubuntu 14.04 (or similar) is going to get
Cython 3 from their distribution. And if they're installing Cython
manually then they can probably install a newer Python manually.
Looking at the stats on PyPI (https://pypistats.org/packages/cython) the
numbers of downloads f
https://github.com/cython/cython/pull/3804 (__del__ in cdef classes)
looks pretty complete to me.
https://github.com/cython/cython/pull/3743 (duplicate utility code) is
hopefully also pretty complete and does fix some bugs that have been
recurred a few times.
David
On 24/03/2021 19:50, St
They're generated using a string-substitution tool (and thus hard to
search for). But the code is
https://github.com/cython/cython/blob/8609e0fa7d361f1392823ff6e1a618720cd62df3/Cython/Utility/MemoryView_C.c#L130.
I found it by searching for "ObjectToMemviewSlice ", which appears just
above the
I'm tactically ignoring the bits of this I don't know the answer to:
> there are issues marked as "blockers", are all of them truly critical
I think the main criteria for being a "blocker" was to try to keep
significant breaks in compatibility to the Cython 3 release (so that
users might been
1. I'm not sure why there would be any dependency on a C compiler in
either mine or Celelibi's proposal. Could you please elaborate? At
least in my proposal, we only ever go from Cython AST to Cython AST
and use Python to do it. None of these things require a C compiler.
To me it looked like Ce
A few things to point out:
1) Because Cython is mainly a is code translation tool it doesn't
currently have an overview of how things would eventually be evaluated -
it leaves a lot for the C compiler to sort out. Your suggestion would
presumably add a dependency on a C compiler at the .pyx ->
https://github.com/cython/cython/issues/1071
On 02/08/2020 18:23, Stefan Behnel wrote:
Am 2. August 2020 17:02:39 MESZ schrieb da-woods:
I'm not convinced that compiler directives like "infer_types" should
propagate into the cimported files at all.
It seems reasonable to me th
I'm not convinced that compiler directives like "infer_types" should
propagate into the cimported files at all.
It seems reasonable to me that these should be controlled by the author
of the pxd file, not by the eventual cimporter.
On 02/08/2020 14:18, Stefan Behnel wrote:
Oliver Haas schr
Hopefully I've succeeded in subscribing correctly so I can now post to
both groups...
On 23/04/2020 21:32, Stefan Behnel wrote:
The question is: how bad is it for existing code, and how can we either
keep things working or make it easy for users to adapt? Should we implement
some kind of fallba
Hi,
(Sent to both cython-devel and cython-users. However, I'm not subscribed
to users I think, so please forward if it doesn't reach there).
On closer inspection I believe both are following Python behaviour (and
thus behaving correctly). In Python any
`__name_preceded_by_double_underscores`
om C++ classes
from Cython, it'd be good to have more seamless (and efficient)
integration with those.
On Sun, Mar 15, 2020 at 1:34 PM da-woods wrote:
On 15/03/2020 08:14, Stefan Behnel wrote:
What makes C structs and C++ classes special enough to make this a separate
language feature?
(I've not got the hang of the difference between "reply" and
"reply-to-list" so initially sent this to the wrong place...)
I've pinged a couple that would be nice to have because they both target
Python compatibility:
https://github.com/cython/cython/pull/3323/
https://github.com/cython/cython
On 15/03/2020 08:14, Stefan Behnel wrote:
What makes C structs and C++ classes special enough to make this a separate
language feature? That should be part of a motivation somewhere (probably
in a ticket
Most of the other major things you could want to wrap are covered
through other mechanisms
re useful to have a keyword
arg for the name of the generated extension class?
-Original Message-----
From: cython-devel
On Behalf Of da-woods
Sent: Friday, March 13, 2020 12:02 PM
To: cython-devel@python.org
Subject: Re: [Cython] Auto-generation of wrapper types
(Sorry, originally
rapping
the C class/struct.
-Original Message-
From: cython-devel
On Behalf Of da-woods
Sent: Thursday, March 12, 2020 4:12 PM
To: cython-devel@python.org
Subject: [Cython] Auto-generation of wrapper types
The process of wrapping a C struct or C++ class in an extension type often h
The process of wrapping a C struct or C++ class in an extension type
often has the user doing a pretty mechanical duplication of
attributes/functions that Cython already knows about. I'm looking at doing:
cdef struct S:
int a
# etc.
then `cython.autowrap[S]` would create an extensi
Related to https://github.com/cython/cython/issues/3343
One issue with the current code generated for fastcall function is that
for a function like:
def f(a, *args, **kwds):
# something...
the wrapper function immediately generates a tuple for `args` and a dict
for `kwds`, which presumab
36 matches
Mail list logo
