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