Some "pythonic" suggestions for Python

[Chris Mellon]

On Nov 9, 2007 8:52 AM, Frank Samuelson
<newsdump0711.12.cudgel 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.
>
> While I'm at it, classes are objects too.  Assign names to them the
> same way you assign names to _any_ other object: "="
>
> MyClass= class(inhereted):
>      attributes
>      functions
>      whatever
>
> x=MyClass()  # an object of the above class.
>
>
>
> > The Pythonic way to write "more complicated yet still comprehensible
> > list comprehensions" is to not use list comprehensions.
> >
> > b = []
> > for x in vec1:
> >   if x > 0:
> >     for y in vec2:
> >       if y > x:
> >         b.append(x + y)
> >
>
> You have just demonstrated that list comprehensions are not really
> necessary at all.  So given the "one clear way of doing things",
> shouldn't they be removed?  My point is that if you are going to
> have them, why make some new unstructured syntax for them?
>

There are at least 2 posts a month by someone who decides that they
want to re-wire Python syntax. Usually it's because of some particular
idiom they're used to in another language, in other cases it's because
they've got some particular issue with "consistency". The ideas are
*never* fully thought out or materialized, and they invariably invite
scorn from the user community. The poster is almost always a Python
beginner (I don't know if thats true in your case or not).

Arbitrary changes to syntax are never going to fly. It's a lost cause.
If you can't handle Python without your pet changes, fork it and write
your own version and let the marketplace of ideas decide if its
useful.