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

[Moshe Zadka]

On Thu, 27 Jul 2000, Vladimir Marangozov wrote:

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

I agree.

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

Can you elaborate on that? At least the numeric typo error makes this
a guessing job <wink>

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

Personally, I don't. If there is no memory, Python should quit gracefully
(throwing MemoryError exception is fine by me -- core dumping is not)

>    Python core dumps on several known situations, notably those that
>    involve recursive calls.

This doesn't have to do with low-memory conditions, this is because Python
uses the C stack. Finally putting in stackless will make this the same
as low-memory conditions, and we already covered that <wink -- but perhaps
that will be stackless's killer feature)

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

I don't. It's in the "useful, but not necessary". What *is* necessary 
is a good IDE, with integrated help. IDLE is being worked on, as is
ActiveState's Komodo and my Bwian vapourware. 

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

I totally agree -- and even more so. I hope to have the time to work on
serious Python optimization, notable things like method caching,
optimizing built-in function calls, 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.

Ummm.....most of unicode *is* optional: the codec package and various
unicode modules are optional. u"" strings have new syntax, which is 
really needed.

> I hope that python-dev will eventually realize that all these issues are
> more important that augmented assignment

I completely agree.

> zip()

zip() and friends (irange, product) have been suggested to live in 
a seperate Python module, hence completely optional. If you're talking
about time usage, well, it's not your time <wink>

--
Moshe Zadka <moshez@math.huji.ac.il>
There is no IGLU cabal.
http://advogato.org/person/moshez