I finally got around to watching the Python keynote recommended by Steve. Two thirds of the “things we have that other people don’t have” is Python finally catching up with Perl features from 1995 and they were in other languages more than 10 years before that (is that ignorance or the Blub effect?). And we already have the rest in various libraries.
Oh well…
A Curious Programmer 
Just watched the video. It would be interesting to present the perl solutions to the snippets presented in the video. IMHO there are some nicenesses in there. And most of them don’t need the installation of any add on package. “Batteries included” is a big plus, because you don’t need to think about configuration management as long as you can stick to the standard libraries.
So, I think, python has its strengths.
Best regards
Perl programmer
Doesn’t have time to watch the video ATM, care to elaborate the points?
Steve listed the features they think are unique here
At one point he’s talking pretty much about Moose style roles.
Christian points out that decorators are simply method modifiers and due to limitations in Python itself, can’t be implemented directly in the language.
The examples he gives of some of the other stuff map trivially to map …
etc.
Googling for generators in perl, points to limitations in the perl versions that aren’t present in python. Could be that I’ve been blubbing here. I’d need to take a closer look.
>Christian points out that decorators are simply method modifiers and due to limitations in Python itself, can’t be implemented directly in the language.
Can you explain this point to the non-Perlistas? Decorators can modify functions or classes or methods and they are “implemented directly in the language” if by that you mean I write decorators in Python…
Simeon, Jared, Christian, et. al: so we’re all on the same page, here is what you would have to do to modifiy a function in Python if you didn’t have decorators:
def decorate(func, adj):
def f(*args, **kwargs):
print(“I will now run the {} function {}.”.format(adj, func.__name__))
res = func(args, kwargs)
return f
def foo(args, kwargs):
for a in args:
print(a)
foo = decorate(foo, “fine”)
foo(“woof”, “snark”)
This prints:
I will now run the fine function foo.
woof
snark
As you can see, Python is perfectly able to modify a function with another function. Decorators buy two things: 1) you don’t have to say “def foo” followed by “foo =”, and 2) you don’t have to pass both the function to modify AND any arguments to the modifier when you modify the function.
Otherwise, it’s all the same thing. This is why Mr. Hettinger, in the video we’ve all apparently say through now, says that his original objection to decorators was that they were purely sugar. They do nothing but improve the notation–no added functionality at all.
The thing Perl programmers seem to overlook about Python is that, while it doesn’t permit multi-line anonymous subs, and it doesn’t have block scope, it DOES allow nested, lexically scoped functions, and it lets you pass them around easily and call them with one simple, consistent syntax (i.e. put parens after it). This buys you back a lot. (Just to be clear, f, the nested function above, is not directly callable outside of decorate()–it’s out of scope.)
(I sure hope this formats nicely and that it makes sense to somebody.)
I was afraid of that. You’ll have to intuit the indentation in the code, I’m afraid.
Steve T – indentation fixed, hopefully.
Actually steve – I’d argue that what you explained is a decorator. The @decorate syntax is just syntactic sugar. And I went off and read about nested functions (or the lack thereof) in Perl and understand why limited lambda seems like a crippling blow to Perlistas.
All that to say that (if I them understand correctly) Christian’s assertions about decorators and Python are incorrect.