Guido van Rossum wrote: > There's also the tension between making the language simpler (to > learn) and making programs simpler (to read). For example, *if* (and > that's still a very big if) we were to add a language feature that > would let you write > > synchronized(lock): > BLOCK > > instead of > > lock.aqcuire() > try: > BLOCK > finally: > lock.release() > > I assure you that this makes programs that use locks more readable, > which reduces maintenance costs down the road. But at the same time > we can't hope to reduce every idiom to a single statement, and we must > be careful not to destroy the language by adding too many "neat > tricks". I think you're getting this wrong: By introducing meta-constructs like the thunk idea to raise the expressiveness of random program blocks you do make the program simpler to read, but certainly not easier to comprehend. The reason is that arbitrary code gets hidden from the user in a way which makes it hard to actually follow the flow of commands. The above lock example is perfect for this: the try:finally: approach is clear and explicit whereas the synchronized(lock): block introduces a layer of abstraction that is not easy to comprehend: because the flow of control is not obvious anymore and because it is hidden in some definition of synchronized() which the maintainer will have to look up somewhere (where somewhere could be inside some .zip archive holding the great new toolbox some geek developer which has long left the company found cool to use... :-/). We have already introduced such a meta-contruct feature in a few places, e.g. importers and meta-classes... both are hardly ever used and that's good, because understanding, maintaining and possibly debugging these is a nightmare for much the same reason that thunks are. Now, we're lucky since meta-classes or writing importers is not all that easy. With thunks the situation will be much like giving macros to Python programmers: you'll see a proliferation of new meta-constructs in all kinds of programs and in the end lose the maintainability argument which is still one of the strongest ones for using Python in the first place. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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