[Python-Dev] Wrappers and keywords

David LeBlanc whisper@oz.net
Thu, 17 Apr 2003 14:03:40 -0700


<snip>
> There have been numerous proposals on what the syntactic sugar should
> look like, which is one reason why no specific solution has been
> implemented yet. Proposals get usually discredit if they require
> introduction of new keywords, like "staticdef". The current favorite
> proposals is to write
>
>    def x() [static]:
>      pass
>
> or perhaps
>
>    def x() [staticmethod]:
>      pass
>
> In that proposal, static(method) would *not* be a keyword, but would
> be an identifier (denoting the same thing that staticmethod currently
> denotes). This syntax nicely extends to
>
>    def x() [threading.synchronized, xmlrpclib.webmethod]:
>      pass

I'm not sure what you're suggesting here semantically...?

> The syntax has the disadvantage of not applying nicely to slots.
>
> Regards,
> Martin

It also has the disadvantage of adding a new syntactical construct to the
language does it not (which seems like more pain than a couple of keywords)?
I don't recall any other place in the language that uses [] as a way to
specify a variable (oops, excepting list comprehensions sort of, and that's
not quite the same thing IMO), especially in that position in a statement?
It seems like it would open the door to uses (abuses?) like:
	class foo [abstract]:
		pass
(although, this particular one might satisfy the group that wants interfaces
in python)

Is there any real difference between what amounts to a reserved constant
identifier (with semantic meaning rather than value) compared to a keyword
statement sentinal? Are there any other language-level uses like that
(reserved constant identifier), or does this introduce something new as
well?

Speaking of slots, is their primary purpose to have classes whose instances
are not morphable? If so, one might default to all classes being
non-morphable by default and having something like:
	class foo [morphable]:
		pass
as identifying those which are (an obviously python-3000 feature if
implemented thusly).

Regards,

Dave LeBlanc
Seattle, WA USA