headers
Stefan Behnel | 1 Feb 2010 08:42
Picon
Favicon

Re: [Cython] C++ support - A simple tutorial


Robert Bradshaw, 30.01.2010 01:31:
> There's no way to interpret the expression
> 
>      new A(1,10)
> 
> as valid Python, so there's no ambiguity.

Ok, it's not /really/ a keyword then, in the sense that it cannot appear
outside of its grammar context. It would still be allowed everywhere,
except that the case that it is followed by a name would be special cased.

But doesn't that overly complicate the parser? I mean, 'new' can
potentially appear in most places of an expression, and it can always mean
both things...

Stefan
Permalink | Reply | 2 comments |
headers
Dag Sverre Seljebotn | 1 Feb 2010 09:29
Picon
Picon

Re: [Cython] C++ support - A simple tutorial

Stefan Behnel wrote:
> Robert Bradshaw, 30.01.2010 01:31:
>   
>> There's no way to interpret the expression
>>
>>      new A(1,10)
>>
>> as valid Python, so there's no ambiguity.
>>     
>
> Ok, it's not /really/ a keyword then, in the sense that it cannot appear
> outside of its grammar context. It would still be allowed everywhere,
> except that the case that it is followed by a name would be special cased.
>
> But doesn't that overly complicate the parser? I mean, 'new' can
> potentially appear in most places of an expression, and it can always mean
> both things...
>   
There's a limit to how simple the parser can be anyway, we can't use the 
simple parsing strategy of Python since we're supporting some C syntax. 
The tokenizer supports putting tokens back, so one can simply try for 
"new X" first, and if there's no match then one can put the token back 
into the tokenizer and call p_expr. Not much more complicated than 
anything else that goes on in the parser...

Dag Sverre
Permalink | Reply | 1 comment |
headers
Stefan Behnel | 1 Feb 2010 10:30
Picon
Favicon

[Cython] Fwd: [codespeak-ann] codespeak migration 3rd feb 2010

FYI

-------- Original-Message --------
Subject: [codespeak-ann] codespeak migration 3rd feb 2010
Date: Mon, 1 Feb 2010 10:16:43 +0100
From: holger krekel <holger@...>
To: codespeak-ann@...

Hi all,

3rd Feb 2010, wednesday afternoon, we plan to migrate codespeak to a new
host -
we are leaving XEN and going for KVM, together with a hardware upgrade.

Please be prepared for downtimes on that afternoon.

Oh and if somebody is interested and wants to help with providing
mercurial hosting on codespeak please contact me.

cheers,
holger
Permalink | Reply | 0 comments |
headers
Stefan Behnel | 1 Feb 2010 14:06
Picon
Favicon

Re: [Cython] Support for borrowed references


Dag Sverre Seljebotn, 25.01.2010 10:17:
> Stefan Behnel wrote:
>>> [...] why not just represent a borrowed reference as a pointer?
>>> So you could write
>>>
>>>      cdef list some_list = []
>>>      cdef list* borrowed_ref = some_list
>>>
>>> and borrowed_ref would be a non-refcounted pointer to a Python list. 
>>> Assignments back to a normal reference would be allowed:
>>>
>>>      cdef list my_list = borrowed_ref   # increfs the pointer
>>>
>>> After all, a non-refcounted reference to a Python object is not more than a 
>>> bare pointer to a well-defined Python builtin/extension type (including 
>>> "object*").
> 
> Well, there's the drawback of making the language more complicated, and 
> also I think the notation is confusing -- plain "object" is not by 
> value, and "object*" is not a pointer to an "object", so to speak.

I was trying to let the syntax emphasise that it *is* a pointer, not a
reference. A reference is special in Cython in that it handles ref-counting
for it. A pointer just behaves like any other pointer in the language.

I agree that it's not flawless, but I think it makes sense and is unambiguous.

> How about a set of explicit functions like
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Dag Sverre Seljebotn | 1 Feb 2010 15:37
Picon
Picon

Re: [Cython] Support for borrowed references

Stefan Behnel wrote:
> Dag Sverre Seljebotn, 25.01.2010 10:17:
>   
>> Stefan Behnel wrote:
>>     
>>>> [...] why not just represent a borrowed reference as a pointer?
>>>> So you could write
>>>>
>>>>      cdef list some_list = []
>>>>      cdef list* borrowed_ref = some_list
>>>>
>>>> and borrowed_ref would be a non-refcounted pointer to a Python list. 
>>>> Assignments back to a normal reference would be allowed:
>>>>
>>>>      cdef list my_list = borrowed_ref   # increfs the pointer
>>>>
>>>> After all, a non-refcounted reference to a Python object is not more than a 
>>>> bare pointer to a well-defined Python builtin/extension type (including 
>>>> "object*").
>>>>         
>> Well, there's the drawback of making the language more complicated, and 
>> also I think the notation is confusing -- plain "object" is not by 
>> value, and "object*" is not a pointer to an "object", so to speak.
>>     
>
> I was trying to let the syntax emphasise that it *is* a pointer, not a
> reference. A reference is special in Cython in that it handles ref-counting
> for it. A pointer just behaves like any other pointer in the language.
>
> I agree that it's not flawless, but I think it makes sense and is unambiguous.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dag Sverre Seljebotn | 1 Feb 2010 15:39
Picon
Picon

Re: [Cython] Support for borrowed references

Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> Dag Sverre Seljebotn, 25.01.2010 10:17:
>>  
>>> Stefan Behnel wrote:
>>>    
>>>>> [...] why not just represent a borrowed reference as a pointer?
>>>>> So you could write
>>>>>
>>>>>      cdef list some_list = []
>>>>>      cdef list* borrowed_ref = some_list
>>>>>
>>>>> and borrowed_ref would be a non-refcounted pointer to a Python 
>>>>> list. Assignments back to a normal reference would be allowed:
>>>>>
>>>>>      cdef list my_list = borrowed_ref   # increfs the pointer
>>>>>
>>>>> After all, a non-refcounted reference to a Python object is not 
>>>>> more than a bare pointer to a well-defined Python 
>>>>> builtin/extension type (including "object*").
>>>>>         
>>> Well, there's the drawback of making the language more complicated, 
>>> and also I think the notation is confusing -- plain "object" is not 
>>> by value, and "object*" is not a pointer to an "object", so to speak.
>>>     
>>
>> I was trying to let the syntax emphasise that it *is* a pointer, not a
>> reference. A reference is special in Cython in that it handles 
>> ref-counting
>> for it. A pointer just behaves like any other pointer in the language.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dag Sverre Seljebotn | 1 Feb 2010 15:39
Picon
Picon

Re: [Cython] Support for borrowed references

Dag Sverre Seljebotn wrote:
> Dag Sverre Seljebotn wrote:
>> Stefan Behnel wrote:
>>> Dag Sverre Seljebotn, 25.01.2010 10:17:
>>>  
>>>> Stefan Behnel wrote:
>>>>   
>>>>>> [...] why not just represent a borrowed reference as a pointer?
>>>>>> So you could write
>>>>>>
>>>>>>      cdef list some_list = []
>>>>>>      cdef list* borrowed_ref = some_list
>>>>>>
>>>>>> and borrowed_ref would be a non-refcounted pointer to a Python 
>>>>>> list. Assignments back to a normal reference would be allowed:
>>>>>>
>>>>>>      cdef list my_list = borrowed_ref   # increfs the pointer
>>>>>>
>>>>>> After all, a non-refcounted reference to a Python object is not 
>>>>>> more than a bare pointer to a well-defined Python 
>>>>>> builtin/extension type (including "object*").
>>>>>>         
>>>> Well, there's the drawback of making the language more complicated, 
>>>> and also I think the notation is confusing -- plain "object" is not 
>>>> by value, and "object*" is not a pointer to an "object", so to speak.
>>>>     
>>>
>>> I was trying to let the syntax emphasise that it *is* a pointer, not a
>>> reference. A reference is special in Cython in that it handles 
>>> ref-counting
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Behnel | 1 Feb 2010 16:41
Picon
Favicon

Re: [Cython] Support for borrowed references


Dag Sverre Seljebotn, 01.02.2010 15:37:
> I'd be fine with almost any kind of syntax which is a superset of the 
> current syntax -- "cdef nonmanaged object x", you name it. The problem 
> with "object*" is that it is not immediately obvious to a reader with a 
> brief knowledge of Cython that it is fundamentally different from "int*".

Makes sense to me. Then we're back to "borrowed" as an object type modifier.

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

Stefan
Permalink | Reply | 0 comments |
headers
Robert Bradshaw | 1 Feb 2010 20:19
Favicon

Re: [Cython] C++ support - A simple tutorial

On Feb 1, 2010, at 12:29 AM, Dag Sverre Seljebotn wrote:

> Stefan Behnel wrote:
>> Robert Bradshaw, 30.01.2010 01:31:
>>
>>> There's no way to interpret the expression
>>>
>>>     new A(1,10)
>>>
>>> as valid Python, so there's no ambiguity.
>>>
>>
>> Ok, it's not /really/ a keyword then, in the sense that it cannot  
>> appear
>> outside of its grammar context. It would still be allowed everywhere,
>> except that the case that it is followed by a name would be special  
>> cased.

Exactly. The same as "extern" or "public" is not really a keyword.

>> But doesn't that overly complicate the parser? I mean, 'new' can
>> potentially appear in most places of an expression, and it can  
>> always mean
>> both things...
>>
> There's a limit to how simple the parser can be anyway, we can't use  
> the
> simple parsing strategy of Python since we're supporting some C  
> syntax.
> The tokenizer supports putting tokens back, so one can simply try for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Bradshaw | 1 Feb 2010 20:31
Favicon

Re: [Cython] Support for borrowed references

On Feb 1, 2010, at 6:37 AM, Dag Sverre Seljebotn wrote:

> Stefan Behnel wrote:
>> Dag Sverre Seljebotn, 25.01.2010 10:17:
>>
>>> Stefan Behnel wrote:
>>>
>>>>> [...] why not just represent a borrowed reference as a pointer?
>>>>> So you could write
>>>>>
>>>>>     cdef list some_list = []
>>>>>     cdef list* borrowed_ref = some_list
>>>>>
>>>>> and borrowed_ref would be a non-refcounted pointer to a Python  
>>>>> list.
>>>>> Assignments back to a normal reference would be allowed:
>>>>>
>>>>>     cdef list my_list = borrowed_ref   # increfs the pointer
>>>>>
>>>>> After all, a non-refcounted reference to a Python object is not  
>>>>> more than a
>>>>> bare pointer to a well-defined Python builtin/extension type  
>>>>> (including
>>>>> "object*").
>>>>>
>>> Well, there's the drawback of making the language more  
>>> complicated, and
>>> also I think the notation is confusing -- plain "object" is not by
>>> value, and "object*" is not a pointer to an "object", so to speak.
>>>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane