Production Pyrex Re: [Pyrex] Pyrex at Pycon

[Paul Prescod]

Greg Ewing wrote:

>...
> 
> I can't honestly make any such commitment, so I will have
> to decline.

Fair enough. I think you for your honesty in addition to your hard work 
on Pyrex and your generosity in sharing it with us. I won't push you to 
accept such a big job but I will disagree with you that Pyrex is any 
more or less of an experiment than any other open source project.

> I wouldn't really feel comfortable being BDFL of someone
> else's project anyway. The leader of that project is entitled
> to decide to follow whatever I decide for Pyrex, but I would
> be loathe to make decisions on anything before I've had a
> chance to try them out in Pyrex myself first.

I guess this is where we disagree. As BDFL of your Pyrex or the 
SourceForge Pyrex or any other open source project, you will make 
mistakes. Probably bad ones. Python's original type system (everything's 
an instance!) was a bad mistake that Guido is still digging himself out 
of. And then there is the division mistake. And the string module. And 
the old scoping... And...

At Pycon, I learned why C has x.y and x->y syntaxes when Pyrex is more 
elegant in only having one. Andrew Koenig says that the reason was that 
in the early days, C did no type checking on the -> operator. You could 
reference a ".foo" member on an integer if you wanted. So instead of 
deciding whether to dereference before accessing the member based on 
type, it asked the user to inform it. The other side effect of this 
typelenessness was that two structs could not have the same member name 
so you had to prefix them.

"Beguiled by the example of PL/I, early C did not tie structure 
point-ers firmly to the structures they pointed to, and permitted 
programmers to write pointer->member almost without regard to the type 
of pointer; such an expression wastaken uncritically as a reference to a 
region of memory designated by the pointer, while the member name 
specified only an offset and a type."

  * 
http://216.239.53.104/search?q=cache:3Jh1QG8Vqu0J:www.lysator.liu.se/c/chistory.ps+c+struct+typeless+member+prefix&hl=en&ie=UTF-8

PHP totally revamped its object structure between 4 and 5.

And I don't think it is any secret how radical the changes between Perl 
4, 5 and 6 were.

And then there is Apache 1 and 2.

And what's left in Linux 2.6 of Linux 1.0?

Remember dynamic scope in Lisp?

I believe that every open source project is an experiment. Every 
non-derivative programming language is an experiment. Every one has tons 
of mistakes that will need to be fixed in the long run. That's why I'm 
not afraid of making a production branch of Pyrex knowing that one day 
we'll look back and think that today's Pyrex is hopelessly naive or 
wrong in some way. The more users Pyrex has, the more feedback you'll 
get and the sooner you'll uncover the mistakes.

 >>In the early days of Python, Guido did 95% of the implementation.
 >
 >
 > Pyrex is still very much in that stage, or even earlier
 > (i.e. 100% implementation). It hasn't even reached version
 > 1.0 yet, remember!

 From my point of view, Pyrex is more mature than Python 1.0,
PHP 1.0, Perl 1.0, C 1.0, Linux 1.0. Given this I don't
know how you will be able to decide when you are ready to
call Pyrex 1.0 and allow other committers. But its your language:
I presume you have some particular feature set in mind for 1.0.

  Paul Prescod