[Cython] How to detect CyFunction?

Hi, I have a very technical question about Cython.Compiler.Nodes.DefNode: how can I know whether the instance represents a PyCFunction (built-in function) or a CyFunction (Cython function)? I've tried all the obvious conditions such as checking self.is_cyfunction, self.py_cfunc_node.binding and env

Re: [Cython] Progress towards Cython 3.0

On 2019-08-04 09:16, Stefan Behnel wrote: But also the "binding" PR is a big one that will need some more fiddling with the details, some of which can be investigated separately. Does that have to be part of Cython 3.0? It may not be worth blocking Cython 3.0 for this. ___

[Cython] Empty defines of Py_TPFLAGS_METHOD_DESCRIPTOR?

Hello, What's the purpose of commit https://github.com/cython/cython/commit/8ac1a6a55fc44ff858cc367af556250a91f71d16 I can't think of any reasonable scenario where Py_TPFLAGS_METHOD_DESCRIPTOR would be defined differently than in CPython (i.e. with value 1<<17). This is an honest question,

[Cython] Working on METH_FASTCALL and vectorcall support

Hello, this is just to let you know that I'm planning to add support for functions/methods defined with METH_FASTCALL instead of METH_VARARGS on CPython 3.7. Once this is implemented, it will be fairly easy to use vectorcall (PEP 590) for cython_function_or_method. Jeroen. ___

[Cython] Reason for __Pyx_PyObject_Call2Args, __Pyx_PyObject_Call3Args

Is there any particular reason why Cython has specific code like __Pyx_PyObject_Call2Args, __Pyx_PyObject_Call3Args, ... And then there is even more complicated Python code in PyMethodCallNode generating something like __Pyx_PyObject_Call2Args for an arbitrary number of arguments. This could

Re: [Cython] Hooking tp_clear()

On 2019-01-09 22:12, Stefan Behnel wrote: I would like to avoid adding Cython specific features that are better served by the general finalisation mechanism of PEP-442. That could also be used as argument against @cython.no_gc_clear but we still have that anyway. Second, with PEP-442 you don

Re: [Cython] Hooking tp_clear()

(reviving this thread after I thought about it some more...) As I mentioned in the original post, I want something like __dealloc__ but with access to a particular cdef attribute (representing a Python object). Since Python attributes of cdef classes may have been cleared by tp_clear, they can

Re: [Cython] longintrepr.h issues with MinGW

On 2018-10-24 07:58, Jeroen Demeyer wrote: If you care about MinGW, there is also this CPython issue which makes it basically impossible to compile any Cython extension on MinGW: https://bugs.python.org/issue11566 I forgot to say that this makes it impossible to compile any *C++* Cython

Re: [Cython] longintrepr.h issues with MinGW

If you care about MinGW, there is also this CPython issue which makes it basically impossible to compile any Cython extension on MinGW: https://bugs.python.org/issue11566 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mai

Re: [Cython] Failing test reimport_from_subinterpreter

OK, I finished analyzing the problem. It's a combination of: 1. the Sage wrapper around the Cython installer setting PYTHONPATH 2. the reimport_from_subinterpreter test failing if PYTHONPATH is set I'll open a PR quick. ___ cython-devel mailing list c

Re: [Cython] Failing test reimport_from_subinterpreter

n 2018-10-22 16:44, Jeroen Demeyer wrote: The entries marked with # < are different but I don't know why. There is a difference in $PYTHONPATH. When it works, PYTHONPATH equals '/home/jdemeyer/sage-test/local/var/tmp/sage/build/cython-0.29/src/TEST_TMP/support/lib.linux-ppc6

Re: [Cython] Failing test reimport_from_subinterpreter

On 2018-10-21 15:44, Stefan Behnel wrote: Maybe print "sys.path" and "sys.meta_path" in a couple of places? So I did and the problem is indeed related to sys.path. When running *only* the reimport_from_subinterpreter tests, sys.path starts with the following entries: '' '/home/jdemeyer/sage

Re: [Cython] Failing test reimport_from_subinterpreter

On 2018-10-16 20:30, Stefan Behnel wrote: Difficult to say why this would fail to find the package. Could it be an import path problem? Current directory missing from the PYTHONPATH or something like that? The problem is that the error depends on the proverbial "phase of the moon". When runnin

[Cython] Failing test reimport_from_subinterpreter

Hello, I'm getting various reports of the test reimport_from_subinterpreter failing (within Sage, Cython 0.29, Python 2.7.15). Annoyingly, the problem can only be reproduced when running the full Cython testsuite, not when running the test in isolation. I'll continue to investigate, but I'm

Re: [Cython] Safer exception handling

On 2018-09-17 15:44, Robert Bradshaw wrote: One of the pain points in Cython is that one must explicitly annotate non-object returning functions with except clauses. Would it be worth trying to change the default here, making exception-suppressing opt-in rather than opt-out? Just to clarify thi

Re: [Cython] Safer exception handling

On 2018-09-17 15:44, Robert Bradshaw wrote: One of the pain points in Cython is that one must explicitly annotate non-object returning functions with except clauses. Would it be worth trying to change the default here, making exception-suppressing opt-in rather than opt-out? There are a couple o

Re: [Cython] Hooking tp_clear()

On 2018-09-07 06:35, Stefan Behnel wrote: Maybe you actually want "tp_finalize"? https://www.python.org/dev/peps/pep-0442/ Cython moves "__del__" methods there in Py3.4+. First of all, are you sure? I tried to cythonize cdef class X: def __del__(self): pass but the generated C c

[Cython] Hooking tp_clear()

Hello, Cython's __dealloc__ special method is meant to deal with cleaning up instances of cdef classes. However, this hooks tp_dealloc() and does not have meaningful access to Python attributes, since those might have been cleared by tp_clear(). I have a concrete use case where I want someth

Re: [Cython] Cython 0.29 – or 29.0 ?

On 2018-08-19 08:26, Stefan Behnel wrote: Should we make that a new directive rather than a language level? Like "py2_str=str"? That would allow its use together with language_level=3 already in the next release. With a new new directive, you also run into compatibility problems. What should

Re: [Cython] Cython 0.29 – or 29.0 ?

Basically I am asking for type("foo") is str both on Python 2 and Python 3. That's another breaking change I'm not following here... what I'm asking is how Cython behaves currently (with language_level=2). ___ cython-devel mailing list cython-dev

Re: [Cython] Cython 0.29 – or 29.0 ?

On 2018-08-18 10:52, Robert Bradshaw wrote: Do the existing c_string_type and c_string_encoding directives not cover this usecase? Those seem to refer to C strings, I am talking about the Python type of string literals. I suppose what you're asking for is str being the str of the runtime, e

Re: [Cython] Cython 0.29 – or 29.0 ?

On 2018-08-17 11:44, Stefan Behnel wrote: https://github.com/cython/cython/issues?q=is%3Aissue+is%3Aopen+label%3A%22Python+Semantics%22 Please add https://github.com/cython/cython/issues/1635 ___ cython-devel mailing list cython-devel@python.org https

Re: [Cython] Cython 0.29 – or 29.0 ?

On 2018-08-17 11:44, Stefan Behnel wrote: Hej, that gives us an alternative for the versioning switch. We could release Cython 3.0 when we change the default language level (and require users to select "language_level=2" for legacy code). Definitely a breaking change that merits inceasing the maj

Re: [Cython] Cython 0.29 – or 29.0 ?

On 2018-08-17 21:51, Robert Bradshaw wrote: It'd be nice to change the default of cython.binding as well (breaking change). Ideally, after PEP 580 is accepted :-) ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/l

Re: [Cython] Cython 0.29 – or 29.0 ?

I vote for 1.0 Version 29.0 sounds too much like marketing. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Should we start requiring "language_level=2" for .pyx files?

On 2018-05-31 16:35, Erik Bray wrote: Perhaps you could clarify something: I tried suggesting a while ago that Sage start using language_level=3 at least when actually building Sage on Python 3. I know this isn't necessary but it just seemed to make logical sense. But Jeroen was convinced it w

[Cython] PEP draft to get rid of the "cyfunction" class

I have drafted a PEP (not officially submitted yet) to unify built-in and Python functions. Cython could benefit from this because cyfunctions could finally be considered functions without sacrificing performance. You find the proposal at https://github.com/jdemeyer/PEP-functions For comments

[Cython] Workshop on interfacing (math) software with low level libraries

Dear Cython developers, This is a reminder of ODK's workshop on "Interfacing (math) software with low-level libraries", April 30th-May 4th in Cernay near Paris: https://github.com/OpenDreamKit/OpenDreamKit/issues/251 Registrations have started (see the above web page). Details: (Math)

Re: [Cython] Multiple inheritance with old-style classes in Python 2?

On 2018-01-25 18:54, Robert Bradshaw wrote: No, we don't care about supporting this, but we should detect and reject it informatively when possible. Good. I'll create a PR. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/

[Cython] Multiple inheritance with old-style classes in Python 2?

Do we want to support Python 2 old-style classes for multiple inheritance? Personally, I don't think that we should, but it's something that has to be decided. The reason I ask is that my code from https://github.com/cython/cython/pull/2033 is actually broken when given an old-style class. _

[Cython] Return types of declarations in Includes/cpython

Many Python/C API functions create objects of a known type. For example, PyUnicode_Decode() always returns a "unicode" object. In some cases, this return type is reflected in the declaration in Cython/Includes/cpython, in other cases (such as PyUnicodeDecode() that I just mentioned) not. What

Re: [Cython] Cython master emits tons of 'foo' redeclared warnings

See https://github.com/cython/cython/issues/1874 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython master emits tons of 'foo' redeclared warnings

Even Cython itself triggers this warning many times: warning: Cython/Compiler/Code.py:380:4: 'format_code' redeclared warning: Cython/Compiler/Code.py:442:4: 'none_or_sub' redeclared warning: Cython/Compiler/Code.py:693:4: 'new_label' redeclared warning: Cython/Compiler/Code.py:71

[Cython] Cython master emits tons of 'foo' redeclared warnings

When compiling SageMath with Cython master, I get literally thousands of warnings like warning: sage/rings/polynomial/laurent_polynomial.pyx:177:10: 'number_of_terms' redeclared What is the meaning of this warning? As far as I know, Sage is not doing anything wrong here, so I feel like Cytho

Re: [Cython] Why does embed-position use relative filenames?

My use case is for calling Cython at runtime. For example, using cython.inline or %%cython or the SageMath-specific cython() function. In that case, absolute paths make the most sense since you want to support the user running Cython somewhere and then doing chdir(). Perhaps we could keep the

Re: [Cython] Why does embed-position use relative filenames?

On 2017-10-25 14:42, Erik Bray wrote: IMO the relative paths make more sense in a way, because when the module is installed the path is relative to the file's location relative to its `sys.path` entry. If it defaulted to absolute paths I didn't say that it should default to absolute paths. I a

[Cython] Why does embed-position use relative filenames?

When Cython is run with the --embed-position option (or when Cython.Compiler.Options.embed_pos_in_docstring is true), Cython writes headers in the docstring like File: sage/rings/integer.pyx (starting at line 358) The filenames that Cython uses here are always made relative to the current wor

Re: [Cython] Issues with CYTHON_FALLTHROUGH

See also https://github.com/cython/cython/pull/1930 (which may be a different issue) ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

[Cython] Website still mentions Python 3.2

I think that this sentence on cython.org is outdated: The C code is generated once and then compiles with all major C/C++ compilers in CPython 2.6, 2.7 (2.4+ with Cython 0.20.x) as well as 3.2 and all later versions. ___ cython-devel mailing list cyt

Re: [Cython] Cython 0.27 alpha 1 is available

Regarding Changelog item * gdb support for Python code (libpython.py) was updated to the latest version in CPython 3.7 (git rev 5fe59f8). Does that fix https://github.com/cython/cython/issues/1655 ___ cython-devel mailing list cython-devel@python.org

Re: [Cython] Release candidate for 0.26.1

All fine in SageMath. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython 0.26 beta

On 2017-07-12 17:13, Robert Bradshaw wrote: Could also be https://github.com/cython/cython/pull/1728 , though of course correctness trumps speed. That would be unlikely since we currently do *NOT* use binding=True in SageMath, so that patch should not affect anything.

Re: [Cython] Cython 0.26 beta

On 2017-07-10 23:51, Robert Bradshaw wrote: https://github.com/cython/cython/archive/0.26b2.zip Everything fine in SageMath! I did notice a speed regression and I suspect that https://github.com/cython/cython/pull/1719 might be the reason. ___ cython

Re: [Cython] Cython 0.26 release

On 2017-06-21 21:51, Robert Bradshaw wrote: I'll see if I can put together a patch. For what? For Sage? For Cython? Anyway, I think that coping with this new error message is not particularly hard, just a lot of work. That's why I would prefer a warning instead of an error. That way, we can

Re: [Cython] Cython 0.26 release

On 2017-06-21 20:25, Robert Bradshaw wrote: I suppose in that case we just got lucky that no one cimported these classes and tried to use methods after this point in the vtable... I think that's the case indeed. ___ cython-devel mailing list cython-d

Re: [Cython] Cython 0.26 release

On 2017-06-21 17:44, Robert Bradshaw wrote: Is it cdef->cpdef, or something else? Yes, it is. It's possible that the error needs to be made narrower, but I'd really like to avoid incorrect code that could lead to wrong methods being called. Fine... we can still patch Cython in Sage. __

Re: [Cython] Cython 0.26 release

See https://github.com/cython/cython/issues/1744 This seems to be the final issue breaking SageMath with Cython master. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython 0.26 release

I'm getting an infinite recursion in deepcopy() in fresh_finally_clause() here: https://github.com/cython/cython/blob/master/Cython/Compiler/Nodes.py#L7022 I'm reporting it now in case you immediately know what the problem is. I'll try to analyse it later.

Re: [Cython] Cython 0.26 release

Could the error from https://github.com/cython/cython/issues/1732 at https://github.com/cython/cython/blob/master/Cython/Compiler/Symtab.py#L2099 be a warning instead? SageMath has quite a bit of code hitting this error. It would make our life easier if we could fix it gradually instead of being

Re: [Cython] Cython 0.26 release

This is breaking SageMath: https://github.com/cython/cython/issues/1739 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Next Cython Release

On 2017-06-12 19:35, Robert Bradshaw wrote: I've been wanting to do a release for a while, just haven't gotten around to it. Yes, let's get one out soon. If you do, could you please consider https://github.com/cython/cython/pull/1654 or at least say why you don't like it. _

[Cython] Automatically add include_dirs for externs (#1654)

Dear Cython developers, as part of a big effort to make SageMath less monolithic and make it part of a larger ecosystem, we are splitting off certain modules from SageMath as separate packages. cysignals was an early example of this. Given that we use Cython a lot, it is really important for

Re: [Cython] lshift_int test failing Re: Cython 0.25.2

On 2016-11-21 06:36, Yaroslav Halchenko wrote: On Thu, 17 Nov 2016, Robert Bradshaw wrote: I'm preparing another bugfix release. Try it out at https://github.com/cython/cython/archive/966a296ac4e4862dee9a571ee412886ca3c61144.zip on some platforms , e.g. armel: https://buildd.debian.org/s

Re: [Cython] Regression since 0.25a0 involving std::vector

On 2016-10-18 17:47, Robert Bradshaw wrote: Try https://github.com/cython/cython/archive/0.25.x.zip Works perfectly in Sage! ___ cython-devel mailing list cython-devel@python.org https://mail.pytho

[Cython] Regression since 0.25a0 involving std::vector

This is a new regression introduced since 0.25a0, found while testing Sage with 0.25b1: from libcpp.vector cimport vector cdef extern from *: cdef cppclass BoostGraph[T]: vector[unsigned long] bandwidth_ordering() ctypedef BoostGraph[int] BoostVecDiGraph Error compiling Cython f

Re: [Cython] Cython release

On 2016-09-09 10:11, Robert Bradshaw wrote: I'd like to put out another Cython release shortly. Is anyone aware of anything that we should try to get in before then? I just built the SageMath distribution with latest Cython master and there were 2 issues (both easily fixed): - Build issue wi

Re: [Cython] Cython release

On 2016-09-09 10:11, Robert Bradshaw wrote: I'd like to put out another Cython release shortly. Do you mean a 0.24.x release or 0.25? Anyway, this is a serious bug breaking SageMath: https://github.com/cython/cython/issues/1433 ___ cython-devel mail

[Cython] Cython docs are for version 0.15pre

The page https://cython.readthedocs.io/en/latest/ has the documentation for Cython version 0.15pre. How did that happen??? ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] BUG: cannot override cdef by cpdef method in .pxd

Fixed with a 1-line change: https://github.com/cython/cython/pull/545 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Migration of tickets from trac to github

We should also about a convention about naming testsuite files. For example, there is tests/compile/distutils_libraries_T845.srctree Should this be changed to tests/compile/distutils_libraries_GH1234.srctree if this becomes GitHub issue #1234? ___ cyt

Re: [Cython] Migration of tickets from trac to github

What about attachments to Trac tickets? This ones mentions a patch, but the patch does not appear on GitHub as far as I can tell: https://github.com/robertwb/issues-import-test/issues/122 ___ cython-devel mailing list cython-devel@python.org https://ma

Re: [Cython] Migration of tickets from trac to github

There are some duplicates, like https://github.com/robertwb/issues-import-test/issues/130 and https://github.com/robertwb/issues-import-test/issues/137 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-

Re: [Cython] Migration of tickets from trac to github

On 2016-07-29 06:50, Robert Bradshaw wrote: I'm not quite sure how to serve the mappings I think it's really important to keep redirects from the old Trac tickets to GitHub. There are a lot of links from SageMath to some Cython Trac ticket and it would be a shame to lose that. Related to t

[Cython] BUG: cannot override cdef by cpdef method in .pxd

Hello, I recently learned from Robert Bradshaw that it is legal in Cython to override cdef methods by cpdef methods. But doing this in a .pxd file causes a compile-time error: *foo.pyx*: cdef class Base(object): cdef meth(self): print("Base.meth()") cdef class Derived(Base):

Re: [Cython] Cython infrastructure

On 2016-07-20 08:01, Robert Bradshaw wrote: let alone all of Sage Curious. Does Cython upstream regularly test SageMath? I know I test Cython master occasionally on SageMath and stuff breaks sometimes. ___ cython-devel mailing list cython-devel@pyt

Re: [Cython] cython.org

On 2016-06-06 07:43, Robert Bradshaw wrote: trac - UW - the big loss (not sure how old any backup is) Has there been any attempt to restart the Cython trac? Is the data still there? ___ cython-devel mailing list cython-devel@python.org https://mail.

Re: [Cython] Virtual cpdef methods

On 2016-06-21 08:17, Jeroen Demeyer wrote: But hang on, are you sure that this works? The C functions for cdef and cpdef functions have a different signature: cpdef functions have a __pyx_skip_dispatch argument while cdef functions don't have such an argument. Answering my own questio

Re: [Cython] Virtual cpdef methods

On 2016-06-20 17:31, Robert Bradshaw wrote: All methods (cdef, cpdef, and def) are virtual by default in Cython, just like Python. I meant "pure virtual" or "abstract": just declared but without an implementation. Sounds like you want a cdef function to me. You can override a cdef function

[Cython] Virtual cpdef methods

Hello, I would like to have a "virtual" cpdef method: something which allows a fast Cython call *when implemented* but without a default implementation. The most simple implementation would be a "cpdef" method but without an entry for the method in the Python method table. Of course, the "c

Re: [Cython] Supporting cython.operator in C

On 2016-06-02 21:12, Robert Bradshaw wrote: "if isinstance(x, (int,long))", which is parsed as "if PyInt_Check(x) or PyLong_Check(x)" is slightly slower than "if PyInt_Check(x) || PyLong_Check(x)". That is very surprising. How much slower? With GCC 4.9.3, roughly 4% for a simple loop like fo

Re: [Cython] Supporting cython.operator in C

On 2016-06-02 05:43, Robert Bradshaw wrote: 2. "x || y" because Cython's "x or y" generates complicated code which isn't optimized as well as "x || y". I just tried using gcc -O3 and the resulting assembly is identical. Well, that would depend on what x and y are. A very concrete example: "

Re: [Cython] Supporting cython.operator in C

On 2016-06-02 05:43, Robert Bradshaw wrote: You can always define your own macro #define ASSIGN(a, b) (a = b). That's basically my whole point. This ASSIGN should be called cython.operator.assign. ___ cython-devel mailing list cython-devel@python.or

Re: [Cython] Supporting cython.operator in C

On 2016-05-31 20:35, Robert Bradshaw wrote: I can't think of any fundamental reason these couldn't be implemented in C, but there's really no need to do so as they can't be overridden in C. Well, for the comma operator there might be no reason. However, it would be nice if one could generate a

[Cython] Supporting cython.operator in C

The following code cimport cython.operator cdef long foo(long x, long y): return cython.operator.comma(x, y) gives AttributeError: 'CBinopNode' object has no attribute 'analyse_c_operation' Is there any fundamental reason why such operators are only implemented for C++ and not pure C? Wh

Re: [Cython] @staticmethod decorator applied twice

I created http://trac.cython.org/ticket/880 for some issues regarding @staticmethod ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

[Cython] Illegal C code generated with numpy complex type

Current Cython git master breaks SageMath because Cython generates calls to non-existing functions like fabs_npy_float64(). Since this is a regression since Cython 0.24, I made a blocker ticket http://trac.cython.org/ticket/879 Jeroen. ___ cython-dev

[Cython] @staticmethod decorator applied twice

When investigating some issue with decorators, I noticed the following stange thing: it seems that the @staticmethod decorator is actually applied twice in some cases. For example, the testsuite file tests/run/static_methods.pyx contains the following code: cdef class A: @staticmethod

Re: [Cython] Cygwin: Handling missing C99 long double functions

On 2016-04-26 16:58, Erik Bray wrote: The problem now is that many of libm long double functions like sqrtl, tanl, etc. are missing on Cygwin Just to understand the issue better, can you elaborate how this impacts Cython? ___ cython-devel mailing li

Re: [Cython] cdef public declarations

On 2016-04-12 10:49, Erik Bray wrote: Do you have a reference about this distinction on hand? I think these two links are useful: [1] http://docstore.mik.ua/orelly/unix3/mac/ch05_03.htm [2] http://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx _

[Cython] cdef public declarations

(this thread is related to the thread "Question about how best require compiler options for C sources") I have a question for Cython users and developers: are you sure that "cdef public" actually works as documented at http://docs.cython.org/src/userguide/external_C_code.html#public-declaratio

Re: [Cython] Fwd: Question about how best require compiler options for C sources

On 2016-04-12 10:08, Erik Bray wrote: OSX issues aside, I was under the impression that this is needed for cysignals in particular. No. cysignals is complicated, but it doesn't need dynamic linking to Python modules (.so files). It does need "internal" linking: it needs to link a non-Cython-g

Re: [Cython] Fwd: Question about how best require compiler options for C sources

On 2016-04-12 10:16, Erik Bray wrote: That said, I think it makes more sense for cythonize() to read the distutils options from the C source instead of the Cython source, though in practice I don't know if it's a worthwhile change or not. I don't quite get what you mean. The C file is only read

Re: [Cython] Fwd: Question about how best require compiler options for C sources

On 2016-04-11 15:23, Erik Bray wrote: In this case I really do want the symbol "hello" to be exported by the DLL, as well as be understood between translation units making up the same library. Are you really sure that you want this? I doubt that this is supported on OS X: on OS X, there are tw

Re: [Cython] Cython 0.23.5 released

On 2016-03-26 13:47, Stefan Behnel wrote: I just pushed a pure bug-fix-only release for the current 0.23 series. Any major changes have been held back for the upcoming 0.24 feature release, so the update is recommended for those who can't wait. Any idea on the ETA for Cython 0.24? _

Re: [Cython] Cython alpha 0.24

On 2016-03-13 14:03, Robert Bradshaw wrote: If we accept cross-project includes I missed the memo that cross-project includes are not "accepted". They do work, just add include_path=sys.path to the cythonize() call. All I'm doing with my patch is to remove the need to explicitly add that in

Re: [Cython] Function calls and ref counts

I cannot reproduce the problem... It might be relevant to mention things like OS and Python version. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython alpha 0.24

On 2016-03-11 10:00, Robert Bradshaw wrote: I'd really rather deprecate .pxi files completely rather than add even more support for them. Well, .pxi files are currently *not* deprecated. The fact that they might be deprecated in the future seems a poor excuse to reject a 1-line patch fixing a

Re: [Cython] Cython alpha 0.24

I get one testsuite failure: $ python runtests.py -v -v fused_cpp Python 2.7.10 (default, Mar 11 2016, 09:57:44) [GCC 4.8.4] Running tests against Cython 0.24a0 Backends: c,cpp runTest (__main__.CythonRunTestCase) compiling (cpp) and running fused_cpp ... === Expected errors: === === Got erro

Re: [Cython] Support for .pxi files

On 2016-03-11 10:34, Robert Bradshaw wrote: On a more pragmatic note, includes add complexities to dependency tracking Because you *intentionally* make things complicated. The refused pull request 392 could actually make dependency checking simpler by treating .pxd and .pxi files more alike.

Re: [Cython] Cython alpha 0.24

On 2016-03-11 10:00, Robert Bradshaw wrote: but it seems it could be done with a cimport alone. I already discussed that with Stefan Behnel... no, it cannot be done with a cimport alone. ___ cython-devel mailing list cython-devel@python.org https://

[Cython] Support for .pxi files

ll/392 was refused and it seems that https://github.com/cython/cython/pull/483 is going to be refused too. Jeroen Demeyer. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython alpha 0.24

Hello, Is there any chance of merging https://github.com/cython/cython/pull/483 It is a really trivial patch. Thanks, Jeroen. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

[Cython] Do we really need realpath()?

Hello, I am currently profiling Cython's dependency-checking code when compiling the SageMath Cython library. I am skipping the actual cythonization, so it's really just the first "for m in module_list" loop in cythonize(). I noticed that about 10% of total time is spent in os.path.realpath(

Re: [Cython] can we deprecate for-from loops?

On 2015-10-12 04:57, Kevin Norris wrote: IMHO, either it should be un-deprecated in the documentation[1], or the compiler should start issuing warnings and eventually errors. You can't have it both ways. Either it's deprecated or it isn't. +1 ___ c

Re: [Cython] can we deprecate for-from loops?

On 2015-10-11 16:30, Stefan Behnel wrote: Hi! The syntax construct "for i from 0 <= i < 10" has been silently outdated for years. Can we start issuing a warning that normal range() loops are preferred? Is there anything wrong with the for ... from ... syntax? In more complicated situations I

[Cython] __dealloc__ called even if __cinit__ failed

Hello, I'm not entirely sure if this is a feature or bug... I noticed that, if a __cinit__ call raises an exception on an object, that __dealloc__ on that same object is still called. The problem is that __cinit__ is supposed to set up the C-level attributes for that object. If this somehow

Re: [Cython] All DEF constants are now unsigned?

Thanks, I just tested Sage with latest master and all worked fine! ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] All DEF constants are now unsigned?

On 2015-09-05 17:09, Stefan Behnel wrote: It now appends the 'U' suffix only to literals that are used in an unsigned context (e.g. assignment to unsigned variable), and additionally appends L/LL suffixes for integers that might exceed the int/long limits. Why not just keep it simple, append no

Re: [Cython] All DEF constants are now unsigned?

This is a bug: DEF myconst = 1 def foo(): cdef long x = -myconst return x This returns 4294967295. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel

[Cython] All DEF constants are now unsigned?

Hello Cython-devel, I noticed that now unsigned constants like DEF foo = 1 become 1U in the C source code. This change (i.e. commit ea6414cd293ba2134c3df5b37b158d8e3db79083) broke Sage. I haven't managed yet to actually isolate why this change broke something. Was this change of 1 to 1U in

  1   2   >