Just watching from the sides....
But, I vote +1 on disallowing the "almost" dict notation {a:1, b:2}.
Brian
On Thu, Oct 16, 2008 at 8:33 AM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
> On Oct 16, 2008, at 7:20 AM, Lisandro Dalcin wrote:
>
>> On Thu, Oct 16, 2008 at 12:43 AM, Greg Ewing
>> <[EMAIL PROTECTED]> wrote:
>>> Lisandro Dalcin wrote:
>>>
>>>> And how are you going to free the memory?
>>>
>>> I'm not, that's up to the programmer. It's just a
>>> more convenient way of writing a malloc.
>>
>> Then I have to say that I'm -1 in such magic. What about introducing
>> two new pseudo-keywords cnew/cdel, and use it like this (like in C++):
>>
>> MyStruct *p = cnew MyStruct(a=1,b=2)
>> # use p
>> cdel p # also sets p to NULL
>> assert p==NULL
>> cdel p # success, but do nothing?
>>
>> Such approach would make Cython/Pyrex closer to C++ behavior.
>> Moreover, this could be extended to support funny features, like
>> letting user choose the alloc/dealloc routines and perhaps
>> constructor/destructor routines.
>>
>> What do you think?
>
> First, thanks for all the feedback, and thanks Dag for bringing this up.
>
> I'd rather focus on making Cython closer to the Python language than
> introducing new concepts. Also, I'm with Stefan that it is very
> dangerous to hide the malloc and expect the user to explicitly
> provide the free. If the user wants to manage their own memory, they
> can do so with malloc and friends (understanding the associated
> dangers), and any special memory-management stuff we add should be as
> implicit and easy to use as Python's garbage collection (and probably
> piggyback off of it).
>
> I think the MyStruct(...) should result in an actual struct (not a
> pointer), but perhaps on conversion to an object it could be made
> into a memory managed version of the struct (e.g. using the same
> string allocation trick we talked about for arrays) giving C access,
> pass-by-reference, and memory management. This, however, is not going
> to happen in the next release of Cython and when it does it could be
> made backwards compatible with the current conversion to dict.
> (Syntax suggestions for how to declare such an object welcome,
> perhaps "cdef object MyStruct foo" and memory-managed arrays could be
> "cdef object int[] foo")
>
> As for the current proposal, don't want to introduce new, special
> "struct instanciation dictionaries," so I'd opt for allowing the
> {"a": 1, "b": 2} literals with the plan of conversion from a runtime
> dict down the road (including runtime-created keys), but disabling
> the {a: 1, b: 2} as the MyStruct(a=1, b=2) is available (and, even
> better, more explicit).
>
> - Robert
>
> _______________________________________________
> Cython-dev mailing list
> [email protected]
> http://codespeak.net/mailman/listinfo/cython-dev
>
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
