[Pyrex] Just some thoughts

[Tomasz Primke]

> <snip>
> Consider, how would you write:
>
>   foo < i < bar
>   foo < i <= bar
>   foo > i >= bar

I wouldn't write such a things. But I haven't intended to _remove_ (or 
replace) the old syntax, but to add a new one.

(Well, the truth is that I'm an old C-programmer and I'm used to writing 
almost all the loops in such a way, that they can be coded as

	for i from foo <= i < bar: ...

and that was the reason for the syntax, that I have proposed. Although some 
changes are needed in order to remove the neccessity of writing the name of 
the loop variable twice.)

> "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".

In general: my proposals were intended for those, who don't affraid to write 
a little of less-readable (more C-style, less Python-style) code in order 
to gain something, that is impossible to be gained by writing more-readable 
(less C-style, more Python-style) code. That's the way I perceive Pyrex.

But I do realize, that the problem is complex. Needs are various, and there 
are always some trade-offs. I'm looking for a language, that would be easy 
to write in (faster code writing), and Python meets this requirement. But 
Python is sometimes too slow for my needs (experiments, that take months to 
complete) - so I had to go back to pure C. For now, I have rewritten almost 
100% of my C code in Pyrex - and I find it being fast enough, while 
remainig still easy to write (Pyrex is much simpler, than C is).

The main reason for my proposals was my experiences with Pyrex, that made me 
realize, that Pyrex could be even an easier tool to use.

> > 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)

Yeah, it means that I have to write _three_ lines. OK, that's quite simple, 
but what if my needs grow?

I think, that it would be nice to have some additional modules for Pyrex, 
that would do such an activities. Another reason for such a solution is 
that no one should reinvent the wheel every time such a functions are 
needed.

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

Wow! Two questions:

1) Is that information present in Pyrex docs? (If so... Where???)

2) How to use it?

> > 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". (...)

My example is of poor quality, indeed. But the situation is different, when 
you're wrapping C functions in Pyrex in order to use that functions from 
Python.


Best regards,

	Tomek