bearophileh...@lycos.com wrote: > Kay Schluehr: >> Don't understand your Cython compliant. The only tricky part of Cython >> is the doublethink regarding Python types and C types. I attempted once >> to write a ShedSkin like code transformer from Python to Cython based on >> type recordings but never found the time for this because I have to work >> on EasyExtend on all fronts at the same time. > > I have tried to create a certain data structure with a recent version > of Pyrex on Windows, and I have wasted lot of time looking for missing > reference count updates that didn't happen, or memory that didn't get > freed.
I wonder what you did then. Apparently, you didn't just compile a Python program, but tried to use Pyrex/Cython to avoid writing C code. That can work, but depends on your C expertise. If you only compile Python code, you will not get in touch with any ref-counting or memory leaks (any more than in CPython, that is). You only have to care about freeing memory if you manually allocate that memory through malloc(), in which case it's your own fault if it doesn't get freed. > I'm sure lot of people like Cython, but I prefer a more transparent > language, that doesn't hide me how it works inside. Cython doesn't hide anything. Most of the magic that happens is done in code tree transformations, which you can look up in the compiler code. The code generation is mostly just mapping the final code tree to C code, with some type specialisations. Cython will even copy your complete source code line-by-line into the C code it writes, so that you can easily read up what your code gets translated to. I admit that the generated C code is not always simple and obvious, as it contains lots of runtime type specialisations and optimisations. But that's the price you pay for fast code. And you can make Cython leave out most of the duplicated code (i.e. the pessimistic fallbacks) by adding type hints to your code. Stefan -- http://mail.python.org/mailman/listinfo/python-list