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 -- http://mail.python.org/mailman/listinfo/python-list
