From: Skip Montanaro <skip@pobox.com> > > (Tom, you gave up way too easily! Hint for the next time: post to > comp.lang.python instead of the python-dev mailing list. There are at least > 20 or 30 people there who will gladly provide positive support for just > about any language change proposal. The lifetime of proposals posted there > thus tends to be correspondingly much longer than those that originate > here. :-) unfair <wink>. IMO it is just that CL,Dylan and Common Lisp did not get macros overnight. And btw the respective communities have dissenting opinion about macros. So maybe a starting point for a discussion would be a bunch of tentative but concrete implementation of macros, that tries to be pythonic. Scheme is not pythonic <wink>. > > But, since Tom has given up more or less and Tim has diverted the thread to > his own nefarious uses, I will note that the try/finally lock idiom does get > tedious. Using the same argument as "if Guido wanted 'unless' he'd add it > to the language", I think that if this is important enough, it's important > enough to add to the language. I think a "lock" keyword would be > appropriate: > > lock somelock: > do stuff > > The biggest problem I found with the try/finally lock idiom was that "do > stuff" can tend to get long, so the vertical distance between lock.acquire() > and lock.release() can be substantial. a lock statement/clause/macro would > remove the need to worry about that visual distance. seems nevertheless ad-hoc <wink>. Then maybe useres ini,consume: stuff => ini() try: stuff finally: consume() useres somelock.acquire,somelock.release: stuff <wink> x 2 regards.
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