UserLinux chooses Python as "interpretive language" of choice

[H.V]

Skip Montanaro <skip at pobox.com> wrote in message news:<mailman.374.1071937108.9307.python-list at python.org>...

> 
> Python's design doesn't admit the option of calling functions without the
> parens.  Perl's and Ruby's do.  On the other hand, functions are first-class
> objects in Python.  

And that's a big plus for python. Forget this silliness about calling
functions without parentheses .


>     John> The jihad against the "functional" builtins is a good case in
>     John> point.  The replacements for apply, map and filter seem to be
>     John> adequate, and in the case of list comprehensions, pretty darned
>     John> useful although I think that it's a rather baroque addition to an
>     John> otherwise very clear and comprehensible language.
> 

I love LC's personally. They do replace map and filter completely and
do so in a very attractive manner. Which is not to say that i am
against map and filter but at least a 100% equivalent construct takes
their place (soon to be replaced by gen conprehensions, which is fine
by me as it's again a clean replacement)



> Why do you call it a "jihad"?  Guido has stated on multiple occasions that
> he regretted adding functional constructs to the language.  I still can't
> get to the Python website (have to wait another two hours for my ISP to
> reload its tables), but here's a Google pointer to an HTML-ized version of
> his OSCON 2002 Powerpoint slides:
> 

Given all that Guido has said about functional programming, i'm
starting to wonder why he even made functions first class in python .


>   http://216.239.41.104/search?q=cache:2QztD1KncJgJ:www.python.org/doc/essays/ppt/regrets/PythonRegrets.ppt+OSCON+%22python+regrets%22&hl=en&ie=UTF-8
> 
>     John> On the other hand, claiming that sum() is an adequate replacement
>     John> for reduce() is so silly that it borders on the absurd. 
> 
> No, operationally that's a correct statement.  People have looked at the use
> of reduce() in a number of different contexts.  In all but the rarest of
> cases, reduce() was used to sum a list of numbers.  sum() is a perfectly
> adequate replacement in all but those rare cases and is easier to read as
> well.  As Guido mentioned in the talk I referenced above:
> 
>     reduce()
>         nobody uses it,  few understand it
>         a for loop is clearer & (usually) faster
> 

I think no one even tries to understand the very concept of reducing 
sequence to a single object using a rule . Sum is not a replacement of
this *concept*.
Just what is so wrong with having such a general tool available in a
programming language ? Doesn't it hurt to understand how to use it?


>     John> The only explanation I can come up with for that level of
>     John> absurdity is a desire to get rid of a feature, regardless of what
>     John> it looks like.  In other words, a jihad (holy war.)
> 
If you look at some recent python-dev threads, you'll see comments
similar to "..this should get rid of most of the uses of lambdas, we
only have a few cases left .." .
I just don't understand this burning need of some to make python
conceptually poorer by eliminating the very idea of an anonymous
function.



> No, it's simply not used very much.  Python never has been a very strong
> functional language.  It's always been a very strong object-oriented
> language.  Use it the way it's strongest.
> 

I think Guido should put his money where his mouth is and simply
eliminate functions as first class objects then ! It'd be a clear and
definitive way of saying that he doesn't like functional programming.
Object oriented purists probably wouldn't care since they probably
never use functions in that way.
It'd also be a great relief for all those who find the idea of
functions being passed around "hopelessly hard, too complex, byzantine
because i prefer 36 nested for loops with breaks, continues because
they're sooo much easier to understand, etc " .
Then python can be exactly like java at last !

Think about it : As long as functions remain first class, some people
will program using a functional style (I surely intend to). The only
way to stop me from doing that is to remove functions from first class
status. If python ever gets very fast, people will reimplement things
like reduce in their own code or in a functional module.


>     John> There is no replacement for lambda in sight, even though lambda is
>     John> arguably the ***largest single*** one of the functional constructs
>     John> that needs work, and has obviously needed work for a long time.
> 
> Once again, you desire Python to be something it is not.  If you want a
> strong functional language, program in Lisp or Haskell.

Functions are supposedly first class, regular objects in python. Why
can't they be sometimes anonymous, just like tuples, lists and user
defined objects can ? One doesn't even need to consider other
languages to make this point.



> 
>     John> The obvious replacement for lambda, which is some form of inline
>     John> block, has not been seriously discussed, with proposed syntax and
>     John> examples, anywhere I've seen it. Clearly, I'm not ominiscient, so
>     John> that doesn't mean it hasn't, though.
> 
> Anonymous blocks are not a replacement for lambdas, named functions are.

Are there objects in python that must always have a name in any
context whatsoever ? It seems to me that all objects even modules can
be anonymous in at least some context.
Why are people even wondering about adding code blocks when making
real anonymous functions work will do ?

I don't even get why some people who are against the anonymity of
lambdas seem quite ok with the anonymity of code blocks (given how
much more complex a code block can be compared to a lambda, how can
anonymity in their case be fine and not fine in the case of the much
simpler lambdas ?) .

Does anyone care about consistency in python ? For real, if you don't
want functional programming, make functions non first class and stop
claiming that they are objects just like every object.



> 
> >Again, it's something that doesn't fit easily into Python's design.  There
> >were several ternary operator proposals advanced, but none was a clear
> >winner.  Guido's a conservative language designer for the most part.  It's
> >better to leave it out than to put something in you'll regret later.  PEP
> >308 wasn't the first time the ternary operator discussion has come up, by
> >the way.  Functional programming, ternary operators, anonymous code blocks.
> >They've all been issues for a long time.
> 
> You seem to have a burr under your saddle about this stuff.  I'm not sure
> why.  Maybe it's time to get out the curry comb...
> 
> Skip

svlf