Some "pythonic" suggestions for Python

[Diez B. Roggisch]

Frank Samuelson schrieb:
> I love Python, and it is one of my 2 favorite
> languages.  I would suggest that Python steal some
> aspects of the S language.
> 
> -------------------------------------------------------
> 1. Currently in Python
> def  foo(x,y): ...
> assigns the name foo to a function object.  Is this pythonic?
> 
> Why not use the = operator like most other assignments?
> Define function objects as "function"s, let users put them where
> they want to.  Get rid of lambda, get rid of def, only use =
> for assignments.
> 
> foo = function(x,y) x+y*2   # Example S language code
> bar = foo
> bar(3,4)
> m = lapply( s, foo )
> bb = lapply(s, function(t) t[3]*4 )
> 
> foo = func(x,y): x+y*2   # Possible python code
> bar = foo
> bar(3,4)
> m = barf( s, foo )
> bb = barf(s, func(t): t[3]*4 )

The whole purpose being that you have statements in lambdas - something 
that has been proposed and rejected about a bazillion times. Read the 
archives.


> -------------------------------------------------------
> 2. Allow sequences to be indices:
>  >>> s=["hello", 6, 33, "none"]
>  >>> x= [1,3]
>  >>> [ s[y] for y in x]     # Current verbose version
> [6, 'none']
>  >>> s[x]                   # Simpler, clearer, more productive
> 
> To quote a poster at http://www.thescripts.com/forum/thread22741.html,
> "While we are at it, I also don't understand why sequences can't be
> used as indices. Why not, say, l[[2,3]] or l[(2, 3)]? Why a special
> slice concept? "  Isn't that unpythonic?


What has the one to do with the other? Slices are use- and powerful.

I'm not against this, but then what you call "verbose" is very concise 
in my book - and concise enough to be used when the need arises, which 
is seldom enough.

> --------------------------------------------------------
> 3. When I first started using python, I frequently used
> map, because I didn't want to have to learn the
> additional syntax of list comprehensions, which
> appeared very nonstructured.
> 
> # Is this readable?
> b= [x+y for x in vec1 if x>0 for y in vec2 if y>x ]


Yes, I think it is readable. You could ask the same for the 
parenthesis-overload in lisp - after all, it's just what you are 
accustomed to.


> Perhaps a list comprehension syntax more like the rest
> of python. "for" could return a list given by continue
> arguments:
> 
> b= for x in vec1 :
>       if (x>0):  continue     # "returns" nothing
>       continue for y in vec2:
>          if (x>y): continue(x+y)
> 
> Note that my code would actually return a list of lists
> rather than a single list like the list comprehension.
> More structured syntax opens the door to having much
> more complicated, yet still comprehensible (thus more
> pythonic), list comprehensions.

So it is _not_ a list comprehension, but all it does is to create 
implicit lists?

I prefer list-comps. They allow for nested as well as flattened structures:

b= [x+y for x in vec1 if x>0 for y in vec2 if y>x ]
b= [[x+y  for y in vec2 if y>x  ] for x in vec1 if x>0]

Overall, I'd say you don't stand a chance that your proposals will be 
adopted. They are minor variations of things that have been proposed & 
rejected too often to count - and to be honest: it get's tiresome 
beating the same old horses again and again...

Diez