[Python-Dev] was Re: Type inference now simplicity (fwd)

[Vladimir Marangozov]

Moshe Zadka wrote:
> 
> [c.l.py posting deleted]
>
> [Moshe, concluding]
>
> Adding new operators and new syntax will make Python harder to read, and
> harder to learn. I don't want that.
> 

To some extent, I share these feelings. But only to some extent, because
in my eyes it's all a matter of priority. I'll try to elaborate quickly.

Before going into extending Python with features, it's more important
to make the current implementation rock solid, a.k.a "commercial quality".
Presently, this is not really the case and there are already long-standing
known issues that nobody gets excited about. Solving these issues is of
paramount importance for the acceptance of Python in .com software and
generally speaking, its proliferation.

For instance:

1. It is unacceptable that Python blows when a generated code object
   happens to be greater than 2 bytes. If this doesn't get fixed in
   the VM, the compiler should at least check for this overflow and
   refuse to emit the bytecode stream.

2. It is unacceptable that Python leaks memory or happens to core dump,
   without having optional emergency procedures. In this regard, I highly
   value robust (commercial) software which, for example, pops up a window
   on low-memory conditions inviting me to free more mem by quitting other
   apps and gives me the choice to abort the current execution or resume it.
   Python core dumps on several known situations, notably those that
   involve recursive calls.

3. I consider very-high priority the recently discussed integrated help
   system.

4. I consider high priority the opportunity to get more performance in
   terms of system resources: memory & execution speed. And this is why
   I'm working on it as time permits. I find unacceptable the fact that
   there are already some potential improvements on the table which have
   not been considered seriously so far: removal of SET_LINENO, GC + malloc
   integration, etc.

5. I find unwise the whole process of enriching the core, whithout a
   global vision on a modular and extensible core architecture. Adding
   10 additional opcodes for augmented assignment is considered nuts.
   The addition of opcodes for extended calls is already a fact, although
   I never use them and I don't need them. Other enhancements have been
   proposed and they come on top of the system, making it quite heavy.
   And I don't use Unicode - so why it isn't optional? <wink> Because
   there's no a truly modular architecture in place.

I hope that python-dev will eventually realize that all these issues are
more important that augmented assignment, zip(), and other recently
discussed enhancements. IMO, the latter are crap <wink> compared to
the concerns above.

and-I'm-not-talking-about-types-or-Py3K'ly y'rs
-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252