[Pyrex] Just some thoughts

[Phil Frost]

On Tue, Apr 18, 2006 at 08:41:58PM +0200, Tomasz Primke wrote:
> For last few days I've been using Pyrex very extensively. Therefore I have
> gained some experience with this wonderful tool. I have also become more
> familiar with its limitations.
> 
> I'd like to share some thoughs about Pyrex - some sugestions, that - from my
> POV - could make Pyrex even better.
> 
> 
> 1) The syntax of integer-loops: I find it too long. In my opinion, instead 
> of writing:
> 
> for i from lower_bound <= i < upper_bound:
>   ...
> 
> it would be better (and easier, faster, more convenient) to write just:
> 
> for i from lower_bound <= upper_bound:
>   ...
> 
> Rationale:
>   a) Why on Earth the name of the loop variable should be written twice? I
>      find it something, that wastes programmer's time.
>   b) (I think) My proposal is a simpler one, than the current Pyrex syntax. 
> A
>      simpler syntax is easier to learn and to memorize.
>   c) (I think) My proposal is a shorter one, that the current Pyrex syntax. 
> It
>      is easier and faster to write less code, that do the same things.

I suspect that the "foo <= i < bar" syntax was chosen because it makes
sense to someone who deals with math. A syntax with simply "foo < bar"
just says "foo is less than bar", which has nothing to do with i, which
is what this for loop is all about. Your proposed syntax also does not
provide a way to express all the possibilities the pyrex syntax offers.
Consider, how would you write:

  foo < i < bar
  foo < i <= bar
  foo > i >= bar

"Less code that does the same thing" is a common thing for programmers
to shout, but one of the nice things of Python, and by analogy, Pyrex,
is that the language is designed with the assumption that code is read
more than it is written, thus it is better to be a little more verbose
if it is easier to read. This is why Python does not support
"while foo = bar" or "bleh = ++grr".

> 2) I think that Pyrex should offer some low-level memory managment routines. 
> I think of sizeof operator, as well as the C standard *alloc and free 
> functions. It would be also nice to have something like the g_new macro 
> known from the GLib library.
>
> [snip]

Well, you can get malloc with something (untested) like this:

cdef extern from "stdlib.h":
    ctypedef unsigned size_t
    void *malloc(size_t size)

Pyrex already supports sizeof. You have to use it as a function though;
the parenthesis are not optional as they are in C.

> 3) It would be great to have some easy way to auto-create Python wrappers 
> for chosen C functions and/or methods.
>
> [snip]
>
> cdef void some_c_func( ... ):
>   ...
> 
> def python_func( ... ):
>   some_c_func( ... )
>
> [snip]

I don't think there is any need for this. If you want to use your
functions from python, define them with "def" and not "cdef". When
manipulating C types in a function (of either kind), Pyrex outputs the
most optimal code to do it. "cdef" doesn't change anything about how the
code is generated; it only changes whether or not this function is
visible from Python.