<div dir="ltr"><div><div><div>Maybe I'm misunderstanding the entire point, but this perplexes me:<br><br></div>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.<br><br></div><div>Sorry if I'm missing the point.<br></div><div><br></div>Cheers<br>--<br></div>Carlos<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 18, 2015 at 2:45 PM, Carlos Pita <span dir="ltr"><<a href="mailto:carlosjosepita@gmail.com" target="_blank">carlosjosepita@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi,<br><br></div>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:<br><br></div>1) Shadow allows creating array types like this: <span>cython</span>.array(<span>cython</span>.int, 10) but the compiler will complain that <span>cython</span>.array is an unknown type.<br><br></div>2) Furthermore Shadow allows to instantiate every type: <span>cython</span>.int(10), <span>cython</span>.array(<span>cython</span>.int, 20)(), etc. The compiler rejects all these constructs, so I see little point in supporting this feature.<br><br></div><div>I think that disallowing these features (<span>AFAICS</span> 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?<br></div><div><br></div><div>Cheers<br>--<br></div><div>Carlos</div></div>
</blockquote></div><br></div>