Some "pythonic" suggestions for Python

[Bruno Desthuilliers]

Frank Samuelson a écrit :
> 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.

Did I mention Lisp ??? No need to go lispish for this - Javascript 
already does what you want here. FWIW, I was somewhat thinking out loud, 
and I guess I thought of Javascript's use of anonymous functions, then 
switched to Ruby (and it's code blocks), which took me to 
expression-based languages. That's all.

> (Apparently
> many people do, because you are rather skittish.)

I don't get the point here.

> In S the value of the last executed statement of a function is the
> returned value of the function by default,

Which is what expression-based languages usually do - cf Ruby and most 
functional languages.

> if there is no return() 
> function.

Actually, in most languages, it's a statement !-)

> It is very convenient for writing really small functions.

For really small functions, Python has lambda - which actually work that 
way.

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

bb = bar(a, b, func(x,y):
   for x in y:
     if x > 10:
       do_something_with(x)
     return y[-1] * 42

ho, wait, I have a couple keyword args to pass to bar too... How should 
I do ? add a comma after the return statement ???

Franck, believe us, *this has been beaten to hell and back*. The point 
is not that full anonymous functions are a bad thing (I personally use 
them a lot in Javascript), but that it just doesn't fit within Python, 
and that the necessary modifications would yield a mostly different 
language. Perhaps a pretty good one, but not Python anymore. You see, I 
don't necessarily share all Python's design choices, and I'm well aware 
of some restrictions they impose. But day in, day out, it happens that 
these choices are mostly coherent, and that the resulting language 
offers a (IMHO) great balance between simplicity and power. 
Non-programmers can (and do) use it, C programmers can (and do) use it, 
Java programmers can (and do) use it, Lisp programmers can (and do) use 
it, etc, etc, etc.

> While I'm at it, classes are objects too.  Assign names to them the
> same way you assign names to _any_ other object: "="

Same problem. Note that in both cases, you already *can* build functions 
and classes that way - as you say, they are objects, and both the def 
and class statements are somewhat syntactic sugar. The only point is 
that, to instanciate a function, you have more to do:

Help on class function in module __builtin__:

class function(object)
  |  function(code, globals[, name[, argdefs[, closure]]])
  |
  |  Create a function object from a code object and a dictionary.
  |  The optional name string overrides the name from the code object.
  |  The optional argdefs tuple specifies the default argument values.
  |  The optional closure tuple supplies the bindings for free variables


>> 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",

Actually, it's: "there should be one - and preferably only one - obvious 
way to do it". List comps are the obvious way for simple list 
operations, and for loops are the obvious way for complex operations. If 
you're in for Python Zen quotes, here are some others:
"""
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
"""


> shouldn't they be removed?  My point is that if you are going to
> have them, why make some new unstructured syntax for them?

Because there's already a (well-known) structured syntax for the cases 
that are too complex to fit a single, simple expression. It's a question 
of balance between purity, readability, and practicallity.