Some "pythonic" suggestions for Python

[Carl Banks]

On Nov 9, 9:52 am, Frank Samuelson
<newsdump0711.12.cud... at neverbox.com> wrote:
> Bruno Desthuilliers wrote:
> > Yes. Python deliberately choosed to be a statement-based language.
>
> >> Why not use the = operator like most other assignments?
>
> > This dead horse has been beaten to hell and back.
>
> > Note that as far as I'm concerned, I may like an expression-based
> > Python-inspired language. But this is another story.
>
> My bad!  In my rush I forgot that python requires the return statements.
> You people think I'm trying to push lisp, which I am not. (Apparently
> many people do, because you are rather skittish.)
> In S the value of the last executed statement of a function is the
> returned value of the function by default, if there is no return() function.
> It is very convenient for writing really small functions.  But skip that for now.
>
> foo = function(x,y) {  # S language
>          if (x>2) return(x+y*2)
>          x+y
>
> }
>
> foo = func(x,y):          # My suggested python syntax (Improved!)
>          if x>2: return x+y*2
>          return x+y
>
> # put the function object in the code wherever you want it.
> bb= bar( a,b, func(x,y): x=x*2 ; b=4 ; return x*b+y )
>
> It still is a statement language.  The statement is an explicit
> assignment using the "=" like most other assignments.  "Def" and "lambda"
> are silly.  Assign names to function objects names the same way
> you assign them to any other object.  Call a duck a duck.


If you do that, then when your pure, duck-called function results in a
raised exception, your stack trace will look like this:

File "xxx.py", line yy

instead of the much more helpful

File "xxx.py", line yy, in foo

because the function will be nameless.  For me, this is more than
enough to justify a special assignment syntax for function.  (In fact,
I'd say there are at least three reasons that are good enough by
themselves, but this'll do for now.)

More generally: your proposals are not "Pythonic", and will get very
little support in the Python community, because the mentality "If it's
good for X, it's good for Y" isn't Pythonic.  Python is about a
practical balance of many concerns, and all decisions are considered
from many viewpoints.  An argument for consistency for the sake of
keeping things simple is only one of many factors considered.


Carl Banks