I've been trying to understand the problem here. The cause is easy to
explain, for the cure I would like to consult the savvy before PR'ing.
The cause:
* Parsing of '<...>' will instantiate a typecast from a basetype node and
a declarator node, then the typecast type will be inferred from these
Hi,
I'm in the process of refactoring the emulated types in Shadow, in order to
simplify a bit that part of the module. Ultimately I want to add support
for declaring typed memory views in pure python (currently it's only
possible to declare them as strings, Shadow does implement the slicing part
Maybe I'm misunderstanding the entire point, but this perplexes me:
3) cython.address will create a pointer from a list, another pointer or an
instance of ArrayType (although, as I commented before: I see no
compiler-compatible way to instantiate an ArrayType). In any case the list
or array will b
> keep pointers opaque... that would imply to remove __setitem__,
__getitem__,...
Probably I went too far there: at least ptr[0] could be kept as a
dereference operator.
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailma
>
> 3) cython.address will create a pointer from a list, another pointer or an
> instance of ArrayType (although, as I commented before: I see no
> compiler-compatible way to instantiate an ArrayType).
>
I just realized this is not an accurate description of what cython.address
does, but of what P
