Re: [Cython] Ctypes object <-> pointer conversion.
On Thu, Aug 4, 2011 at 11:58 PM, Dag Sverre Seljebotn wrote: > On 08/05/2011 01:31 AM, Robert Bradshaw wrote: >> >> This is getting a bit OT but is worth discussing, so I'm starting a new >> thread. >> >> On Thu, Aug 4, 2011 at 2:51 PM, Greg Ewing >> wrote: >>> >>> 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 -- even if all the code that dereferences it is >>> in Cython, there are problems with managing the lifetime >>> of whatever it references. >> >> You know, C has the same problem with slinging around raw pointers and >> managing their lifetimes :). Of course, with C, the user is all to >> painfully aware of the situation. >> >> I think this would be most useful for providing data from Python (even >> an interactive prompt) to a Cython module. I agree about it being >> dangerous to do implicitly, but something explicit like >> >> def entry_point(ctypes.CData x): >> cdef double* result = func(x) >> returnresult # or cytpes.CData(result, >> option=...) to control deallocation >> >> could be really nice. Maybe CData could even be parameterized. > > This doesn't let you write > > cpdef int func(int *a): ... > > though. I wasn't thinking of excluding this, but I'd was thinking cdef object o = ... int* x = o o = x might be a compile-time error, forcing the user to be a bit more explicit (especially the latter). > My motivation for this was mainly to remove an exception from the > rules, and make sure that every C level object . ? > Although, C++ classes are another gaping exception to the rules. On this note, what about SWIG-wrapped types? > Perhaps > just allowing the extension to 'cpdef' above but instead generate a stub > that always raises a TypeError for the 'def' version is a better idea? That > would allow fetching the docstring etc. from Python space, while the > function remains uncallable. Even if we get int*<->ctypes.pointer, I propose > this idea for C++ classes. That's an interesting idea. > But I can also see that it'd be really handy if you, say, have a huge API > wrapped with ctypes, and want to gradually and piecewise move over to > Cython. Or do some low-level integration between a ctypes wrapper and Cython > wrapper. > > What's ctypes.CData? It's not in my ctypes module... It's really _ctypes._CData. - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] object to struct conversion
On 5 August 2011 08:53, Robert Bradshaw wrote: > On Wed, Aug 3, 2011 at 2:09 PM, mark florisson > wrote: >> On 3 August 2011 19:36, Robert Bradshaw wrote: >>> On Wed, Aug 3, 2011 at 9:20 AM, Stefan Behnel wrote: mark florisson, 03.08.2011 16:28: > > Is there any specific reason objects cannot coerce to structs (from > e.g. dicts?). It would be convenient for memoryviews, then you could > assign dicts (or any mapping) to items in the memoryview from Python > space. You could also have structs as argument to def functions etc. > Any objection to this addition? The implementation is pretty > straightforward. Robert implemented these things a while ago. I think I recall that there were unsupported use cases, but I'm not sure what exactly is missing here. >>> >>> It just simply wasn't implemented yet. >>> >>> - Robert >>> ___ >>> cython-devel mailing list >>> cython-devel@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >>> >> >> Ok, thanks guys, it's implemented in _memview: >> https://github.com/markflorisson88/cython/commit/6a2560b5b151a788ed11671663c833b6de6daccd#L4R1 >> >> BTW, my hudson sdist keeps failing with >> >> writing manifest file 'MANIFEST' >> making hard links in Cython-0.14.1+... >> hard linking COPYING.txt -> Cython-0.14.1+ >> error: File exists > > I'm not sure. I removed that directory entirely and scheduled another > build; we'll see if that helps. Thanks! That did the trick. >> any idea what that is all about? Are these hudson scripts available for >> perusal? > > Yes, but you need to have an account. We'd be happy to set you up with > one (though I thought you already had access). > > - Robert > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > Yeah I have an account. I suppose I should read some documentation to find out where to find the scripts :) ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] object to struct conversion
Robert Bradshaw, 05.08.2011 08:53: On Wed, Aug 3, 2011 at 2:09 PM, mark florisson wrote: my hudson sdist keeps failing with writing manifest file 'MANIFEST' making hard links in Cython-0.14.1+... hard linking COPYING.txt -> Cython-0.14.1+ error: File exists I'm not sure. I removed that directory entirely and scheduled another build; we'll see if that helps. BTW, just in case: this can be done through the web interface by clicking on the "workspace" of the job and then the "clear" link that appears below that. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] object to struct conversion
On 5 August 2011 11:05, Stefan Behnel wrote: > Robert Bradshaw, 05.08.2011 08:53: >> >> On Wed, Aug 3, 2011 at 2:09 PM, mark florisson wrote: >>> >>> my hudson sdist keeps failing with >>> >>> writing manifest file 'MANIFEST' >>> making hard links in Cython-0.14.1+... >>> hard linking COPYING.txt -> Cython-0.14.1+ >>> error: File exists >> >> I'm not sure. I removed that directory entirely and scheduled another >> build; we'll see if that helps. > > BTW, just in case: this can be done through the web interface by clicking on > the "workspace" of the job and then the "clear" link that appears below > that. > > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > I see, thanks Stefan! ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Cython 0.15 released
We are excited to announce the release of Cython 0.15, which is a huge step forward in achieving full Python language coverage as well as many new features, optimizations, and bugfixes. Download: http://cython.org/ or http://pypi.python.org/pypi/Cython == Major Features == * Generators (yield) - Cython has full support for generators, generator expressions and coroutines. http://www.python.org/dev/peps/pep-0342/ * The nonlocal keyword is supported. * Re-acquiring the gil: with gil - works as expected within a nogil context. * OpenMP support: http://docs.cython.org/0.15/src/userguide/parallelism.html * Control flow analysis prunes dead code and emits warnings and errors about uninitialised variables. * Debugger command cy set to assign values of expressions to Cython variables and cy exec counterpart cy_eval(). * Exception chaining http://www.python.org/dev/peps/pep-3134/ * Relative imports http://www.python.org/dev/peps/pep-0328/ * The with statement has its own dedicated and faster C implementation. * Improved pure syntax including cython.cclass, cython.cfunc, and cython.ccall. http://docs.cython.org/0.15/src/tutorial/pure.html * Support for del. * Boundschecking directives implemented for builtin Python sequence types. * Several updates and additions to the shipped standard library pxd files https://github.com/cython/cython/tree/master/Cython/Includes * Forward declaration of types is no longer required for circular references. Note: this will be the last release to support Python 2.3; Python 2.4 will be supported for at least one more release. == General improvements and bug fixes == This release contains over a thousand commits including hundreds of bugfixes and optimizations. The bug tracker has not been as heavily used this release cycle, but is still useful http://trac.cython.org/cython_trac/query?status=closed&group=component&order=id&col=id&col=summary&col=milestone&col=status&col=type&col=priority&col=owner&col=component&milestone=0.15&desc=1 == Incompatible changes == * Uninitialized variables are no longer initialized to None and accessing them has the same semantics as standard Python. * globals() now returns a read-only dict of the Cython module's globals, rather than the globals of the first non-Cython module in the stack * Many C++ exceptions are now special cases to give closer Python counterparts. This means that except+ functions that formally raised generic RuntimeErrors may raise something else such as ArithmaticError. == Known regressions == * The inlined generator expressions (introduced in Cython 0.13) were disabled in favour of full generator expression support. This induces a performance regression for cases that were previously inlined. == Contributors == Many thanks to: Francesc Alted, Haoyu Bai, Stefan Behnel, Robert Bradshaw, Lars Buitinck, Lisandro Dalcin, John Ehresman, Mark Florisson, Christoph Gohlke, Jason Grout, Chris Lasher, Vitja Makarov, Brent Pedersen, Dag Sverre Seljebotn, Nathaniel Smith, and Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
