Re: [Cython] Cython 0.16: "eval" problem
2012/4/22 Vitja Makarov :
> 2012/4/22 Nathan Dunfield :
>> On Apr 22, 2012, at 1:22 PM, Vitja Makarov wrote:
>>> Oops, it seems to be a problem with locals() dict creation.
>>
>> Yes it does. The following variants of my original example both work:
>>
>> ## prob.pyx version 1
>>
>> def cy_eval(s):
>> return eval(s)
>>
>> def f(x):
>> cdef int* p
>> return cy_eval(x)
>>
>> ## prob.pyx version 2
>>
>> def f(x):
>> cdef int* p
>> return eval(x, {})
>>
>> Best,
>>
>> Nathan
>>
>
> I've fixed it here:
> https://github.com/vitek/cython/commit/6dc132731b8f3f7eaabf55e51d89bcbc7b8f4eb7
>
> Now waiting for jenkins, then I'll push it into upstream. As a
> workaround you can manually pass locals dictionary, e.g.:
>
> eval(x, None, {'a: a})
>
Btw before 0.16 locals() weren't passed to eval. I've tried the
following code and it fails with 0.15:
def foo():
cdef int *a
return locals()
I've pushed fix to upstream/master
https://github.com/cython/cython/commit/0b133e00a7bc3c53ea60d3cf4ae8eb3e20ef49ec
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] test crash in Py3.2 (NumPy/memoryview/refcounting related?)
mark florisson, 22.04.2012 16:41: > On 22 April 2012 15:31, mark florisson wrote: >> I think the problem here >> is that a single memoryview object is traversed multiple times through >> different traverse functions, and that the refcount doesn't match the >> number of traverses. Indeed, the refcount is only one, as the actual >> count is the acquisition count. So we shouldn't traverse the >> memoryview objects in memoryview slices, i.e. not >> _memoryviewslice.from_slice.memview. I'll come up with a commit >> shortly, would you be willing to test it? > > A fix is here: > https://github.com/markflorisson88/cython/commit/cd32184f3f782b6d7275cf430694b59801ce642a > > Lets see what jenkins has to say :) Seems to like it. > BTW, tp_clear calls Py_CLEAR on Py_buffer.obj, shouldn't it call > releasebuffer instead? Where is that? The memoryview class calls __Pyx_ReleaseBuffer() here. BTW, why are some of the self arguments in MemoryView.pyx explicitly typed as "memoryview"? Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] test crash in Py3.2 (NumPy/memoryview/refcounting related?)
On 23 April 2012 09:23, Stefan Behnel wrote: > mark florisson, 22.04.2012 16:41: >> On 22 April 2012 15:31, mark florisson wrote: >>> I think the problem here >>> is that a single memoryview object is traversed multiple times through >>> different traverse functions, and that the refcount doesn't match the >>> number of traverses. Indeed, the refcount is only one, as the actual >>> count is the acquisition count. So we shouldn't traverse the >>> memoryview objects in memoryview slices, i.e. not >>> _memoryviewslice.from_slice.memview. I'll come up with a commit >>> shortly, would you be willing to test it? >> >> A fix is here: >> https://github.com/markflorisson88/cython/commit/cd32184f3f782b6d7275cf430694b59801ce642a >> >> Lets see what jenkins has to say :) > > Seems to like it. > > >> BTW, tp_clear calls Py_CLEAR on Py_buffer.obj, shouldn't it call >> releasebuffer instead? > > Where is that? The memoryview class calls __Pyx_ReleaseBuffer() here. Yes, but ModuleNode generates a tp_clear for Py_buffer cdef class attributes that clears Py_buffer.obj, which means a subsequent __dealloc__ calling release buffer cannot call the release buffer function on the original object. > BTW, why are some of the self arguments in MemoryView.pyx explicitly typed > as "memoryview"? I suppose because the original code had that before I started, and then I continued with it a bit for consistency. > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] `cdef inline` and typed memory views
On 23 April 2012 07:24, Stefan Behnel wrote:
> mark florisson, 22.04.2012 22:20:
>> On 21 April 2012 20:17, Dimitri Tcaciuc wrote:
>>> Say I want to factor out inner part of
>>> some N^2 loops over a flow array, I write something like
>>>
>>> cdef inline float _inner(size_t i, size_t j, float[:] x):
>>> cdef float d = x[i] - x[j]
>>> return sqrtf(d * d)
>>>
>>> In 0.16, this actually compiles (as opposed to 0.15 with ndarray) and
>>> function is declared as inline, which is great. However, the
>>> memoryview structure is passed by value:
>>>
>>> static CYTHON_INLINE float __pyx_f_3foo__inner(size_t __pyx_v_i,
>>> size_t __pyx_v_j, __Pyx_memviewslice __pyx_v_x) {
>>> ...
>>>
>>> This seems to hinder compiler's (in my case, GCC 4.3.4) ability to
>>> perform efficient inlining (although function does in fact get
>>> inlined). If I manually inline that distance calculation, I get 3x
>>> speedup. (in my case 0.324020147324 vs 1.43209195137 seconds for 10k
>>> elements). When I manually modified generated .c file to pass memory
>>> view slice by pointer, slowdown was eliminated completely.
>>
>> Although it is neither documented nor tested, it works if you just
>> take the address of the memoryview. You can then index it using
>> memoryview_pointer[0][i].
>
> Are you advertising this an an actual feature here? I'm just asking because
> supporting hacks can be nasty in the long run. What if we ever want to make
> a change to the internal way memoryviews work that would break this?
>
> Stefan
> ___
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
Yeah, I'm not entirely sure if this is a hack or a feature. It doesn't
really matter how memoryviews are represented, or where they are
stored, as dereferencing the pointer gives you the same situation as
before. The only difference is when a) memoryviews would be relocated
or b) go out of scope.
If we're ever planning to support garbage collection (and I doubt we
are) or if we're ever going to allocate them on the heap and have a
variable-sized representation, a) could be a case. As for b), it's
really the same as automatic C variables. So I suppose I wouldn't be
opposed to officially supporting this.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
[Cython] tp_clear() of buffer client objects (was: Re: test crash in Py3.2 (NumPy/memoryview/refcounting related?))
Stefan Behnel, 23.04.2012 10:23: > mark florisson, 22.04.2012 16:41: >> On 22 April 2012 15:31, mark florisson wrote: >>> I think the problem here >>> is that a single memoryview object is traversed multiple times through >>> different traverse functions, and that the refcount doesn't match the >>> number of traverses. Indeed, the refcount is only one, as the actual >>> count is the acquisition count. So we shouldn't traverse the >>> memoryview objects in memoryview slices, i.e. not >>> _memoryviewslice.from_slice.memview. I'll come up with a commit >>> shortly, would you be willing to test it? >> >> BTW, tp_clear calls Py_CLEAR on Py_buffer.obj, shouldn't it call >> releasebuffer instead? > > Where is that? The memoryview class calls __Pyx_ReleaseBuffer() here. Ah, found it. Yes, tp_clear() would be called before __dealloc__() in reference cycles, so that's a problem. I'm not sure tp_clear should do something as (potentially) involved as freeing the buffer, but if the Py_buffer is owned by the object, then I guess it just has to do that. Otherwise, it would leak the buffer. The problem is that this also impacts user code, though, so a change might break code, e.g. when it needs to do some cleanup on its own before freeing the buffer. It would make the code more correct, sure, but it would still break it. Guess we have to take that route, though... Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] tp_clear() of buffer client objects (was: Re: test crash in Py3.2 (NumPy/memoryview/refcounting related?))
On 23 April 2012 09:42, Stefan Behnel wrote: > Stefan Behnel, 23.04.2012 10:23: >> mark florisson, 22.04.2012 16:41: >>> On 22 April 2012 15:31, mark florisson wrote: I think the problem here is that a single memoryview object is traversed multiple times through different traverse functions, and that the refcount doesn't match the number of traverses. Indeed, the refcount is only one, as the actual count is the acquisition count. So we shouldn't traverse the memoryview objects in memoryview slices, i.e. not _memoryviewslice.from_slice.memview. I'll come up with a commit shortly, would you be willing to test it? >>> >>> BTW, tp_clear calls Py_CLEAR on Py_buffer.obj, shouldn't it call >>> releasebuffer instead? >> >> Where is that? The memoryview class calls __Pyx_ReleaseBuffer() here. > > Ah, found it. Yes, tp_clear() would be called before __dealloc__() in > reference cycles, so that's a problem. I'm not sure tp_clear should do > something as (potentially) involved as freeing the buffer, but if the > Py_buffer is owned by the object, then I guess it just has to do that. > Otherwise, it would leak the buffer. > > The problem is that this also impacts user code, though, so a change might > break code, e.g. when it needs to do some cleanup on its own before freeing > the buffer. It would make the code more correct, sure, but it would still > break it. Guess we have to take that route, though... > > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel It also seems that tp_clear is only generated for object attributes, and then it includes freeing the object of Py_buffers (so only a Py_buffer attribute doesn't result in a tp_clear function). Finally, tp_dealloc doesn't deallocate buffers either, which it should. So both tp_clear and tp_dealloc should call release buffer (it can be called multiple times on the same buffer). ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] tp_clear() of buffer client objects
mark florisson, 23.04.2012 11:10: > On 23 April 2012 09:42, Stefan Behnel wrote: >> Stefan Behnel, 23.04.2012 10:23: >>> mark florisson, 22.04.2012 16:41: On 22 April 2012 15:31, mark florisson wrote: > I think the problem here > is that a single memoryview object is traversed multiple times through > different traverse functions, and that the refcount doesn't match the > number of traverses. Indeed, the refcount is only one, as the actual > count is the acquisition count. So we shouldn't traverse the > memoryview objects in memoryview slices, i.e. not > _memoryviewslice.from_slice.memview. I'll come up with a commit > shortly, would you be willing to test it? BTW, tp_clear calls Py_CLEAR on Py_buffer.obj, shouldn't it call releasebuffer instead? >>> >>> Where is that? The memoryview class calls __Pyx_ReleaseBuffer() here. >> >> Ah, found it. Yes, tp_clear() would be called before __dealloc__() in >> reference cycles, so that's a problem. I'm not sure tp_clear should do >> something as (potentially) involved as freeing the buffer, but if the >> Py_buffer is owned by the object, then I guess it just has to do that. >> Otherwise, it would leak the buffer. >> >> The problem is that this also impacts user code, though, so a change might >> break code, e.g. when it needs to do some cleanup on its own before freeing >> the buffer. It would make the code more correct, sure, but it would still >> break it. Guess we have to take that route, though... > > It also seems that tp_clear is only generated for object attributes, > and then it includes freeing the object of Py_buffers (so only a > Py_buffer attribute doesn't result in a tp_clear function). Finally, > tp_dealloc doesn't deallocate buffers either, which it should. So both > tp_clear and tp_dealloc should call release buffer Good call. > (it can be called > multiple times on the same buffer). I guess calling it the first time would set "obj" to NULL and the second time would recognise it and do nothing, right? That's fine. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Cython 0.16 issue Windows with Mingw32
I've encountered the following issue with Cython 0.16 on Windows with using the Mingw32 compiler (I'm using Python 3.2 here, but I don't think that's the issue): $ python3 setup.py build -c mingw32 running build running build_py running build_ext skipping 'SnapPy.c' Cython extension (up-to-date) building 'snappy.SnapPy' extension c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Iheaders -Iunix_kit -Iaddl_code -I. -Ipari/pari-2.3.4/include/ -Ipari/pari-2.3.4/include/pari -Ic:\Python32\include -Ic:\Python32\PC -c SnapPy.c -o build\temp.win32-3.2\Release\snappy.o SnapPy.c: In function `__pyx_f_6snappy_6SnapPy_13Triangulation_build_rep_into_Sn': SnapPy.c:25187: warning: implicit declaration of function `fg_get_num_orig_gens' SnapPy.c:25423: warning: implicit declaration of function `candidateSn_is_valid' SnapPy.c:25435: warning: implicit declaration of function `candidateSn_is_transitive' SnapPy.c: At top level: SnapPy.c:76434: error: initializer element is not constant SnapPy.c:76434: error: (near initialization for `__pyx_CyFunctionType_type.tp_call') error: command 'gcc' failed with exit status 1 The problem seems to be in the code that's pulled in from CythonFunction.c. I apologize for not providing a more minimal example (the above code is available at "hg clone static-http://math.uic.edu/t3m/hg/SnapPy";) but the small module I tried didn't pull in the CythonFunction.c code. Thanks, Nathan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Julialang
On Sun, Apr 22, 2012 at 1:59 AM, Lisandro Dalcin wrote: > On 22 April 2012 08:10, Robert Bradshaw wrote: >> Yes, Julia looks really cool. It's been on my radar for a while, but I >> haven't had a chance to really try it out for anything yet. But I >> hadn't thought about low-level Python/Cython <-> Julia integration. >> That sounds very interesting. I wonder if Jython could give any >> insight into to the tight interaction between two languages that are >> usually used in isolation but have been made to call each other >> (though there are a lot of differences too, e.g. we're not targeting >> replacing the CPython interpreter (on first pass at least...)). >> > > Are you all aware that "calling C" actually means a ctypes-like > functionality based in dlopen()/dlsym() ? > http://julialang.org/manual/calling-c-and-fortran-code/. Yes, with all its drawbacks, but the fact that it's JIT'ed at least cuts into the overhead issues. - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Julialang
I may be misuderstanding the intent here, but here it goes. If the main idea is to be able to call functions that are written in Julia or other languages, I think an effort to create an LLVM backend for Cython would go a long way towards inter-language connections as the one discussed here. It should be possible to take Cython- and Julia- produced LLVM bytecode and assemble it all together, applying whatever bytecode optimizers that are available (eg. SSE vectorization). A big advantage of that approach is that there's no need for one language to know syntax conventions of the other one (or at least not to full extent). Continuing the effort, it should be possible to eliminate the need for writing an intermediate .c/.cpp file if Clang compiler is used, which is also LLVM based. Dimitri. On Mon, Apr 23, 2012 at 9:30 AM, Robert Bradshaw wrote: > On Sun, Apr 22, 2012 at 1:59 AM, Lisandro Dalcin wrote: >> On 22 April 2012 08:10, Robert Bradshaw wrote: >>> Yes, Julia looks really cool. It's been on my radar for a while, but I >>> haven't had a chance to really try it out for anything yet. But I >>> hadn't thought about low-level Python/Cython <-> Julia integration. >>> That sounds very interesting. I wonder if Jython could give any >>> insight into to the tight interaction between two languages that are >>> usually used in isolation but have been made to call each other >>> (though there are a lot of differences too, e.g. we're not targeting >>> replacing the CPython interpreter (on first pass at least...)). >>> >> >> Are you all aware that "calling C" actually means a ctypes-like >> functionality based in dlopen()/dlsym() ? >> http://julialang.org/manual/calling-c-and-fortran-code/. > > Yes, with all its drawbacks, but the fact that it's JIT'ed at least > cuts into the overhead issues. > > - Robert > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Julialang
On Mon, Apr 23, 2012 at 10:09 AM, Dimitri Tcaciuc wrote: > I may be misuderstanding the intent here, but here it goes. > > If the main idea is to be able to call functions that are written in > Julia or other languages, I think an effort to create an LLVM backend > for Cython would go a long way towards inter-language connections as > the one discussed here. It should be possible to take Cython- and > Julia- produced LLVM bytecode and assemble it all together, applying > whatever bytecode optimizers that are available (eg. SSE > vectorization). A big advantage of that approach is that there's no > need for one language to know syntax conventions of the other one (or > at least not to full extent). Continuing the effort, it should be > possible to eliminate the need for writing an intermediate .c/.cpp > file if Clang compiler is used, which is also LLVM based. I should clarify myself to avoid a gross mistake; a .c module would still be necessary for CPython integration. > Dimitri. > > On Mon, Apr 23, 2012 at 9:30 AM, Robert Bradshaw wrote: >> On Sun, Apr 22, 2012 at 1:59 AM, Lisandro Dalcin wrote: >>> On 22 April 2012 08:10, Robert Bradshaw wrote: Yes, Julia looks really cool. It's been on my radar for a while, but I haven't had a chance to really try it out for anything yet. But I hadn't thought about low-level Python/Cython <-> Julia integration. That sounds very interesting. I wonder if Jython could give any insight into to the tight interaction between two languages that are usually used in isolation but have been made to call each other (though there are a lot of differences too, e.g. we're not targeting replacing the CPython interpreter (on first pass at least...)). >>> >>> Are you all aware that "calling C" actually means a ctypes-like >>> functionality based in dlopen()/dlsym() ? >>> http://julialang.org/manual/calling-c-and-fortran-code/. >> >> Yes, with all its drawbacks, but the fact that it's JIT'ed at least >> cuts into the overhead issues. >> >> - Robert >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Julialang
On Mon, Apr 23, 2012 at 6:09 PM, Dimitri Tcaciuc wrote: > I may be misuderstanding the intent here, but here it goes. > > If the main idea is to be able to call functions that are written in > Julia or other languages, I think an effort to create an LLVM backend > for Cython would go a long way towards inter-language connections as > the one discussed here. It should be possible to take Cython- and > Julia- produced LLVM bytecode and assemble it all together, applying > whatever bytecode optimizers that are available (eg. SSE > vectorization). A big advantage of that approach is that there's no > need for one language to know syntax conventions of the other one (or > at least not to full extent). Continuing the effort, it should be > possible to eliminate the need for writing an intermediate .c/.cpp > file if Clang compiler is used, which is also LLVM based. You'd still need some way to translate between the Cython and Julia calling conventions, runtimes, error handling, garbage collection regimes, etc. IIUC, LLVM IR isn't like the CLR -- it doesn't force languages into a common system for these things. Which might be great and worth the effort, I don't know, and don't want to discourage anyone. But there are literally hundreds of new languages designed every year, and a new *successful* language comes along maybe twice in a decade? And one of those recent ones was PHP, which shows you how important pure technical quality is in determining which ones survive (i.e., not much). Building a self-sustaining ecosystem requires a ton of work and a ton of luck. And here I'm still trying to *reduce* the number of languages I need in each analysis pipeline... so even though there are a number of really exciting things about Julia, and its author seems to know what he's doing, I'm still in wait-and-see mode. -- Nathaniel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.16 issue Windows with Mingw32
Nathan Dunfield, 23.04.2012 17:58: > I've encountered the following issue with Cython 0.16 on Windows with > using the Mingw32 compiler (I'm using Python 3.2 here, but I don't think > that's the issue): > > $ python3 setup.py build -c mingw32 > running build > running build_py > running build_ext > skipping 'SnapPy.c' Cython extension (up-to-date) > building 'snappy.SnapPy' extension > c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Iheaders -Iunix_kit > -Iaddl_code -I. -Ipari/pari-2.3.4/include/ -Ipari/pari-2.3.4/include/pari > -Ic:\Python32\include -Ic:\Python32\PC -c SnapPy.c -o > build\temp.win32-3.2\Release\snappy.o > SnapPy.c: In function > `__pyx_f_6snappy_6SnapPy_13Triangulation_build_rep_into_Sn': > SnapPy.c:25187: warning: implicit declaration of function > `fg_get_num_orig_gens' > SnapPy.c:25423: warning: implicit declaration of function > `candidateSn_is_valid' > SnapPy.c:25435: warning: implicit declaration of function > `candidateSn_is_transitive' > SnapPy.c: At top level: > SnapPy.c:76434: error: initializer element is not constant > SnapPy.c:76434: error: (near initialization for > `__pyx_CyFunctionType_type.tp_call') > error: command 'gcc' failed with exit status 1 Hmm, that line basically just says "PyCFunction_Call", which is a function exported by CPython. I wonder why gcc would consider this "not a constant". Could you check if the preprocessor (gcc -E, with all the above includes) also sees that on your side? Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Julialang
On 04/23/2012 08:17 PM, Nathaniel Smith wrote: On Mon, Apr 23, 2012 at 6:09 PM, Dimitri Tcaciuc wrote: I may be misuderstanding the intent here, but here it goes. If the main idea is to be able to call functions that are written in Julia or other languages, I think an effort to create an LLVM backend for Cython would go a long way towards inter-language connections as the one discussed here. It should be possible to take Cython- and Julia- produced LLVM bytecode and assemble it all together, applying whatever bytecode optimizers that are available (eg. SSE vectorization). A big advantage of that approach is that there's no need for one language to know syntax conventions of the other one (or at least not to full extent). Continuing the effort, it should be possible to eliminate the need for writing an intermediate .c/.cpp file if Clang compiler is used, which is also LLVM based. You'd still need some way to translate between the Cython and Julia calling conventions, runtimes, error handling, garbage collection regimes, etc. IIUC, LLVM IR isn't like the CLR -- it doesn't force languages into a common system for these things. Which might be great and worth the effort, I don't know, and don't want to discourage anyone. But there are literally hundreds of new languages designed every year, and a new *successful* language comes along maybe twice in a decade? And one of those recent ones was PHP, which shows you how important pure technical quality is in determining which ones survive (i.e., not much). Building a self-sustaining ecosystem requires a ton of work and a ton of luck. And here I'm still trying to *reduce* the number of languages I need in each analysis pipeline... so even though there are a number of really exciting things about Julia, and its author seems to know what he's doing, I'm still in wait-and-see mode. I'm excited about Julia because it's basically what I'd *like* to program in. My current mode of development for much stuff is Jinja2 or Tempita used for generating C code; Julia would be a real step forward. I recently started a thread on julia-dev, primarily to encourage them to focus on binding to Python and use Python libraries rather than focusing on creating their own libraries (though I wasn't that blunt). The response is positive and I'm hopeful. The thing is, I really hope we've moved beyond CPython in 10 years -- in fact I'd go as far as saying that the reliance on CPython (specifically the lack of a decent JIT) is a real danger for the survival of the scientific Python ecosystem long-term! And I have my doubts about PyPy too (though I'm really happy for Stefan's efforts to bring some sanity with fixing cpyext). If Julia gets into a mode where they bootstrap by piggy-backing on Python's libraries, and gets that working transparently and builds a userbase around that, the next natural step is to implement Python in Julia, with CPython C-API compatability. Which would be great. A very, very, very long shot of course. Dag ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Julialang
Dag Sverre Seljebotn wrote: I'm excited about Julia because it's basically what I'd *like* to program in. My current mode of development for much stuff is Jinja2 or Tempita used for generating C code; Julia would be a real step forward. It looks interesting, but I have a few reservations about it as it stands: * No modules, just one big global namespace. This makes it unsuitable for large projects, IMO. * Multiple dispatch... I have mixed feelings about it. When methods belong to classes, the class serves as a namespace, and as we all know, namespaces are a honking great idea. Putting methods outside of classes throws away one kind of namespace. * One-based indexing? Yuck. I suppose it's what Fortran and Matlab users are familiar with, but it's not the best technical decision, IMO. On the plus side, it does seem to have a very nice and unobtrusive type system. the next natural step is to implement Python in Julia, with CPython C-API compatability. Which would be great. That would indeed be an interesting thing to explore. -- Greg ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Julialang
On 04/24/2012 12:32 AM, Greg Ewing wrote:
Dag Sverre Seljebotn wrote:
I'm excited about Julia because it's basically what I'd *like* to
program in. My current mode of development for much stuff is Jinja2 or
Tempita used for generating C code; Julia would be a real step forward.
It looks interesting, but I have a few reservations about
it as it stands:
* No modules, just one big global namespace. This makes it
unsuitable for large projects, IMO.
As far as I know it seems like namespaces are on their TODO-list. But of
course, that also means it's undecided.
* Multiple dispatch... I have mixed feelings about it. When
methods belong to classes, the class serves as a namespace,
and as we all know, namespaces are a honking great idea.
Putting methods outside of classes throws away one kind of
namespace.
Well, there's still the namespace of the argument type. I think it is
really a syntactic rewrite of
obj->foo(bar)
to
foo(obj, bar)
If Julia gets namespace support then the version ("method") of "foo" to
use is determined by the namespace of obj and bar.
And in Python there's all sorts of problems with who wins the battle
over __add__ and __radd__ and so on (though it's a rather minor point
and not something that by itself merits a new language IMO...).
* One-based indexing? Yuck. I suppose it's what Fortran and
Matlab users are familiar with, but it's not the best
technical decision, IMO.
On the plus side, it does seem to have a very nice and
unobtrusive type system.
the next natural step is to implement Python in Julia, with CPython
C-API compatability. Which would be great.
That would indeed be an interesting thing to explore.
Dag
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Julialang
Greg Ewing, 24.04.2012 00:32: > Dag Sverre Seljebotn wrote: >> I'm excited about Julia because it's basically what I'd *like* to program >> in. My current mode of development for much stuff is Jinja2 or Tempita >> used for generating C code; Julia would be a real step forward. > > It looks interesting, but I have a few reservations about > it as it stands: > > * No modules, just one big global namespace. This makes it > unsuitable for large projects, IMO. > > * Multiple dispatch... I have mixed feelings about it. When > methods belong to classes, the class serves as a namespace, > and as we all know, namespaces are a honking great idea. > Putting methods outside of classes throws away one kind of > namespace. > > * One-based indexing? Yuck. I suppose it's what Fortran and > Matlab users are familiar with, but it's not the best > technical decision, IMO. > > On the plus side, it does seem to have a very nice and > unobtrusive type system. I totally agree. They might have been inspired by Lua and tried to make the type system more usable. There are/were many languages that started off with the design goal of being simple, beautiful and avoiding "all that overhead", before they got to the point of becoming usable and consequently quite complex. Even if Julia stays a niche language (and there is nothing that indicates that it won't be so), I think Dag is right in that it is an interesting niche for a certain user group (whether that is enough for it to prevail, well...). It could certainly make a nice addition to CPython. Whether reimplementing Python in it is a good idea and worth the effort - well, there are lots of incomplete special-purpose Python-like language implementations already, so why not have one more. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Julialang
Dag Sverre Seljebotn wrote: Well, there's still the namespace of the argument type. I think it is really a syntactic rewrite of obj->foo(bar) to foo(obj, bar) This is where I disagree. It's *not* just a syntactic rewrite, it's a lot more than that. With a Python method, I have a fairly good idea of where to start looking for a definition, documentation, etc. Or if it's a stand-alone function, I can follow the imports and find out which module it's defined in. But with generic functions, the implementation for the particular combination of argument types concerned could be *anywhere*, even in a file that I haven't explicitly imported myself. It's monkeypatching on steroids. I acknowledge that multiple dispatch is very powerful and lets you do all sorts of wonderful things. But that power comes at the expense of some features that I particularly value about Python's namespace system. And in Python there's all sorts of problems with who wins the battle over __add__ and __radd__ I think Python's solution to this is rather good, actually. It seems to work quite well in practice. And multiple dispatch systems have all the same problems when the "best" match to the argument types is ambiguous, so it's not as if multimethods are a magic solution to this. -- Greg ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
