Make 'def' and 'class' usable within expressions

[Shane Hathaway]

Joe Mason wrote:
> In article <mailman.401.1080225693.742.python-list at python.org>, 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.

I was amazed to discover that list comprehensions are considered 
Pythonic.  They turn two kinds of statements (for and if) into 
expressions and often have to span multiple lines.  Also, when read from 
left to right, they set the iteration variable *after* using it.  This 
started to open my mind to new possiblities.

> 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).

Yes, although list comprehensions provide a second way to generate a 
list.  The difference is procedural vs. functional style.  Making Python 
friendlier to the functional style seems valuable, even if it leads to 
two ways to do some things.

> 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.)

I wouldn't want to allow inline names--they just confuse things.

> 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.

Maybe, but then we'd have to wait for Python 3000 for it to become 
standard. :-)

Shane