[Cython] [cython-users] GSoC 2012

Stefan Behnel stefan_ml at behnel.de
Mon Apr 2 14:23:22 CEST 2012


Vitja Makarov, 02.04.2012 14:14:
> 2012/4/2 Stefan Behnel:
>> Vitja Makarov, 11.03.2012 09:51:
>>> 2012/3/11 Stefan Behnel:
>>>> mark florisson, 11.03.2012 07:44:
>>>>> - better type inference, that would be enabled by default and again
>>>>> handle thing like reassignments of variables and fallbacks to the
>>>>> default object type. With entry caching Cython could build a database
>>>>> of types ((extension) classes, functions, variables) used in the
>>>>> modules and functions that are compiled (also def functions), and
>>>>> infer the types used and specialize on those. Maybe a switch should be
>>>>> added to cython to handle circular dependencies, or maybe with the
>>>>> distutils preprocessing it can run all the type inference first and
>>>>> keep track of unresolved entries, and try to fill those in after
>>>>> building the database. For bonus points the user can be allowed to
>>>>> write plugins to aid the process.
>>>>
>>>> That would be my favourite. We definitely need control flow driven type
>>>> inference, local type specialisation, variable renaming, etc. Maybe even
>>>> whole program (or at least module) analysis, like ShedSkin and PyPy do for
>>>> their restricted Python dialects. Any serious step towards that goal would
>>>> be a good outcome of a GSoC.
>>>
>>> I think we should be careful here and try to avoid making Cython code
>>> more complicated.
>>
>> I agree that WPA is probably way out of scope. However, control flow driven
>> type inference would allow us to infer the type of a variable in a given
>> block, e.g. for code like this:
>>
>>  if isinstance(x, list):
>>      ...
>>  else:
>>      ...
>>
>> or handle cases like this:
>>
>>  def test(x):
>>      x = list(x)
>>      # ... do read-only stuff with x below this point ...
>>
>> Here, we currently infer that x is an unknown object that is being assigned
>> to twice, even though it's obviously a list in all interesting parts of the
>> function.
>>
> 
> What to do if an entry is of PyObject type in some block and of some
> C-type in another?
> 
> Should it be split into two different entries?

Yes, that's what I meant with "variable renaming". I admit that I have no
idea how complex that would be, though...

Stefan


More information about the cython-devel mailing list