UserLinux chooses Python as "interpretive language" of choice

[Francis Avila]

H.V wrote in message <279b566d.0312201935.38fb2156 at posting.google.com>...
>Skip Montanaro <skip at pobox.com> wrote in message
news:<mailman.374.1071937108.9307.python-list at python.org>...
>
>Given all that Guido has said about functional programming, i'm
>starting to wonder why he even made functions first class in python .

He didn't make them first-class.  He made everything an object, which has
the consequence of making everything first-class.

>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?

No, but it was deemed to not be useful or idiomatic enough to warrant a
builtin.  The most common use-case (like, 99% most common) was simply
summing up numbers, so we got a clear and conscise (and faster) builtin for
that, and continue to do things idiomatically for the other use cases.

I tend to agree with this.  I've never found a use for reduce, even trying
hard to think of where I might find a home for it in my code.  All I've ever
done with it is sum things.  Even the Numeric people don't seem to use
reduce, and it seems that they, of all people, would use it.  It's simply,
for whatever reason, not Pythonic.  People naturally gravitate to alternate
idioms to do things that reduce could do.

Whether sum itself should be a builtin instead of in math is another issue
altogether, but removing reduce from the builtins definately seems like a
good decision to me.  It may not be the right decision in some other
language, but for whatever reason, Python doesn't use it much.

>>     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.

Python isn't really big on being conceptually pure, just on being clean,
consistent, and easy-to-use and understand.

I think the drive to get rid of usecases for lambdas is rather the opposite
of what you seem to suspect: lambdas have so few uses as it is, that the
Pythonic bent towards using fewer keywords/builtins/constructs has inclined
people to see if those few use-cases are really unique enough to warrant the
special syntax, or if it can somehow be subsumed and eliminated by other,
more generally useful constructs.

I will argue in the following that lambda simply isn't very useful *to*
*Python.*

>> 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 !

You've got it backwards: functions are first-class in Python *because*
everything in Python is an object. (Did you notice that functions have
attributes, like objects?)  It would be impossible to make them *not* first
class!  (Well, I guess not impossible, but it would require enormous kludgy
hacking at core Python internals, and will inevitably result in bugs that
would haunt Python for the rest of its days.  Besides, it's inconsistent,
and Python hates special-cases.)

Anyway, the following is a fantastically common and powerful Python idiom
that requires functions (well, really methods) to be first-class:

class Dispatch(object):
    def do_this(self): pass
    def do_that(self): pass

    def dispatch(self, cmd):
        cmd = 'do_' + cmd
        if hasattr(self, cmd):
            getattr(self, cmd)()
        else:
            raise NotImplementedError

Just because functions are first-class in Python doesn't mean we have to use
them the way functional programmers use them. ;)

>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.

Anyone is free to program in a functional manner.  In fact, Guido was quite
amenable to the suggestion (I think by Hettinger) that there be a functional
module in the standard library, similar to how we have the itertools module
for generator fun.

However, we will remain free to point out how there's usually a more
straightforward Python idiom that does the same thing faster and more
clearly. ;)  We all hope Python calls get fast enough that functional
programming in Python is not always slower, but, even if functional
constructs were faster than standard idiom, Python would still stick to
idiom, unless it needed to optimize.

Of the functional functions, the only one that can occasionally beat a
for-loop is map.  Map is faster than anything else when the function used is
a builtin.

Remember that no matter how nice your lambda syntax gets, functional
programming will probably always be slow in Python, simply because calling
is slow in Python.  Quite slow, in fact, and there's no obvious way around
that.  So Python generally prefers solutions that do not involve calling
functions repeatedly, especially not functions as tiny as the ones you can
comfortably fit into a lambda.  Given this, you can see why anonymous
functions don't make much sense for Python.  Python would get rid of lambdas
before it tried to "make them better", and no one is sure what that would
entail.  So just use 'def' and be happy.

>>     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.

They can be anonymous, but to be small enough to be anonymous means being
inefficient.  Python simply does not go the way of small, throwaway
functions, because there's no obvious way to use them without morphing
Python into an entirely different "functional Python" language.  And it will
still be slower than using for-loops.

>>
>>     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 ?

What does it mean to make them "work"?  If you have an anonymous function,
where would you use it?  map()? reduce()?  But these are all slower and
less-intuitive to Pythonistas than using for-loops and list comprehensions.

So I would argue, there's no place to put anonymous functions to work in
Python.  That's why they never do any. (Work, that is.)

If we make lambda some powerful construct that can have multi-line code,
we'd just scratch our heads and say, "why didn't you just use a def"?  If
the function is long and involved enough, making it anonymous ceases to be
of any importance.  We'd end up just assigning the lambda to a name anyway,
so what's the point?

In other words, why is:

def myname(): pass

somehow intrinsically worse than:

myname = lambda : pass

supposing the latter were legal?  If lambda were in every way the same as
def, except that lambda is anonymous and def is not, and that lambda was
legal in more places, then certainly the lambda is more general than def,
and we should get rid of def, since Python does not like to have equivalent
constructs.  But the only thing the latter has over the former is that the
latter can sometimes be used anonymously.  "But," future Pythonistas will
say, "we hardly ever use these anonymously!  Why don't we invent a new
syntax that allows us to define the name inline, like we see many other
languages happily doing."  And then they reinvent def, and then the upstart
def-ites lobby Guido against the old-school lambda-ites, and lambda is
overthrown "because def," (speaking from the future, now), "replaces the
by-far-most common use case of lambda and does it more clearly, and the
little niche use of lambda that's left is so rare as to not be worth it
anyway. Guido Jr. the third, out."

>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 ?) .

It's not the anonymity.  It just so happens that in Python, anonymity makes
no sense beyond very small functions placed into the call of these
functional functions for which we always have an equivalent for-loop or
list-comp construct that is faster and more Pythonic.

There simply aren't many places in Python where a function takes a function
as an argument.  And those places where it does usually a for-loop is
clearer and faster (as I've been saying over and over).  In other cases, the
function being passed is large enough that making it anonymous gains
nothing--you'd just have to use a name to refer to it anyway, in order to
make the code clear enough to read.

Or is:

map( lambda x:
    <do some complex multi-line thing with x>
   , range(10))

really clearer than just using def somewhere up above?  It's not even clear
that anything like Python syntax could support such a construct, and in
anycase it is horribly unPythonic in its gnarish attempt to fit everything
into one construct.  So, I could turn the tables and say "what's this
obsession with making things anonymous?" ;)

The only utility of an anonymous function is the ability to define a
function inline, within the calling construct, without polluting the
namespace.  I.e., a "throwaway function".  Now, how often in Python do all
those circumstance conjoin to make anonymous functions very useful?  Not
very, especially because, as we said, function calling is slow in Python.

>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.

Umm...I don't understand.  You can program functionally if you really want
to, but I don't see why Python should feel obligated to support your habit,
especially since it has its own way of doing things that is far more natural
(and, um, faster, at least now) to the Pythonic frame of mind.  Pythonic is
a concept orthogonal to everything else, including "functional" and "OO".
Python doesn't define itself by saying "I am OO, not functional."  Rather,
it examines itself, it peers into its own essence, and discovers, "hey,
there isn't much functional in here, but there's an awful lot of OO."
Python is something that simply *is*; definitions come later, and frankly
will always be inaccurate and provisional.  "Pythonic" is like a culture;
undefinable and always evolving.

It's a tautology that a language best supports those who like the way that
language does things.  So if you don't like the way Python does things, and
you prefer it did things in a more functional way, perhaps you would be
better supported by using a language that *did* do things in a more
functional way?  It won't make you a bad (or even a lesser) person if you
don't use Python, but it might make you happier.

I mean really, fighting about languages is like fighting about the relative
moral worth of screwdrivers and hammers, and going from there to arguing
about whether it's better to use screws or nails.
--
Francis Avila