Stefan Behnel | 8 May 14:24 2012
Picon

[Cython] CF based type inference

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.)

Stefan
Vitja Makarov | 8 May 15:47 2012
Picon

Re: [Cython] CF based type inference

2012/5/8 Stefan Behnel <stefan_ml@...>:
> 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')
(Continue reading)

Dag Sverre Seljebotn | 8 May 18:52 2012
Picon
Picon

Re: [Cython] CF based type inference


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.)
>>
>
(Continue reading)

Stefan Behnel | 9 May 17:13 2012
Picon

Re: [Cython] CF based type inference

Dag Sverre Seljebotn, 08.05.2012 18:52:
> Vitja Makarov wrote:
>> 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.

That's how these things work, though. It's basically register allocation
and variable renaming mapped to a code translator (rather than a compiler
that emits assembly or byte code).

Stefan
(Continue reading)

mark florisson | 9 May 17:20 2012
Picon

Re: [Cython] CF based type inference

On 9 May 2012 16:13, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
> Dag Sverre Seljebotn, 08.05.2012 18:52:
>> Vitja Makarov wrote:
>>> 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.
>
> That's how these things work, though. It's basically register allocation
> and variable renaming mapped to a code translator (rather than a compiler
> that emits assembly or byte code).
>
(Continue reading)

Dag Sverre Seljebotn | 9 May 17:58 2012
Picon
Picon

Re: [Cython] CF based type inference

On 05/09/2012 05:13 PM, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 08.05.2012 18:52:
>> Vitja Makarov wrote:
>>> 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.
>
> That's how these things work, though. It's basically register allocation
> and variable renaming mapped to a code translator (rather than a compiler
> that emits assembly or byte code).

(Continue reading)

Robert Bradshaw | 9 May 00:12 2012
Picon

Re: [Cython] CF based type inference

On Tue, May 8, 2012 at 6:47 AM, 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()
(Continue reading)

Stefan Behnel | 9 May 08:22 2012
Picon

Re: [Cython] CF based type inference

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')
(Continue reading)

Vitja Makarov | 9 May 10:02 2012
Picon

Re: [Cython] CF based type inference

2012/5/9 Stefan Behnel <stefan_ml@...>:
> 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()
(Continue reading)

mark florisson | 9 May 10:28 2012
Picon

Re: [Cython] CF based type inference

On 9 May 2012 09:02, Vitja Makarov <vitja.makarov <at> gmail.com> wrote:
> 2012/5/9 Stefan Behnel <stefan_ml <at> behnel.de>:
>> 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():
>>>>   """
(Continue reading)

mark florisson | 9 May 10:44 2012
Picon

Re: [Cython] CF based type inference

On 9 May 2012 09:28, mark florisson <markflorisson88 <at> gmail.com> wrote:
> On 9 May 2012 09:02, Vitja Makarov <vitja.makarov <at> gmail.com> wrote:
>> 2012/5/9 Stefan Behnel <stefan_ml <at> behnel.de>:
>>> 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():
(Continue reading)

Robert Bradshaw | 11 May 17:48 2012
Picon

Re: [Cython] CF based type inference

On Tue, May 8, 2012 at 11:22 PM, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
> 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()
(Continue reading)

Stefan Behnel | 11 May 17:56 2012
Picon

Re: [Cython] CF based type inference

Robert Bradshaw, 11.05.2012 17:48:
> On Tue, May 8, 2012 at 11:22 PM, Stefan Behnel <stefan_ml@...> wrote:
>> 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():
>>>>   """
(Continue reading)

Robert Bradshaw | 11 May 17:58 2012
Picon

Re: [Cython] CF based type inference

On Fri, May 11, 2012 at 8:56 AM, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
> Robert Bradshaw, 11.05.2012 17:48:
>> On Tue, May 8, 2012 at 11:22 PM, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
>>> 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():
(Continue reading)

Stefan Behnel | 10 May 08:45 2012
Picon

Re: [Cython] CF based type inference

Vitja Makarov, 08.05.2012 15:47:
> 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
(Continue reading)

Vitja Makarov | 10 May 09:27 2012
Picon

Re: [Cython] CF based type inference

2012/5/10 Stefan Behnel <stefan_ml@...>:
> Vitja Makarov, 08.05.2012 15:47:
>> 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')
>>    """
(Continue reading)

mark florisson | 10 May 10:34 2012
Picon

Re: [Cython] CF based type inference

On 10 May 2012 08:27, Vitja Makarov <vitja.makarov <at> gmail.com> wrote:
> 2012/5/10 Stefan Behnel <stefan_ml <at> behnel.de>:
>> Vitja Makarov, 08.05.2012 15:47:
>>> 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')
(Continue reading)

Stefan Behnel | 9 May 11:34 2012
Picon

Re: [Cython] CF based type inference

Stefan Behnel, 08.05.2012 14:24:
> Vitja has rebased the type inference on the control flow

On a related note, is this fixable now?

  def test():
      x = 1    # inferred as int
      del x    # error: Deletion of non-Python, non-C++ object

http://trac.cython.org/cython_trac/ticket/768

It might be enough to infer "object" for names that are being del-ed for
now, and to fix "del" The Right Way when we split entries.

Stefan
Vitja Makarov | 9 May 14:21 2012
Picon

Re: [Cython] CF based type inference

2012/5/9 Stefan Behnel <stefan_ml@...>:
> Stefan Behnel, 08.05.2012 14:24:
>> Vitja has rebased the type inference on the control flow
>
> On a related note, is this fixable now?
>
>  def test():
>      x = 1    # inferred as int
>      del x    # error: Deletion of non-Python, non-C++ object
>
> http://trac.cython.org/cython_trac/ticket/768
>
> It might be enough to infer "object" for names that are being del-ed for
> now, and to fix "del" The Right Way when we split entries.
>

Do you mean that `x` should be inferred as "python object" in your example?

Yes, we may add workaround for del <unspecified_type> case.
Del is represented now by NameDeletion with the same rhs and lhs.

We can add method infer_type() to NameAssignment and use it instead of
Node.infer_type()

--

-- 
vitja.
Vitja Makarov | 9 May 14:39 2012
Picon

Re: [Cython] CF based type inference

2012/5/9 Vitja Makarov <vitja.makarov@...>:
> 2012/5/9 Stefan Behnel <stefan_ml@...>:
>> Stefan Behnel, 08.05.2012 14:24:
>>> Vitja has rebased the type inference on the control flow
>>
>> On a related note, is this fixable now?
>>
>>  def test():
>>      x = 1    # inferred as int
>>      del x    # error: Deletion of non-Python, non-C++ object
>>
>> http://trac.cython.org/cython_trac/ticket/768
>>
>> It might be enough to infer "object" for names that are being del-ed for
>> now, and to fix "del" The Right Way when we split entries.
>>
>
> Do you mean that `x` should be inferred as "python object" in your example?
>
> Yes, we may add workaround for del <unspecified_type> case.
> Del is represented now by NameDeletion with the same rhs and lhs.
>
> We can add method infer_type() to NameAssignment and use it instead of
> Node.infer_type()
>
>

Here I've tried to fix it, now deletion always infers as python_object

https://github.com/vitek/cython/commit/225c9c60bed6406db46e87da31596e053056f8b7
(Continue reading)

mark florisson | 9 May 14:43 2012
Picon

Re: [Cython] CF based type inference

On 9 May 2012 13:39, Vitja Makarov <vitja.makarov <at> gmail.com> wrote:
> 2012/5/9 Vitja Makarov <vitja.makarov <at> gmail.com>:
>> 2012/5/9 Stefan Behnel <stefan_ml <at> behnel.de>:
>>> Stefan Behnel, 08.05.2012 14:24:
>>>> Vitja has rebased the type inference on the control flow
>>>
>>> On a related note, is this fixable now?
>>>
>>>  def test():
>>>      x = 1    # inferred as int
>>>      del x    # error: Deletion of non-Python, non-C++ object
>>>
>>> http://trac.cython.org/cython_trac/ticket/768
>>>
>>> It might be enough to infer "object" for names that are being del-ed for
>>> now, and to fix "del" The Right Way when we split entries.
>>>
>>
>> Do you mean that `x` should be inferred as "python object" in your example?
>>
>> Yes, we may add workaround for del <unspecified_type> case.
>> Del is represented now by NameDeletion with the same rhs and lhs.
>>
>> We can add method infer_type() to NameAssignment and use it instead of
>> Node.infer_type()
>>
>>
>
> Here I've tried to fix it, now deletion always infers as python_object
>
(Continue reading)

Vitja Makarov | 9 May 14:47 2012
Picon

Re: [Cython] CF based type inference

2012/5/9 mark florisson <markflorisson88@...>:
> On 9 May 2012 13:39, Vitja Makarov <vitja.makarov@...> wrote:
>> 2012/5/9 Vitja Makarov <vitja.makarov@...>:
>>> 2012/5/9 Stefan Behnel <stefan_ml@...>:
>>>> Stefan Behnel, 08.05.2012 14:24:
>>>>> Vitja has rebased the type inference on the control flow
>>>>
>>>> On a related note, is this fixable now?
>>>>
>>>>  def test():
>>>>      x = 1    # inferred as int
>>>>      del x    # error: Deletion of non-Python, non-C++ object
>>>>
>>>> http://trac.cython.org/cython_trac/ticket/768
>>>>
>>>> It might be enough to infer "object" for names that are being del-ed for
>>>> now, and to fix "del" The Right Way when we split entries.
>>>>
>>>
>>> Do you mean that `x` should be inferred as "python object" in your example?
>>>
>>> Yes, we may add workaround for del <unspecified_type> case.
>>> Del is represented now by NameDeletion with the same rhs and lhs.
>>>
>>> We can add method infer_type() to NameAssignment and use it instead of
>>> Node.infer_type()
>>>
>>>
>>
>> Here I've tried to fix it, now deletion always infers as python_object
(Continue reading)

Vitja Makarov | 9 May 14:58 2012
Picon

Re: [Cython] CF based type inference

2012/5/9 Vitja Makarov <vitja.makarov@...>:
> 2012/5/9 mark florisson <markflorisson88@...>:
>> On 9 May 2012 13:39, Vitja Makarov <vitja.makarov@...> wrote:
>>> 2012/5/9 Vitja Makarov <vitja.makarov@...>:
>>>> 2012/5/9 Stefan Behnel <stefan_ml@...>:
>>>>> Stefan Behnel, 08.05.2012 14:24:
>>>>>> Vitja has rebased the type inference on the control flow
>>>>>
>>>>> On a related note, is this fixable now?
>>>>>
>>>>>  def test():
>>>>>      x = 1    # inferred as int
>>>>>      del x    # error: Deletion of non-Python, non-C++ object
>>>>>
>>>>> http://trac.cython.org/cython_trac/ticket/768
>>>>>
>>>>> It might be enough to infer "object" for names that are being del-ed for
>>>>> now, and to fix "del" The Right Way when we split entries.
>>>>>
>>>>
>>>> Do you mean that `x` should be inferred as "python object" in your example?
>>>>
>>>> Yes, we may add workaround for del <unspecified_type> case.
>>>> Del is represented now by NameDeletion with the same rhs and lhs.
>>>>
>>>> We can add method infer_type() to NameAssignment and use it instead of
>>>> Node.infer_type()
>>>>
>>>>
>>>
(Continue reading)

Vitja Makarov | 9 May 15:16 2012
Picon

Re: [Cython] CF based type inference

2012/5/9 Vitja Makarov <vitja.makarov@...>:
> 2012/5/9 Vitja Makarov <vitja.makarov@...>:
>> 2012/5/9 mark florisson <markflorisson88@...>:
>>> On 9 May 2012 13:39, Vitja Makarov <vitja.makarov@...> wrote:
>>>> 2012/5/9 Vitja Makarov <vitja.makarov@...>:
>>>>> 2012/5/9 Stefan Behnel <stefan_ml@...>:
>>>>>> Stefan Behnel, 08.05.2012 14:24:
>>>>>>> Vitja has rebased the type inference on the control flow
>>>>>>
>>>>>> On a related note, is this fixable now?
>>>>>>
>>>>>>  def test():
>>>>>>      x = 1    # inferred as int
>>>>>>      del x    # error: Deletion of non-Python, non-C++ object
>>>>>>
>>>>>> http://trac.cython.org/cython_trac/ticket/768
>>>>>>
>>>>>> It might be enough to infer "object" for names that are being del-ed for
>>>>>> now, and to fix "del" The Right Way when we split entries.
>>>>>>
>>>>>
>>>>> Do you mean that `x` should be inferred as "python object" in your example?
>>>>>
>>>>> Yes, we may add workaround for del <unspecified_type> case.
>>>>> Del is represented now by NameDeletion with the same rhs and lhs.
>>>>>
>>>>> We can add method infer_type() to NameAssignment and use it instead of
>>>>> Node.infer_type()
>>>>>
>>>>>
(Continue reading)

mark florisson | 9 May 15:18 2012
Picon

Re: [Cython] CF based type inference

On 9 May 2012 14:16, Vitja Makarov <vitja.makarov <at> gmail.com> wrote:
> 2012/5/9 Vitja Makarov <vitja.makarov <at> gmail.com>:
>> 2012/5/9 Vitja Makarov <vitja.makarov <at> gmail.com>:
>>> 2012/5/9 mark florisson <markflorisson88 <at> gmail.com>:
>>>> On 9 May 2012 13:39, Vitja Makarov <vitja.makarov <at> gmail.com> wrote:
>>>>> 2012/5/9 Vitja Makarov <vitja.makarov <at> gmail.com>:
>>>>>> 2012/5/9 Stefan Behnel <stefan_ml <at> behnel.de>:
>>>>>>> Stefan Behnel, 08.05.2012 14:24:
>>>>>>>> Vitja has rebased the type inference on the control flow
>>>>>>>
>>>>>>> On a related note, is this fixable now?
>>>>>>>
>>>>>>>  def test():
>>>>>>>      x = 1    # inferred as int
>>>>>>>      del x    # error: Deletion of non-Python, non-C++ object
>>>>>>>
>>>>>>> http://trac.cython.org/cython_trac/ticket/768
>>>>>>>
>>>>>>> It might be enough to infer "object" for names that are being del-ed for
>>>>>>> now, and to fix "del" The Right Way when we split entries.
>>>>>>>
>>>>>>
>>>>>> Do you mean that `x` should be inferred as "python object" in your example?
>>>>>>
>>>>>> Yes, we may add workaround for del <unspecified_type> case.
>>>>>> Del is represented now by NameDeletion with the same rhs and lhs.
>>>>>>
>>>>>> We can add method infer_type() to NameAssignment and use it instead of
>>>>>> Node.infer_type()
>>>>>>
(Continue reading)

Stefan Behnel | 9 May 15:33 2012
Picon

Re: [Cython] CF based type inference

mark florisson, 09.05.2012 15:18:
> On 9 May 2012 14:16, Vitja Makarov wrote:
>> from cython cimport typeof
>>
>> def foo(float[::1] a):
>>    b = a
>>    #del b
>>    print typeof(b)
>>    print typeof(a)
>>
>>
>> In this example `b` is inferred as 'Python object' and not
>> `float[::1]`, is that correct?
>>
> That's the current behaviour, but it would be better if it inferred a
> memoryview slice instead.

+1

Stefan
Robert Bradshaw | 9 May 20:15 2012
Picon

Re: [Cython] CF based type inference

On Wed, May 9, 2012 at 6:33 AM, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
> mark florisson, 09.05.2012 15:18:
>> On 9 May 2012 14:16, Vitja Makarov wrote:
>>> from cython cimport typeof
>>>
>>> def foo(float[::1] a):
>>>    b = a
>>>    #del b
>>>    print typeof(b)
>>>    print typeof(a)
>>>
>>>
>>> In this example `b` is inferred as 'Python object' and not
>>> `float[::1]`, is that correct?
>>>
>> That's the current behaviour, but it would be better if it inferred a
>> memoryview slice instead.
>
> +1

+1. This looks like it would break inference of extension classes as well.

https://github.com/vitek/cython/commit/f5acf44be0f647bdcbb5a23c8bfbceff48f4414e#L0R336

could be changed to check if it's already a py_object_type (or memory
view) as a quick fix, but it's not as pure as adding the constraints
"can be del'ed" to the type inference engine.

- Robert
_______________________________________________
(Continue reading)

Vitja Makarov | 9 May 20:21 2012
Picon

Re: [Cython] CF based type inference

2012/5/9 Robert Bradshaw <robertwb@...>:
> On Wed, May 9, 2012 at 6:33 AM, Stefan Behnel <stefan_ml@...> wrote:
>> mark florisson, 09.05.2012 15:18:
>>> On 9 May 2012 14:16, Vitja Makarov wrote:
>>>> from cython cimport typeof
>>>>
>>>> def foo(float[::1] a):
>>>>    b = a
>>>>    #del b
>>>>    print typeof(b)
>>>>    print typeof(a)
>>>>
>>>>
>>>> In this example `b` is inferred as 'Python object' and not
>>>> `float[::1]`, is that correct?
>>>>
>>> That's the current behaviour, but it would be better if it inferred a
>>> memoryview slice instead.
>>
>> +1
>
> +1. This looks like it would break inference of extension classes as well.
>
> https://github.com/vitek/cython/commit/f5acf44be0f647bdcbb5a23c8bfbceff48f4414e#L0R336
>
> could be changed to check if it's already a py_object_type (or memory
> view) as a quick fix, but it's not as pure as adding the constraints
> "can be del'ed" to the type inference engine.
>

(Continue reading)

Vitja Makarov | 10 May 11:34 2012
Picon

Re: [Cython] CF based type inference

2012/5/9 Robert Bradshaw <robertwb@...>:
> On Wed, May 9, 2012 at 6:33 AM, Stefan Behnel <stefan_ml@...> wrote:
>> mark florisson, 09.05.2012 15:18:
>>> On 9 May 2012 14:16, Vitja Makarov wrote:
>>>> from cython cimport typeof
>>>>
>>>> def foo(float[::1] a):
>>>>    b = a
>>>>    #del b
>>>>    print typeof(b)
>>>>    print typeof(a)
>>>>
>>>>
>>>> In this example `b` is inferred as 'Python object' and not
>>>> `float[::1]`, is that correct?
>>>>
>>> That's the current behaviour, but it would be better if it inferred a
>>> memoryview slice instead.
>>
>> +1
>
> +1. This looks like it would break inference of extension classes as well.
>
> https://github.com/vitek/cython/commit/f5acf44be0f647bdcbb5a23c8bfbceff48f4414e#L0R336
>
> could be changed to check if it's already a py_object_type (or memory
> view) as a quick fix, but it's not as pure as adding the constraints
> "can be del'ed" to the type inference engine.
>

(Continue reading)

Stefan Behnel | 9 May 15:27 2012
Picon

Re: [Cython] CF based type inference

Vitja Makarov, 09.05.2012 15:16:
> 2012/5/9 Vitja Makarov:
>>>> On 9 May 2012 13:39, Vitja Makarov wrote:
>>>>> 2012/5/9 Vitja Makarov:
>>>>>> 2012/5/9 Stefan Behnel:
>>>>>>>  def test():
>>>>>>>      x = 1    # inferred as int
>>>>>>>      del x    # error: Deletion of non-Python, non-C++ object
>>>>>>>
>>>>>>> http://trac.cython.org/cython_trac/ticket/768
>>>>>>>
>>>>>>> It might be enough to infer "object" for names that are being del-ed for
>>>>>>> now, and to fix "del" The Right Way when we split entries.
>>>>>>
>>>>>> Do you mean that `x` should be inferred as "python object" in your example?
>>>>>>
>>>>>> Yes, we may add workaround for del <unspecified_type> case.
>>>>>> Del is represented now by NameDeletion with the same rhs and lhs.
>>>>>>
>>>>>> We can add method infer_type() to NameAssignment and use it instead of
>>>>>> Node.infer_type()

Yes, looks ok.

>>>>> Here I've tried to fix it, now deletion always infers as python_object
>>>>>
>>>>> https://github.com/vitek/cython/commit/225c9c60bed6406db46e87da31596e053056f8b7
>>>>>
>>>>> That may break C++ object deletion
>>
(Continue reading)


Gmane