[Cython] CF based type inference
stefan_ml at behnel.de
Wed May 9 08:22:07 CEST 2012
Robert Bradshaw, 09.05.2012 00:12:
> On Tue, May 8, 2012 at 6:47 AM, Vitja Makarov wrote:
>> 2012/5/8 Stefan Behnel:
>>> Vitja has rebased the type inference on the control flow, so I wonder if
>>> this will enable us to properly infer this:
>>> def partial_validity():
>>> >>> partial_validity()
>>> ('Python object', 'double', 'str object')
>>> a = 1.0
>>> b = a + 2 # definitely double
>>> a = 'test'
>>> c = a + 'toast' # definitely str
>>> return typeof(a), typeof(b), typeof(c)
>>> I think, what is mainly needed for this is that a NameNode with an
>>> undeclared type should not report its own entry as dependency but that of
>>> its own cf_assignments. Would this work?
>>> (Haven't got the time to try it out right now, so I'm dumping it here.)
>> Yeah, that might work. The other way to go is to split entries:
>> def partial_validity():
>> >>> partial_validity()
>> ('str object', 'double', 'str object')
>> a_1 = 1.0
>> b = a_1 + 2 # definitely double
>> a_2 = 'test'
>> c = a_2 + 'toast' # definitely str
>> return typeof(a_2), typeof(b), typeof(c)
>> And this should work better because it allows to infer a_1 as a double
>> and a_2 as a string.
> This already works, right?
It would work if it was implemented. *wink*
> I agree it's nicer in general to split
> things up, but not being able to optimize a loop variable because it
> was used earlier or later in a different context is a disadvantage of
> the current system.
Absolutely. I was considering entry splitting more of a "soon, maybe not
now" type of thing because it isn't entire clear to me what needs to be
done. It may not even be all that hard to implement, but I think it's more
than just a local change in the scope implementation because the current
lookup_here() doesn't know what node is asking.
More information about the cython-devel