Hi Stefan,
Cython is a programming language, so you can stick anything you like into
the wrapper. Note that a lot of code is not being (re-)written specifically
for a platform (CPython/PyPy/...), or at least shouldn't be, so when
writing a wrapper as a library, you may want to put some (and some
Stefan Behnel, 14.04.2012 09:36:
> wlavrij...@lbl.gov, 13.04.2012 22:19:
>> Same goes for C++ overloads (with a little care): each overload that fails
>> should result in a (python) exception during mapping of the arguments. The
>> JIT then removes those branches from the trace, leaving only the ca
wlavrij...@lbl.gov, 13.04.2012 22:19:
>> It's not necessarily slow because a) the intermediate function can do more
>> than just passing through data (especially in the case of Cython or Numba)
>> and b) the exception case is usually just that, an exceptional case.
>
> interesting: under a), what
Hi Stefan,
It's not necessarily slow because a) the intermediate function can do more
than just passing through data (especially in the case of Cython or Numba)
and b) the exception case is usually just that, an exceptional case.
interesting: under a), what other useful work can be done by the
wlavrij...@lbl.gov, 13.04.2012 21:15:
>> At least for Cython code that's not a problem - its functions raise Python
>> exceptions. Some C++ exceptions are mapped automatically and others can be
>> mapped explicitly.
>>
>> Other wrapper generators could also generate an intermediate wrapper
>> funct
Hi Stefan,
At least for Cython code that's not a problem - its functions raise Python
exceptions. Some C++ exceptions are mapped automatically and others can be
mapped explicitly.
Other wrapper generators could also generate an intermediate wrapper
function that does the error mapping and passe
Alex Gaynor, 13.04.2012 20:25:
> On Fri, Apr 13, 2012 at 2:18 PM, Stefan Behnel wrote:
>> wlavrij...@lbl.gov, 13.04.2012 19:03:
>>> Integrating unpacked functions pointers with PyPy works rather elegantly
>>> through the functionality made available in rlib/libffi.py. The form of
>>> the specificat
On Fri, Apr 13, 2012 at 2:18 PM, Stefan Behnel wrote:
> wlavrij...@lbl.gov, 13.04.2012 19:03:
> >> Note that a wrapper function may offer more than one native signature,
> e.g.
> >> when wrapping overloaded C++ functions or when using Cython fused
> functions.
> >
> > the big problem I'm finding
wlavrij...@lbl.gov, 13.04.2012 19:03:
>> Note that a wrapper function may offer more than one native signature, e.g.
>> when wrapping overloaded C++ functions or when using Cython fused functions.
>
> the big problem I'm finding for unpacking C++ functions (other than that
> there's no platform-in
Hi Stefan,
Note that a wrapper function may offer more than one native signature, e.g.
when wrapping overloaded C++ functions or when using Cython fused functions.
the big problem I'm finding for unpacking C++ functions (other than that
there's no platform-independent way to do so when it come
Hi,
I already mentioned this possibility a couple of times on this list, but
now the idea has attracted some more general interest.
The Cython project would like to specify a general way of unpacking wrapped
native functions for Python implementations. This is interesting for
CPython because it w
11 matches
Mail list logo
