Make 'def' and 'class' usable within expressions

Joe Mason joe at
Thu Mar 25 20:39:08 CET 2004

In article <mailman.401.1080225693.742.python-list at>, Shane Hathaway wrote:
>>     # Define a staticmethod named 'now'.
>>     class datetime:
>>         now = staticmethod(def):
>>             ticks = time.time()
>>             return datetime(ticks)
> Today, this would be written as:
>      class datetime:
>          def now():
>              ticks = time.time()
>              return datetime(ticks)
>          now = staticmethod(now)

Note that it would need to be "now = staticmethod(def()):", I think, to
allow parameters.

I like this syntax in general (hence why I hope to have some excuse to
use Haskell or an ML someday) but it doesn't seem quite Pythonic.
If "name = def(params): body" and "def name(params): body" are both allowed, we have two
ways to define functions (plus lambda, although this would make it
obsolete, I believe).

So would "now = def then():" be allowed, setting the function name
attribute to then but making it callable only as now()?  Or would this
not allow naming functions at all?  The latter would make the
multimethods from the other thread hard to implement.  (Then again, in
this view of the world functions don't have names, they just happen to
be callable by named variables, so multimethods indexed by name wouldn't
make any sense anyway.)

Personally, I wouldn't mind at all if this form became the standard, and
the original form retired.  But I think if you don't do both, you'd
start to get a vaguely schizophrenic language.


More information about the Python-list mailing list