On 05/03/2011 10:49 AM, mark florisson wrote:
On 3 May 2011 10:44, Dag Sverre Seljebotn<d.s.seljeb...@astro.uio.no> wrote:
On 05/03/2011 10:42 AM, mark florisson wrote:
On 3 May 2011 10:07, Dag Sverre Seljebotn<d.s.seljeb...@astro.uio.no>
wrote:
On 05/03/2011 09:59 AM, mark florisson wrote:
On 3 May 2011 00:21, Robert Bradshaw<rober...@math.washington.edu>
wrote:
On Mon, May 2, 2011 at 1:56 PM, mark florisson
<markflorisso...@gmail.com> wrote:
On 2 May 2011 18:24, Robert Bradshaw<rober...@math.washington.edu>
wrote:
On Sun, May 1, 2011 at 2:38 AM, mark florisson
<markflorisso...@gmail.com> wrote:
A remaining issue which I'm not quite certain about is the
specialization through subscripts, e.g. func[double]. How should
this
work from Python space (assuming cpdef functions)? Would we want to
pass in cython.double etc? Because it would only work for builtin
types, so what about types that aren't exposed to Python but can
still
be coerced to and from Python? Perhaps it would be better to pass in
strings instead. I also think e.g. "int *" reads better than
cython.pointer(cython.int).
That's whey we offer cython.p_int. On that note, we should support
cython.astype("int *") or something like that. Generally, I don't
like
encoding semantic information in strings.
OTHO, since it'll be a mapping of some sort, there's no reason we
can't support both. Most of the time it should dispatch (at runtime
or
compile time) based on the type of the arguments.
If we have an argument type that is composed of a fused type, would be
want the indexing to specify the composed type or the fused type? e.g.
ctypedef floating *floating_p
How should we support this? It's clear in this case, but only because
you chose good names. Another option would be to require
parameterization floating_p, with floating_p[floating] the
"as-yet-unparameterized" version. Explicit but redundant. (The same
applies to struct as classes as well as typedefs.) On the other had,
the above is very succinct and clear in context, so I'm leaning
towards it. Thoughts?
Well, it is already supported. floating is fused, so any composition
of floating is also fused.
cdef func(floating_p x):
...
Then do we want
func[double](10.0)
or
func[double_p](10.0)
to specialize func?
The latter.
I'm really leaning towards the former. What if you write
cdef func(floating_p x, floating_p *y):
...
Then specializing floating_p using double_p sounds slightly
nonsensical, as you're also specializing floating_p *.
I made myself agree with both of you in turn, but in the end I think I'm
with Robert here.
Robert's approach sounds perhaps slightly simpler if you think of it this
way:
ctypedef fused_type(float, double) floating
ctypedef floating* floating_p
is really a short-hand for
ctypedef fused_type(float*, double*) floating_p
I.e., when using a fused_type in a typedef you simply get a new
fused_type.
This sounds in a sense simpler without extra complexity getting in the
way
("which was my fused base type again...").
Dag SVerre
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Ok, if those typedefs should be disallowed then specialization through
indexing should then definitely get the types listed in the fused_type
typedef.
I'm not sure what you mean here. What is disallowed exactly?
ctypedef cython.fused_type(float, double) floating
ctypedef floating *floating_p
That is what you meant right? Because prohibiting that makes it easier
to see where a type is variable (as the entire type always is, and not
some base type of it).
No. I meant that the above is automatically transformed into
ctypedef cython.fused_type(float, double) floating
ctypedef cython.fused_type(float*, double*) floating_p
DS
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
