Thoughts about extensions to the Python language

[Carlos Ribeiro]

At 17:37 14/03/01 -0500, jeremy at alum.mit.edu wrote:
>You seem to have a very abstract concern about the speed of
>develpoment and the fact that we write design documents that describe
>changes to the language.  I voted for "just right" in the poll, so we
>probably don't agree on the former.  As for the latter, what
>alternative is there?  Make changes to the language without
>describing the changes in advance? <wink>  I don't expect Guido's good
>judgement is impaired by having written proposals to consider.  He's
>been known to reject PEPs.

  Ok, my concern about written proposals was mostly a joke. And no, I dont 
have any alternative. However, from my practical experience, I *do* believe 
that is fairly easy to to be impressed by junk ideas just because they are 
well written and documented. You'd better keep your wits sharp.

Some of the proposal dont make much sense to me. Someone else (I'm afraid 
that it was Guido :-) has just pointed out that improving the library is 
not as much fun as trying to improve the language. Ok, so lets try to find 
a generic approach to make language *easily* extensible. I see some areas 
where this could be done.

1) This topic has been beaten to death, but anyway... the "import from 
future" problem should be solved by a more generic and natural approach. 
There is a possibility that some code may break, but this is a 
"transitional" effect, and nothing stops people to keep using older 
versions of Python in this case. On the other side, the extension of the 
meaning of the import directive would be definitive, and would affect all 
code written from now on. We could:

- why not a generic pragma or directive keyword? a lot of people suggested 
doing that, but I dont see any reason not to do it, except perhaps the 
possibility of breaking code.
- why not extend the Python compiler itself with Python? We already have 
the __main__ symbol for the top-level script, why not a __compiler__ symbol?

(please take this as suggestions only - I could be the one making junk 
proposals here :-)

2) One area that I would like to see more discussion is about the 
implementation of a generic notation for new fundamental types. Python does 
a nice job on fundamental types - we have strings, list, sequences, 
mappings. And the syntax is clean, which makes Python so easy to learn. The 
problem is that all the reasonable delimiters were spent in this proccess, 
and any proposal to extend or create new fundamental types has to use a 
kind of kludge. For instance this already happened with the Unicode string. 
Why not think of a generic approach for that?


Carlos Ribeiro
carribeiro at yahoo.com
cribeiro at mail.inet.com.br


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com