On Thu, Oct 3, 2013 at 3:06 PM, Chuck Blake wrote:
> Robert Bradshaw [rober...@gmail.com] wrote:
>>Yes, it still is. But it would be nice to get any such major changes
>>out of the way ahead of time.
>
> I think the "compiling Python" goal is so orthogonal to the goal of
> how "beyond Python synta
Robert Bradshaw [rober...@gmail.com] wrote:
>Yes, it still is. But it would be nice to get any such major changes
>out of the way ahead of time.
I think the "compiling Python" goal is so orthogonal to the goal of
how "beyond Python syntax work" or simplicity of the parsing impl
that "getting it ou
On Thu, Oct 3, 2013 at 9:30 AM, Chuck Blake wrote:
> Greg Ewing wrote:
>>What would be the benefit of this? You're proposing to change
>>from something identical to C declaration syntax, which is
>>second nature for a great many people, to something that
>>looks deceptively like C syntax but isn't
On Thu, Oct 3, 2013 at 10:21 AM, Nathaniel Smith wrote:
> On Thu, Oct 3, 2013 at 5:03 PM, Robert Bradshaw wrote:
>> On Thu, Oct 3, 2013 at 7:13 AM, Nathaniel Smith wrote:
>>> On Thu, Oct 3, 2013 at 3:00 PM, Stefan Behnel wrote:
Nathaniel Smith, 03.10.2013 14:35:
> On Thu, Oct 3, 2013 a
On Thu, Oct 3, 2013 at 5:03 PM, Robert Bradshaw wrote:
> On Thu, Oct 3, 2013 at 7:13 AM, Nathaniel Smith wrote:
>> On Thu, Oct 3, 2013 at 3:00 PM, Stefan Behnel wrote:
>>> Nathaniel Smith, 03.10.2013 14:35:
On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote:
> Greg Ewing, 03.10.2013 14
Greg Ewing wrote:
>What would be the benefit of this? You're proposing to change
>from something identical to C declaration syntax, which is
>second nature for a great many people, to something that
>looks deceptively like C syntax but isn't.
>
>I can't see that causing anything other than a massiv
On Thu, Oct 3, 2013 at 7:13 AM, Nathaniel Smith wrote:
> On Thu, Oct 3, 2013 at 3:00 PM, Stefan Behnel wrote:
>> Nathaniel Smith, 03.10.2013 14:35:
>>> On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote:
Greg Ewing, 03.10.2013 14:10:
> Robert Bradshaw wrote:
>> cdef int *a, b, c
On Thu, Oct 3, 2013 at 3:00 PM, Stefan Behnel wrote:
> Nathaniel Smith, 03.10.2013 14:35:
>> On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote:
>>> Greg Ewing, 03.10.2013 14:10:
Robert Bradshaw wrote:
> cdef int *a, b, c, *d[3]
>
> is IMHO quite ugly but also adds a lot of c
Nathaniel Smith, 03.10.2013 14:35:
> On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote:
>> Greg Ewing, 03.10.2013 14:10:
>>> Robert Bradshaw wrote:
cdef int *a, b, c, *d[3]
is IMHO quite ugly but also adds a lot of complexity to the parser.
What if instead we required
On Thu, Oct 3, 2013 at 1:23 PM, Stefan Behnel wrote:
> Greg Ewing, 03.10.2013 14:10:
>> Robert Bradshaw wrote:
>>> cdef int *a, b, c, *d[3]
>>>
>>> is IMHO quite ugly but also adds a lot of complexity to the parser.
>>> What if instead we required
>>>
>>> cdef int* a
>>> cdef int b, c
Greg Ewing, 03.10.2013 14:10:
> Robert Bradshaw wrote:
>> cdef int *a, b, c, *d[3]
>>
>> is IMHO quite ugly but also adds a lot of complexity to the parser.
>> What if instead we required
>>
>> cdef int* a
>> cdef int b, c
>> cdef int[3]* d
The last line looks ambiguous, BTW, hadn'
Robert Bradshaw wrote:
cdef int *a, b, c, *d[3]
is IMHO quite ugly but also adds a lot of complexity to the parser.
What if instead we required
cdef int* a
cdef int b, c
cdef int[3]* d
What would be the benefit of this? You're proposing to change
from something identical to C
Robert Bradshaw, 03.10.2013 05:38:
> In thinking about 1.0, this would be a chance to make
> backwards-incompatible changes. One thing that has always bothered me
> is the C-delclarator decoration for specifying complex types.
> Specifically,
>
> cdef int *a, b, c, *d[3]
>
> is IMHO quite ugl
Hi,
I'm new to cython's typed memory view, and found some cases where the
function that uses typed memory view has memory leaking.
The leak happens when I pass a numpy array of objects, where each object
itself is a numpy array.( You can get this 'weird' object from construction
a pandas Series wi
14 matches
Mail list logo
