Re: [Cython] [ENH] Compile-time code execution (macros / templates)

On 26/02/21 3:21 pm, Celelibi wrote: def twice(f): fun = CdefFunction(... use f ...) return fun foo = CdefFunction(...) ast.append(AstCdefFunction("foo", twice(foo))) I think this might even be doable without having to even detect the closure in cython. We'd just have to let python pe

Re: [Cython] [ENH] Compile-time code execution (macros / templates)

On 26/02/21 9:29 am, Celelibi wrote: Maybe in the future if cython support compiling closures to C? Your "twice" example already needs some closure functionality. It relies on being able to manufacture a cdef function inside a Python function, with the expectation that it will have access to ar

Re: [Cython] Most efficient way to create an object with Python C-API

On 17/06/20 8:32 am, Daniele Nicolodi wrote: PyObject* decimal = PyImport_ImportModule("decimal"); PyObject* constructor = PyObject_GetAttrString(m, "Decimal"); PyObject* obj = PyObject_CallFunction(PyDec_Type, "s#", str, len); Is there a better way? I was thinking about getting to the PyTypeOb

Re: [Cython] Status

On 1/02/20 3:29 pm, John Skaller2 wrote: But the all hell breaks loose for pointers. Your hack only works for rvalues. Yes, using these it's possible for Cython to accept something that will later be rejected by the C compiler. It's not perfect, but it gets the job done most of the time. -- Gr

Re: [Cython] Size of output

On 1/02/20 3:17 am, John Skaller2 wrote: When I ran Cython on a two line Python function I got this from wc: 4276 13798 161338 oldtest.c That seems a bit excessive. A lot of the emitted code appeared to be run time and compile time support code which wasn’t actually used. Not sure

Re: [Cython] Status

On 1/02/20 3:08 am, John Skaller2 wrote: I don’t think that is true in C99 but I’m not sure. You may be right, I haven't been keeping up with all the twists and turns of recent C standards. The gcc I just tried it on allowed it, but warned about it. In any case its a bad idea in an interface

Re: [Cython] Status

On 1/02/20 3:03 am, John Skaller2 wrote: So this is some kind of hack way of getting something a bit like Haskell type classes, you’re basically saying int32_t and int64_t are of class “Integer”. I suppose you could think of it that way, but it's really not that formal. This also explains t

Re: [Cython] Status

On 1/02/20 12:34 am, John Skaller2 wrote: Ok, but now the syntax is made very context sensitive. To interpret it correctly, you have to know “ob” is not a type. Yes, Cython mostly follows C declaration syntax, and C also has this property. In C this would not work because there is no default

Re: [Cython] Status

On 1/02/20 12:25 am, John Skaller2 wrote: cdef extern from "Python.h": ctypedef int int32_t ctypedef int int64_t ctypedef unsigned int uint32_t ctypedef unsigned int uint64_t These work because Cython doesn't need to know the exact sizes of these types. All it needs to know

Re: [Cython] Status

On 31/01/20 9:47 am, John Skaller2 wrote: 2. pyport is plain wrong. It contains conflicting C typedefs. PRs welcome. Is this your prefered method (pull request)? I'm sure PRs are very welcome, but at the least you could give us some idea of what these conflicting typedefs are! ob

Re: [Cython] Status

On 31/01/20 10:00 am, John Skaller2 wrote: It works. Why Python would look for a linux extension only on MacOS I have no idea. It's not really a Linux extension. It goes back to when shared libraries first appeared in BSD, from which large parts of MacOSX are derived, and MacOSX also recognise

Re: [Cython] Status

On 30/01/20 8:58 pm, John Skaller2 wrote: import oldtest > Traceback (most recent call last): >File "", line 1, in > ModuleNotFoundError: No module named 'oldtest' What happens if you use a .so extension instead of .dylib? -- Greg ___ cython-

Re: [Cython] Hello

On 29/01/20 8:37 am, John Skaller2 wrote: If I implement that with just static casts for coercions, then say, given a dictionary and a function accepting a mapping argument, you can pass a dictionary or mapping, but not an object. If you want to pass an object you have to explicitly coerce it.

Re: [Cython] Hello

On 29/01/20 1:33 am, John Skaller2 wrote: # This conflicts with the C++ bool type, and unfortunately # C++ is too liberal about PyObject* <-> bool conversions, # resulting in unintuitive runtime behavior and segfaults. #("bool","PyBool_Type", []), Now you have me worried! Any more

Re: [Cython] Hello

On 27/01/20 6:56 pm, John Skaller2 wrote: Felix binds C/C++ code with statements like: type PyObject = “PyObject*”; fun add: PyObject * PyObject -> PyObject = “Py_AddLong($1)”; and can use the bindings like: var a : PyObject = …. var b: PyObject = ...

Re: [Cython] Hooking tp_clear()

Jeroen Demeyer wrote: I have a concrete use case where I want something like __dealloc__ but > *before* Python attributes are cleared. So this really belongs in tp_clear(). Are you sure you can't do it in __del__? From what I gather, the presence of __del__ no longer prevents cyclic garbage c

Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter

Robert Bradshaw wrote: Name mangling is done for the standard reasons--to avoid possible conflicts with all other symbols that may be defined. The main reason for mangling names is that top-level declarations in Cython belong to a module namespace, whereas C just has a single namespace for all

Re: [Cython] Virtual cpdef methods

Robert Bradshaw wrote: All methods (cdef, cpdef, and def) are virtual by default in Cython, just like Python. On Mon, Jun 20, 2016 at 6:08 AM, Jeroen Demeyer wrote: I would like to have a "virtual" cpdef method: something which allows a fast Cython call *when implemented* but without a defaul

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

Erik Bray wrote: A developer who writes some code that happens to use long double isn't going to think themselves "Gosh, I guess I can't accept `long double` here because it may cause Cython to generate code that contains "truncl" Sounds to me like Cython shouldn't be taking it upon itself to g

Re: [Cython] import-free setuptools integration

Nils Werner wrote: - Having `cythonize()` internally automatically compile *.pyx files when *.c files are provided is disabled by default and must be enabled using the `replace_extension` keyword argument (`cython_modules` enables that option). I'd be happier if it were still disabled

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

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? I'd be in favour of replacing it with just 'for 0 <= i < 10', but -1 on removing it altogether. I introduced it

Re: [Cython] __dealloc__ called even if __cinit__ failed

Jeroen Demeyer wrote: The problem is that __cinit__ is supposed to set up the C-level attributes for that object. If this somehow fails, then the object isn't in a consistent state yet, so it makes no sense to call __dealloc__ on it. Do you consider this a Cython bug or should I manually prote

Re: [Cython] operator() bug in cython

Ulrich Dobramysl wrote: Thanks! I haven't figured out how to call heap allocated objects, as the code --- cdef OperatorTest *t = new OperatorTest() t() --- is not translatable by Cython. Have you tried: t[0]() ? A quick and dirty fix for this would be this patch for NameNode.calculate_

Re: [Cython] Compilation failes if a class member is named "INFINITY"

Stefan Behnel wrote: Python extension types are just structs at the C level, and struct member names cannot be mangled. Well, in principle it *could* mangle the names in structs that aren't declared "cdef extern". I didn't do that in Pyrex because it didn't seem necessary; I hadn't anticipated

Re: [Cython] IPython with Cython support on Android

Apps Embedded wrote: > 2015-02-01 9:25 GMT+01:00 Stefan Behnel >: > > (I don't understand why it requests the right to track where I am, > though, > so I didn't try it out.) > The Free app has an advertising banner based on the Mobfox library. When integr

Re: [Cython] Possible bug (or wrong documentation) WRT "not None"

Samuele Kaplun wrote: The self parameter of a method of an extension type is guaranteed never to be None. (Note: arithmetic methods might be an exception to this rule. The arithmetic methods don't *have* a "self" parameter (or at least it's not always the first parameter), so technically what

Re: [Cython] New function (pointer) syntax.

Robert Bradshaw wrote: If you want a hint, the last is something that returns numerical integration algorithm given a string name. Yes, you could use typedefs, but you shouldn't have to. I don't find *any* of those particularly easy to read in the third case, or even the second. Using typedefs

Re: [Cython] Wrong order of __Pyx_DECREF when calling a function with an implicit str → char* conversion.

Stefan Behnel wrote: Stefan Behnel, 30.05.2014 15:01: Emmanuel Gil Peyrot, 28.05.2014 13:25: I was testing my cython codebase on top of pypy/cpyext, and I found a memory corruption. After investigating it with the pypy guys (thanks arigato!), we identified it as a cython bug: cdef void test

Re: [Cython] Declaration syntax change

Robert Bradshaw wrote: cdef int *a, b, c, *d[3] is IMHO quite ugly but also adds a lot of complexity to the parser. What if instead we required cdef int* a cdef int b, c cdef int[3]* d What would be the benefit of this? You're proposing to change from something identical to C

Re: [Cython] How should be C-clobal deletion handled?

Vitja Makarov wrote: Recently I've found that the following code causes segmentation fault: cdef object f del f print f FWIW, Pyrex disallows using del on cdef names. -- Greg ___ cython-devel mailing list cython-devel@python.org http://mail.python.o

Re: [Cython] nogil doesn't seem to work when defined on extern cpp functions

Ryan Pessa wrote: It doesn't seem like Cython respects the `nogil` statement on extern cpp functions. The nogil declaration doesn't work that way. Declaring a function as nogil just says that it's safe to call it without the GIL -- it doesn't actually cause the GIL to be released. You need a 'w

Re: [Cython] Surprising behaviour wrt. generated tp_clear and tp_dealloc functions

Stefan Behnel wrote: Torsten Landschoff, 22.04.2013 13:07: One could even think about building a graph of possible object relationships ... Slot refers only to Slots and Slots only to Context, so these can't build a cycle. Interesting. Yes, that might work. Only if subclassing of Slot and

Re: [Cython] Cython syntax to pre-allocate lists for performance

Nikita Nemkin wrote: Sorry, accidental early send. Previous mail continued... [None] * N makes an extra pass over the list to assign None to each item (and also incref None n times). Maybe this could be optimised by adding N to the reference count instead of incrementing it N times? -- Greg _

Re: [Cython] [cython-users] Recommendations for efficient typed arrays in Cython?

Sturla Molden wrote: I was replying to a Cython user who thought anything declared 'cdef' was reference counted That's a matter of user education. We can't use syntax to address every possible misconception a user might have. "cdef" refers to storage in the generated C, not to the semantics of

Re: [Cython] [cython-users] Recommendations for efficient typed arrays in Cython?

Sturla Molden wrote: The way I see it, "object" is a Python type and "PyObject*" is a C type. That is, PyObject* is just a raw C pointer with respect to behavior. Well... while it's possible to declare something as PyObject* in Cython and get raw pointer behaviour, it's something you should onl

Re: [Cython] [cython-users] Recommendations for efficient typed arrays in Cython?

On 01/02/13 09:31, Sturla Molden wrote: cdef object a cdef list b cdef foobar c etc to define Python variables. 'cdef' seems to indicate that it is a C declaration, yet here it is not. Yes, it is. In this context, the cdef isn't about the type of the variable, it's about where and how it's sto

Re: [Cython] import relative cimport

Christoph Groth wrote: kwant/_system.pyx:8:0: 'graph.defs.pxd' not found That part *is* related to Pyrex -- it's a holdover from the old method of dealing with .pyx files in packages. It doesn't have anything to do with relative imports, though. -- Greg ___

Re: [Cython] import relative cimport

Christoph Groth wrote: in Cython/Compiler/Parsing.py I find code that emits "Relative cimport is not supported yet". Is this related to the behavior of Pyrex? There's no such code in Pyrex's Parsing.py, and if I try to compile this with Pyrex: from .bar.stuff cimport thing I get /U

Re: [Cython] Bug, or changed array assignment in 0.17beta1?

mark florisson wrote: I'm wondering, what was the original motivation to reuse temporaries? It goes back to Pyrex, where I didn't really give it much thought -- it just seemed like the tidiest thing to do. Once you have the logic to release temp references as soon as it's safe to do so, it's n

Re: [Cython] Fwd: Re: [cython-users] checking for "None" in nogil function

Stefan Behnel wrote: The main reason we didn't change this behaviour back then was that it would clearly break user code and we thought we could do without that. That's different from considering it "right" and "good". I changed the None-checking behaviour in Pyrex because I *wanted* to break

Re: [Cython] Julialang

Dag Sverre Seljebotn wrote: Well, there's still the namespace of the argument type. I think it is really a syntactic rewrite of obj->foo(bar) to foo(obj, bar) This is where I disagree. It's *not* just a syntactic rewrite, it's a lot more than that. With a Python method, I have a fairly go

Re: [Cython] Julialang

Dag Sverre Seljebotn wrote: I'm excited about Julia because it's basically what I'd *like* to program in. My current mode of development for much stuff is Jinja2 or Tempita used for generating C code; Julia would be a real step forward. It looks interesting, but I have a few reservations abou

Re: [Cython] CEP1000: Native dispatch through callables

Dag Sverre Seljebotn wrote: if you use Python bytes in a dict in sys.modules['_nativecall'], the bytes objects could be deallocated before callables containing the interned string -- unless you Py_INCREF once too many, I don't understand that. Is there some reason that refcounting of the inte

Re: [Cython] CEP1000: Native dispatch through callables

Robert Bradshaw wrote: Brevity, especially if the signature is inlined. (Encoding could take care of this by, e.g. ignoring the redundant opening, or we could just write di=d.) Yes, I was thinking in terms of replacing the paren with some other character, rather than inserting more parens. --

Re: [Cython] CEP1000: Native dispatch through callables

Stefan Behnel wrote: It wasn't really a proposed syntax, I guess, more of a way to write down an example. That's okay, although you might want to mention in the PEP that the actual syntax is yet to be determined. Being a PEP, anything it says tends to come across as being a specification other

Re: [Cython] CEP1000: Native dispatch through callables

Dag Sverre Seljebotn wrote: if (obj has signature "id)i") { This is an aside, but is it really necessary to define the signature syntax in a way that involves unmatched parens? Some editors (such as the one I like to use) get confused by this, even when they're inside quotes. The answer "get

Re: [Cython] CEP1000: Native dispatch through callables

Robert Bradshaw wrote: Has anyone done any experiments/timings to see if having constants vs. globals even matters? My gut feeling is that one extra memory read is going to be insignificant compared to the time taken by the call itself and whatever it does. But of course gut feelings are alway

Re: [Cython] CEP1000: Native dispatch through callables

Dag Sverre Seljebotn wrote: 1) It doesn't work well with multiple interpreter states. Ok, nothing works with that at the moment, but it is on the roadmap for Python Is it really? I got the impression that it's not considered feasible, since it would require massive changes to the entire implem

Re: [Cython] Correct way of defining enums

Stéfan van der Walt wrote: Hi Licandro On Tue, Nov 29, 2011 at 10:32 AM, Lisandro Dalcin wrote: Try "ctypedef enum ..." Unfortunately, that doesn't work either :/ Did you try both together? I.e. cdef extern from "ndarraytypes.h": ctypedef enum NPY_SEARCHSIDE: NPY_SEARCHLEFT =

Re: [Cython] Acquisition counted cdef classes

Dag Sverre Seljebotn wrote: I'd gladly take a factor two (or even four) slowdown of CPython code any day to get rid of the GIL :-). The thing is, sometimes one has 48 cores and consider a 10x speedup better than nothing... Another thing to consider is that locking around refcount changes may

Re: [Cython] Acquisition counted cdef classes

mark florisson wrote: These will by default not lock for operations to allow e.g. one thread to iterate over the list and another thread to index it without lock contention and other general overhead. I don't think that's safe. You can't say "I'm not modifying this, so I don't need to lock it"

Re: [Cython] [cython-users] Re: callback function pointer problem

Robert Bradshaw wrote: On this note, eventually I would like coerce structs (and unions, enums) to auto-generated wrapper classes, visible in the Python module namespace if one declares them as "cpdef struct ..." Would these wrapper classes contain a copy of the struct, or would they reference

Re: [Cython] Willing to contribute

Dag Sverre Seljebotn wrote: - One idea is coercion of C pointers to ctypes Python objects and back again. Some way of requesting this manually might be useful, but I don't think I'd like it to happen automatically. Slinging raw pointers around in Python isn't something to be done lightly -- e

Re: [Cython] How to define C-consts in python module scope

Chris Colbert wrote: cdef public enum: EV_READ = 1 EV_WRITE = 2 However, I do not like it, because I would like to use "public" for other meaning (API generation). My suggestion is cdef exposed enum: ... -- Greg __

Re: [Cython] Header file bug

Seth Shannin wrote: I would still make the case that currently something is a bit off in that the header file tries to use something which it has no information about Yes, I agree that it could do with improvement. I'm not sure that automatically putting the struct declaration in the header is

Re: [Cython] Header file bug

On Sat, Jun 4, 2011 at 10:36 AM, Seth Shannin wrote: test.h:11: warning: 'struct __pyx_obj_4test_foo' declared inside parameter list test.h:11: warning: its scope is only this definition or declaration, which is probably not what you want Not sure about Cython, but the way to to this in Pyrex

Re: [Cython] Fused Types

Dag Sverre Seljebotn wrote: The argument to the above goes that you *should* be out of luck. For instance, talking about dot products, BLAS itself has float-float and double-double, but not float-double AFAIK. Seems to me that's more because generating lots of versions of a function in C is h

Re: [Cython] Fused Types

Dag Sverre Seljebotn wrote: ctypedef fused_type(float, double) speed_t ctypedef fused_type(float, double) acceleration_t then you get 4 specializations. ctypedef speed_t acceleration_t I guess only 2 specializations. Treating the typedefs in this way is slightly fishy of course. Indeed. Th

Re: [Cython] Fused Types

mark florisson wrote: cdef func(floating x, floating y): ... you get a "float, float" version, and a "double, double" version, but not "float, double" or "double, float". It's hard to draw conclusions from this example because it's degenerate. You don't really need multiple versions of a

Re: [Cython] Fused Types

I'm a bit confused about how fused types combine to create further fused types. If you have something like ctypedef struct Vector: floating x floating y floating z then is it going to generate code for all possible combinations of types for x, y and z? That's probably not what the

Re: [Cython] Fused Types

Stefan Behnel wrote: Meaning, we'd find a new type during type analysis or inference, split off a new version of the function and then analyse it. I'm not sure that this degree of smartness would really be a good idea. I'd worry that if I made a type error somewhere, the compiler would go off

[Cython] What *is* a fused type?

I seem to have missed the beginning of the discussion about this fused type business. Is there a document somewhere describing what a "fused type" is and what it's meant to be used for? -- Greg ___ cython-devel mailing list cython-devel@python.org http:

Re: [Cython] GSoC Proposal - Reimplement C modules in CPython's standard library in Cython.

Arthur de Souza Ribeiro wrote: def _make_iterencode(dict markers, _default, _encoder, _indent, _floatstr, _key_separator, _item_separator, bint _sort_keys, bint _skipkeys, bint _one_shot, ## HACK: hand-optimized bytecode; turn globals into locals ValueError=ValueError,

Re: [Cython] CEP: prange for parallel loops

Nathaniel Smith wrote: Surely it should be 'pfor i in range(...)'. Or 'pfhor', just to let you know it's really something out of this world. http://marathongame.wikia.com/wiki/Pfhor_%28Race%29 -- Greg ___ cython-devel mailing list cython-devel@pytho

Re: [Cython] Rewriting/compiling parts of CPython's stdlib in Cython

Sturla Molden wrote: Why stop with the standard library? Why not implement the whole CPython interpreter in Cython? That would be tricky, because the code that Cython generates depends on large chunks of CPython as an infrastructure. -- Greg ___ cy

Re: [Cython] 'with gil:' statement

mark florisson wrote: I think we could support it without having to acquire the GIL in the finally clause. That was the intention -- the code in the finally clause would be subject to the same nogil restrictions as the rest of the nogil block. My point is that as long as you're allowing except

Re: [Cython] 'with gil:' statement

Dag Sverre Seljebotn wrote: def f(): with nogil: for ...: A if something_exceptional: with gil: raise Exception(...) B C If that's to be supported, the following really ought to be supported as well:

Re: [Cython] 'with gil:' statement

Stefan Behnel wrote: I'm not sure if this is a good idea. "nogil" blocks don't have a way to handle exceptions, so simply jumping out of them because an inner 'with gil' block raised an exception can have unexpected side effects. Seems to me that the __Pyx_WriteUnraisable should be done at th

Re: [Cython] Out of order side effects of argument evaluation in function calls (ticket #654)

Stefan Behnel wrote: That means that the average innocent future maintainer could break the code by manually rearranging the expression in a way that's perfectly valid mathematically, Another thing is that when the subexpressions concerned are function arguments, it only works if the order of

Re: [Cython] 'with gil:' statement

On 03/16/2011 01:55 PM, mark florisson wrote: but it doesn't catch this: cdef void func() nogil: with nogil: pass with nogil: func() I would say that in that case, func() should acquire the gil on entry so that it can be released in the 'with nogil' block. Either that or

Re: [Cython] 'with gil:' statement

mark florisson wrote: I just think it is important for users to realize that in general, they cannot unblock threads recursively. I don't think that nested 'with nogil' blocks in any way suggest that they can. Saying 'with nogil' means "I want this code executed with the gil released". If it's

Re: [Cython] OpenMP support

mark florisson wrote: Have we ever thought about supporting 'with gil' as an actual statement instead of just as part of a function declaration or definition? That's the way I was originally going to do it in Pyrex, but it turned out to be problematic, because there is some setup that gets don

Re: [Cython] Out of order side effects of argument evaluation in function calls (ticket #654)

Stefan Behnel wrote: To be a little clearer here, it's a problem in C for example with struct values. Copying them by value into a temp variable can be expensive, potentially twice as expensive as simply passing them into the function normally. What are you actually proposing to do here? Any

Re: [Cython] Out of order side effects of argument evaluation in function calls (ticket #654)

Stefan Behnel wrote: This introduces problems when the arguments have side effects or are not simple, e.g. f(g(a), a.x, h(a)) > What do you think about this? I think it's a bad idea to write code that relies on the order of evaluation like this. If the order matters, it's better to be

Re: [Cython] OpenMP support

Stefan Behnel wrote: You *can* use Python references inside of nogil blocks, even if there's a lot of stuff that you can't do with them, ... But you can access cdef > attributes on them, Strictly speaking it's not even safe to do that, unless you know there's some locking mechanism in effect

Re: [Cython] Multiple modules in one compilation unit

Lisandro Dalcin wrote: However, in Python 3 that is not te case (and only for the .so, for .py is the same as in Py2), the import machinery adds the entry later, after the finalization of the module init function. Might be an idea to raise this issue on python-dev, to see if there is a reason f

Re: [Cython] Multiple modules in one compilation unit

Stefan Behnel wrote: you'd call "cython" on a package and it would output a directory with a single __init__.so that contains the modules compiled from all .pyx/.py files in that package. Importing the package would then trigger an import of that __init__.so, which in turn will execute code in

Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants

Stefan Behnel wrote: The same argument could be brought up against "cdef" vs. "def" (between which the semantic difference is *huge*) There are a couple of differences: - 'cdef' and 'def' look very different (at least to me) because they *start* with a different letter. Whereas 'cdef' and 'c

Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants

Stefan Behnel wrote: With "preferred way", I was suggesting that we could *deprecate* cdef public int x cdef readonly object y for cdef class properties in favour of cpdef int x cpdef readonly object y I think I've just realised one of the reasons for my gut dislike of the "

Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants

Stefan Behnel wrote: Given that Cython has "cpdef" already, why not just use that? That seems like a reasonable idea. -- Greg ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants

W. Trevor King wrote: On Sat, Feb 19, 2011 at 04:41:27PM -0800, Robert Bradshaw wrote: On Sat, Feb 19, 2011 at 3:31 PM, W. Trevor King wrote: cython $ grep class Cython/Includes/numpy.pxd ctypedef class numpy.dtype [object PyArray_Descr]: ctypedef extern class numpy.flatiter [o

Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants

Robert Bradshaw wrote: BTW, the "public" keyword is the wrong thing to use here, as that actually controls name mangling and (c-level) symbol exporting. The fact that means a different thing for members than for top-level symbols isn't ideal, but at least it's unambiguous as members need not be

Re: [Cython] Control flow graph

Vitja Makarov wrote: Here is funny picture made with graphviz ;) http://piccy.info/view3/1099337/ca29d7054d09bd0503cefa25f5f49420/1200/ Gives the term "spaghetti code" a whole new meaning! -- Greg ___ cython-devel mailing list cython-devel@python.

Re: [Cython] Bug in NULL handling introduced 0.14.1-1

Chris Colbert wrote: changing the include definition to: cdef extern from "Python.h": int PyObject_GenericSetAttr(PyObject*, PyObject*, PyObject*) except -1 This suggests another possible workaround: cdef extern from "Python.h": int PyObject_GenericDelAttr "PyObject_GenericSetAttr"

Re: [Cython] Bug in NULL handling introduced 0.14.1-1

Chris Colbert wrote: The problem with delattr (and thus PyObject_DelAttr) arises when you define a __delattr__ method on your class. There is not easy way to then call back into the "normal" python delattr semantics, except by doing object.__delattr__ (which is not optimized by Cython). Hmmm

Re: [Cython] Bug in NULL handling introduced 0.14.1-1

Chris Colbert wrote: I have cython file which is using PyObject_GenericSetAttr Now in my script I am using that function to generically delete an attribute by passing a NULL as the last value (this is proper way to trigger a generic delattr in the Python c-api) I would have thought the prope