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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4