On Tue, Mar 4, 2008 at 11:15 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Mar 4, 2008, at 1:53 PM, Dag Sverre Seljebotn wrote:
>
> >
> >> buffers, then this could be provided automatically. Overloading the =
> >> operator would work for the one direction, and perhaps something
> >> similar would be provided to do an "convert self to other type"
> >> declaration.
> > Right. This will keep me thinking :-)
> >
> > Has there been any thoughts on doing something as brute as allowing
> > Python code in pxd files that is simply called compile-time and
> > returns
> > strings of C code? Or if not there, as a kind of plugin-
> > architecture for
> > the Cython compiler engine? Like this (apologies for bad knowledge of
> > this aspect of Cython):
> >
> > (Lot's of stuff that doesn't work, just scetching wildly...)
> >
> > cdef class std_vector_int:
> > def __compile_index_assign__(lefthand, indices, righthand):
> > return "%s[%s] = %s;" % (as_c(lefthand), as_c(indices), as_c
> > (righthand))
> > def __compile_index_lookup__(lefthand, indices):
> > return "%s[%s];" % (as_c(lefthand), as_c(indices))
> > def __compile_assign__(lefthand, rightand):...
> >
> > cdef class numpy.numarray ...:
> > def __compile_index_assign__(lefthand, indices, righthand):
> > l = indices.split(":")
> > if len(l) != int(lefthand.type_params[0]): raise ValueError(...)
> > idx = " + ".join([as_c(x) + " * stride[%d]" % d for x in zip(l,
> > range(len(l))])
> > return "%s[%s] = %s;" % (as_c(lefthand), idx, as_c(righthand))
>
> No, nothing like that has been attempted (or even discussed before).
> It is an interesting idea. I see potential for lots of subtle bugs
> (e.g. refcounting errors). I think if we can reduce operators (and
> conversions) to a specified function call (pass the operator to C++)
> there will be little, if any, need for something like this. I may be
> overly optimistic for things like making sure dimensions match however.
>
>
> > With the "macro as cdef"-trick earlier in the mailing list this
> > certainly doesn't seem *too* far-fetched for me...
>
> That code is simply evil.
>
>
>
> >
> >
> >>
> >> These data types can be declared, right now, by doing.
> >>
> >> cdef extern from "numpy.h":
> >> cdeftype int uint8
> > Ah, right :-)
> >
> >
> >>>
> >>> @Compile
> >>> def myfunc(a: uint8, b: array(2, uint8), c: int = 10):
> >>> d: ptr(int) = &a
> >>> print a, b, c, d
> >>>
> >>
> >> One thing I really like about the cdef keyword is that it makes it
> >> very clear what is special Cython commands, and what is not. I also
> >> find this harder to read (and parse). (BTW, what's the @Compile
> >> supposed to mean?) However, if people want to move in this
> >> direction I
> >> wouldn't protest against it as an alternative.
> > The idea was to focus on making Cython usable for numerical
> > computation
> > -- and for that use (as opposed to making wrappers for C code) you do
> > NOT want people to feel that it is not part of Python, but rather
> > treat
> > it as a "typed Python that will run fast". The use case is simply
> > somebody that uses NumPy for everything, but comes over this one
> > operation that a) isn't in the libraries, b) can't be vectorized but
> > must be implemented as for-loops. If they can simply drop in a
> > @Compile
> > decorator and add some types and get on with their work, the pure
> > convenience of it might make Cython a regular tool for these kind of
> > things...
>
> This is a good point.
>
>
> > @Compile simply uses the standard Python function decorator syntax.
> > The
> > @Compile might be @Cython instead actually. The idea is that while
> > Python syntax allows for decorating function arguments, it doesn't say
> > anything about what they're for (documentation? something else?),
> > so you
> > would often have a function decorator that acts on them, and this
> > serves
> > to document that the function argument decorators are Cython types.
> >
> > Long term, @Compile might be used to replace the function with
> > calls to
> > compiled code in Python-land, and to extract functions to compile
> > from a
> > py-file in Cython-land, so that one can mix Cython and Python in one
> > source file. Also, it can take the options that Cython needs (ie
> > @Compile(native=True, except=1) instead of cdef ... except ).
>
> If we can come up with a good syntax for using decorators to express
> all Cython options, that could have some advantages (though I would
> still keep the old way as well). For example, one could debug the
> algorithm as a pure Python program which has a faster turnaround time
> and more tools (pylint, prun, etc) and then compile it when one is
> fairly confident that all is working well. Perhaps something could
> even be done with ctypes to actually simulate library wrapping and
> everything in python mode.
Yes, we were discussing exactly this with Travis Oliphant at Sage Days
8, it would be very cool, if a "pure python" code could be compiled.
You can use decorators, or even python comments for specifying the
types. Definitely it would be very useful, but it's quite a lot of
work to get everything right.
Ondrej
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
