On Tue, May 15, 2012 at 12:59 PM, mark florisson <markflorisso...@gmail.com>wrote:
> On 15 May 2012 17:34, Armin Rigo <ar...@tunes.org> wrote: > > Hi Yury, > > > > On Tue, May 15, 2012 at 5:56 PM, Yury Selivanov <yselivanov...@gmail.com> > wrote: > >> While I don't like some design quirks of Cython, I think that it's far > >> better than any ffi or ctypes-like solution. Essentially, it's an ffi > >> merged with the language, not a separate module. And that's a pretty > >> unique approach. Why not focus on improving Cython design and moving > >> toward some superset of Python language, that every implementation > >> should support natively? > > > > I'm quite sure it will never happen. See for example the new section > > "Pure Python Mode" in http://docs.cython.org/src/tutorial/pure.html: > > it is again about adding ffi-like glue to Python files. It is a > > reasonable next step in the Cython project, but it shows precisely > > that there is no chance to add all of Cython into the Python language > > definition. > > > > If I got you correctly, such ffi-like glue code is the part that you > > dislike. I agree with you, but I don't think we can hope for a > > solution with no glue at all; instead, we can try to minimize it as > > much as possible. I may be wrong, but until proven otherwise, I am > > under the impression that LuaJIT's approach leads to significantly > > less glue code than Cython's Pure Python Mode. (This is true even > > though the former is complete and the latter so far not: from the > > Cython docs, "A limited attempt is made to emulate these more complex > > types, but only so much can be done from the Python language.") > > > > > > A bientôt, > > > > Armin. > > _______________________________________________ > > pypy-dev mailing list > > pypy-dev@python.org > > http://mail.python.org/mailman/listinfo/pypy-dev > > We have been discussing a proposal to add a mechanism to perform > native calls fast given a Python object. E.g. if a JIT, or Cython > code, suspects a certain signature, it can query the object for that, > and if valid call the function natively through a pointer, allowing > also for specializations. This could work from Cython (e.g. when > calling a function with typed arguments/return value, or when casting > the function object explicitly to a typed C function pointer), but > this information can also be used by a JIT to call into native code > quickly. > > The details of the proposal are here: > http://wiki.cython.org/enhancements/cep1000 . I guess the question is, > will this project also try to expose an interface along these lines? > It would standardize an efficient mechanism to deal with wrapped > native code. The CEP was not originally designed for functions wrapped > by an FFI (more for callback wrappers of native code, such as numba or > cython functions), but it can be used to wrap any native code. > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > http://mail.python.org/mailman/listinfo/pypy-dev > FWIW my project is available here: https://github.com/alex/yaffi. It's very incomplete (only docs, which are also incomplete :P, ATM). Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
