Production Pyrex Re: [Pyrex] Pyrex at Pycon

[Phillip J. Eby]

At 06:02 PM 3/30/04 -0800, Paul Prescod wrote:
>Greg Ewing wrote:
>
>>
>>>If you feel that Pyrex is an experiment and others want to use it in 
>>>production code (e.g. Chandler) would you mind if they took your 
>>>experiments and made a production-ready branch that had stable 
>>>interfaces, test cases, optimizations and public repositories of bugs, 
>>>patches and code.
>>
>>They're quite welcome to do that!
>
>Are there other people out there interested in using a QAed, optimized 
>version of Pyrex? Would you submit test cases, patches, extensions etc. to 
>a branched sibling of Pyrex?

A definite maybe.  :)

I have competing concerns...  On the one hand, there are definitely 
features I'd like to see and would be willing to code, like interning of 
identifier strings and pre-objectifying of non-identifier strings, 
PyObj_GetAttr instead of PyObj_GetAttrString, and so on.

But on the other hand, I'd really like to see the sorts of things Greg has 
talked about doing in future releases.  If this is a fork, it's not going 
to have what he does, unless people make it a point to keep the fork in 
sync.  And what happens when the fork and Greg diverge on matters of opinion?

I think I'd want to see Greg (or somebody) as a Pyrex BDFL (chief cook?) to 
decree what the *language* is, so that even if the two implementations take 
different approaches, they'll still be interoperable.