Re: [Cython] [Bug] Unable to cast to python type.
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 two
nodes.
* ParseTreeTransform of 'cast()' will instead instantiate a typecast
node directly from a type (parsed as 'sizeof(...)'). So there will be no
self.base_type in this part of TypecastNode.analyse_types:
if to_py and not from_py:
elif self.operand.type.can_coerce_to_pyobject(env):
self.result_ctype = py_object_type
base_type = self.base_type.analyse(env)
self.operand = self.operand.coerce_to(base_type, env)
The question: Why isn't the last line simply "self.operand =
self.operand.coerce_to(self.type, env)"? That is, what's the point of
coercing to the base type here instead of coercing to the type itself? A
fortiori, notice this is inside the to_py case, I'm not even sure that
base_type makes sense here. For example:
- Pointer base type cannot be a Python object (for ).
- Const base type cannot be a Python object (for ).
- Cannot cast to a function type (for ).
(the compiler dixit)
Cheers
--
Carlos
On Fri, Oct 16, 2015 at 4:05 PM, Carlos Pita
wrote:
> Hi,
>
> import cython as cy
> y = cy.cast('list', x)
>
> fails to compile with "AttributeError: 'TypecastNode' object has no
> attribute 'typecheck'".
>
> But the following examples do compile:
>
> y = x
>
> y = cy.cast('int', x)
>
> Cheers
> --
> Carlos
>
>
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
[Cython] [Refactor] Emulated types
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 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [Refactor] Emulated types
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 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 > ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [Refactor] Emulated types
> 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/mailman/listinfo/cython-devel
Re: [Cython] [Refactor] Emulated types
> > 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 PointerType does instead. I hadn't noticed the [] boxing cython.address does when creating the pointer. So I guess the list case in the PointerType constructor is there just to support this boxed parameter, not lists per se. Nevertheless my main concerns still stand: (i) the boxing won't make cython.address(x) equivalent to &x when x is, say, an int (you get a "pointer to the box", not a "pointer to the int"); (ii) I don't know how to create an instance of ArrayType in a way the compiler likes (and I don't understand the point of doing that, even if it were possible) and (iii) in any case that array will be copied when the PointerType constructor type casts it, so I won't really get a pointer to an array but a new array instead. Sorry for the autoanswering, I'm a bit overwhelmed with my first intimate contact with cython. Any clarifications will be *very much* appreciated. Regards -- Carlos ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
