[Cython] [Refactor] Emulated types

[Carlos Pita]

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 be a (type casted) *copy* of the original one, thus the
reference semantics of pointers would be lost here. This could be
workarounded if the cast was replaced by a check and then the original
(type checked) list or array was kept *referenced* from inside the pointer
object. But, nevertheless, I see no general way to preserve reference
semantics in pure python mode, since there are immutable objects in python.
What is to be done with ints, for example? (notice this is the example for
cython.address in the docs), so maybe cython.address should be banned for
good, or at least restricted. If it's just restricted I think that instead
of trying to emulate some cases (say lists/arrays) and disallow others (say
ints/floats) it could be saner to just keep pointers opaque. In terms of
the current implementation, that would imply to remove __setitem__,
__getitem__ and initialization from objects other than pointers or None/0.
I don't know... maybe this __setitem__, __getitem__, __init__(from
list/array) stuff is there just for the sake of the ArrayType subclass. But
then it would be better to push it down the hierarchy and, again, I still
don't get how to instantiate ArrayType in a way that the compiler likes, so
I feel more inclined to remove it.

Sorry if I'm missing the point.

Cheers
--
Carlos


On Sun, Oct 18, 2015 at 2:45 PM, Carlos Pita <carlosjosepita at gmail.com>
wrote:

> 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
> -tho it's messy here- but the parser is unable to get them right from
> decorators). But before that I'd like to simplify things a bit, as I've
> said, and before that I need to get a good grasp of what I'm trying to
> simplify, so I'd better hear your opinion about the following points first:
>
> 1) Shadow allows creating array types like this: cython.array(cython.int,
> 10) but the compiler will complain that cython.array is an unknown type.
>
> 2) Furthermore Shadow allows to instantiate every type: cython.int(10),
> cython.array(cython.int, 20)(), etc. The compiler rejects all these
> constructs, so I see little point in supporting this feature.
>
> I think that disallowing these features (AFAICS completely unsupported by
> the compiler) will simplify the code a lot and will allow to merge the
> "shameless copy" section in a more coherent fashion. Is there any
> compelling reason to keep them? What is/was their rationale?
>
> Cheers
> --
> Carlos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20151018/fb3e6c47/attachment.html>