"Ruby does it this way and people like it" isn't an argument that will work. You can accomplish the same things in Python with an extra line of overhead.
If you want to get this past python-dev you'll need to explain the benefits, here's a start:
1) Lower cognitive load: Users can understand blocks but the extra naming/reference is one too many things for their brain stack to handle.
2) More descriptive: with blocks the first line says "I'm about to define a function for use with X" instead of the existing way which says "I'm defining a function. Now I'm using that function with X."
3) Show me: take a chunk of an existing project (stdlib is best) and rewrite it with the proposed block syntax. You get to cherry pick the example so if the new version doesn't read much cleaner than the old version maybe the idea isn't so hot.
I'm -1 on the idea but if you want to change my mind you have to make an argument that doesn't start with "In Ruby..."
Anyway, I'm kind of sad that people seem to want a straight copy of Ruby's blocks. I'd prefer syntax that allowed passing more than one block to a function, like the C-like syntax I proposed here:
http://www.hackerdashery.com/2006/10/code-blocks-and-c-like-...
I was wondering if the one-block limit bothered anyone else. Maybe something like Haskell's where clause:
map(foo, pairs) where:
pairs = [(0,1), (20, 10), (30, 10)]
def foo(pair):
a = pair[1] * 2
b = pair[0] * a
return (b, a)
I'm not terribly familiar with Python's grammar, so it might be difficult to introduce a closing where-clause without ambiguity. In that case, it might be useful to use a do clause as well:
do:
<statements>
where:
<statements>
Another alternative would be to simply create a real function literal syntax (i.e., lambda that doesn't suck).
Actually 340 was withdrawn in favor of the 'with' statement, so blocks haven't been ruled out, as far as I can see. However, it will have to be Pythonic (no braces of block terminators) and well thought out.
Ruby style blocks would have made the with_statement (and a bunch of other stuff) obsolete. In fact most stuff can be implemented from blocks (like decorators and generators) and not the other way around.
Obviously no reasonable person wants Python to be identical to Ruby, since those who like Ruby better can go use it. But Python has over its lifetime incorporated new ideas from other languages. Giving substantive reasons why you don't like this particular idea would be a lot more interesting than just registering your distaste for it.
This has been up so many times. It's not happening, live with it. Python "lambdas" can do most things you need anyway.Normally I don't really find the need for supercomplicated lambdas and you can do if-else in lambda s in Python with the ternary operator, see below:
Don't know what select does but it sounds like filter. So if that works as intended(is the ruby version both returning value and side-effecting?) or not I'm not sure but you probably could make it.
The use is the same, it's just that the definition can now be more than one line of code. It's pretty arbitrary to say "you can have one-line anonymous functions, but for two lines, the function must have a name".
No other language does that, because it makes very little sense. This proposal will make Python behave more like every other programming language that supports anonymous functions.
I've had a little bit of wine, so you'll have to pardon my honesty: I think Python is a crap language with a great syntax. I'd rather use C++ when performance is very important, or Haskell, when it's not.
[+] [-] jackdied|17 years ago|reply
If you want to get this past python-dev you'll need to explain the benefits, here's a start:
1) Lower cognitive load: Users can understand blocks but the extra naming/reference is one too many things for their brain stack to handle.
2) More descriptive: with blocks the first line says "I'm about to define a function for use with X" instead of the existing way which says "I'm defining a function. Now I'm using that function with X."
3) Show me: take a chunk of an existing project (stdlib is best) and rewrite it with the proposed block syntax. You get to cherry pick the example so if the new version doesn't read much cleaner than the old version maybe the idea isn't so hot.
I'm -1 on the idea but if you want to change my mind you have to make an argument that doesn't start with "In Ruby..."
[+] [-] tav|17 years ago|reply
[+] [-] inklesspen|17 years ago|reply
Besides, it's not the Python style to have function calls without the () syntax.
I think you could do something interesting with decorators, though.
[+] [-] russell|17 years ago|reply
Sorry about the url. Tinyurl couldnt digest it. :-)
I think 'there' could have good traction, but nobody has made a PEP (see python.org). If a proposal doesnt have a champion, it isn't going anywhere.
[+] [-] sah|17 years ago|reply
Anyway, I'm kind of sad that people seem to want a straight copy of Ruby's blocks. I'd prefer syntax that allowed passing more than one block to a function, like the C-like syntax I proposed here: http://www.hackerdashery.com/2006/10/code-blocks-and-c-like-...
[+] [-] Jebdm|17 years ago|reply
[+] [-] russell|17 years ago|reply
[+] [-] tav|17 years ago|reply
[+] [-] anamax|17 years ago|reply
Once you understand that, a lot of the "issues" go away.
[+] [-] relme|17 years ago|reply
[+] [-] tdavis|17 years ago|reply
[+] [-] sah|17 years ago|reply
[+] [-] globalrev|17 years ago|reply
####### def throwaway_function(emp): if emp.salary > developer.salary: return fireEmployee(emp) else: return extendContract(emp)
employees.select(throwaway_function) ######
Python lambda: filter(lambda emp: fireEmployee(emp) if emp.salary > developer.salary else extendContract(emp), employees)
Don't know what select does but it sounds like filter. So if that works as intended(is the ruby version both returning value and side-effecting?) or not I'm not sure but you probably could make it.
[+] [-] lacker|17 years ago|reply
[+] [-] tav|17 years ago|reply
[+] [-] aceofspades19|17 years ago|reply
[+] [-] jrockway|17 years ago|reply
No other language does that, because it makes very little sense. This proposal will make Python behave more like every other programming language that supports anonymous functions.
[+] [-] SapphireSun|17 years ago|reply
[+] [-] gaius|17 years ago|reply
[+] [-] critic|17 years ago|reply