[Guido van Rossum]
> Just throwing out some thoughts.
>
> There are several possible use cases for new customizable syntax:
>
> - resource allocation (lock.acquire(); try-finally: lock.release())
>
> - defining functions with special treatment (e.g. classmethods,
> properties)
>
> - defining class-like things (e.g. Zope-style interface declarations)
With that last I assume (or hope) that you're trying to subsume what Jim
Fulton was trying to get at in the "Context binding" thread on the Zope list
a few weeks back (which was itself a repeat of an earlier proposal nobody
responded to at the time -- wanted to, but couldn't make time).
> Maybe it's possible to invent a new statement that covers all of
> these? Certainly a macro system should support doing all these
> easily...
I'd like to go back to Jim's original statement of "the problem" (since it
was more helpful than the proposed solution <wink>):
It would be cool, IMO, if people could define their own
block statements in Python.
I think all the use cases you had in mind fit this too, and it's not
vacuous. For example, it rules out "expression macros", like trying to
cater to defining
x implies y
as expanding to
((not (x)) or (y))
Python's better off without anything like that; new block statements aren't
nearly as disgusting <wink>.
one-sickly-step-at-a-time-ly y'rs - tim
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