[Cython] CF based type inference

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Tue May 8 18:52:24 CEST 2012



Vitja Makarov <vitja.makarov at gmail.com> wrote:

>2012/5/8 Stefan Behnel <stefan_ml at behnel.de>:
>> Hi,
>>
>> 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.


+1 (as also Mark has hinted several times). I also happen to like that typeof returns str rather than object... I don't think type inferred code has to restrict itself to what you could dousing *only* declarations.

To go out on a hyperbole: Reinventing compiler theory to make things fit better with our current tree and the Pyrex legacy isn't sustainable forever, at some point we should do things the standard way and refactor some code if necesarry.

Dag

>
>
>-- 
>vitja.
>_______________________________________________
>cython-devel mailing list
>cython-devel at python.org
>http://mail.python.org/mailman/listinfo/cython-devel

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.


More information about the cython-devel mailing list