On Thu, 08 Nov 2007 15:00:03 -0500, Frank Samuelson wrote:
> 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?
Why? What benefit do you gain?
> 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.
So you remove two keywords. That's a plus. But then you have to create a
WHOLE lot more syntax to support it, and that's about a thousand minuses.
Python has very little syntax, and the designers are (rightly) very
resistant to adding more.
> foo = function(x,y) x+y*2 # Example S language code
This would currently be a syntax error, hence the need for new syntax.
Also, function() couldn't be a normal type, or even a built-in function,
because it has to have special syntax:
name = function(*argument_list) expression
It's also not clear how you expect this to work with anything more
complex than a single expression. How do you handle statements and
multiple returns?
def foo(x, y):
L = []
try:
if x[y] % 2:
print x, y
return y
return x[y]
except:
return None
> bar = foo
But you can still do this with Python:
def foo(x, y):
return x+y*2
bar = foo
> 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']
I don't especially call it verbose.
> >>> s[x] # Simpler, clearer, more productive
It's certainly smaller.
But the fatal objection to this is that it is a special case for a very
limited benefit: saving half a dozen characters. List comprehensions are
very flexible:
[float(s[3*i % 2]) for i in x if 3 <= i < 12] # for example...
Your proposal doesn't have anywhere near that flexibility. It simply
duplicates perhaps the most trivial list comp [s[y] for y in x], just to
save a dozen or so characters. Python doesn't treat terseness as that big
a virtue.
Besides, if you want this behaviour, you can add it yourself:
class mylist(list):
# Untested!
def __getitem__(self, index):
if type(index) is list:
return [self[i] for i in index]
return super(mylist, self).__getitem__(index)
list = mylist
The only difference is you have to write:
s = list([1,2,3])
instead of s = [1,2,3].
> 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?
But can't you see that the suggestion to use sequences as replacements
for slices is completely incompatible with your suggestion above?
seq = range(10)
Would you expect seq[[2,6]] to do an index lookup, as you suggested
originally, or a slice? In the first case, it would return [2, 6], but in
the second, it would return [2, 3, 4, 5].
If sequence indices are slices, what does an index of [1, 2, 3, 4] mean?
> 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.
It is a slightly more verbose form of standard mathematical set notation.
In case it comes out wrong, the symbol ϵ is supposed to be the symbol for
"element".
"the set of 3x+1 such that x is in (1, 2, 3) if x is odd"
{ 3x+1 : x ϵ (1, 2, 3) if x%2 }
becomes the list comprehension:
[ 3*x+1 for x in (1, 2, 3) if x%2 ]
> # Is this readable?
> b= [x+y for x in vec1 if x>0 for y in vec2 if y>x ]
It is probably pushing the boundaries of how readable a list comp can get
before it should be refactored, but it hasn't crossed over into
unreadability.
> Perhaps a list comprehension syntax more like the rest of python.
I think the great majority Python folks find the list comprehension
syntax to be one of the MOST Pythonic features, not the least.
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
