why python annoys me

[Alex Martelli]

"James Logajan" <JamesL at Lugoj.Com> wrote in message
news:3AE1D1DE.BF3CEA18 at Lugoj.Com...
> Alex Martelli wrote:
> > [...] since Python does have list comprehensions, [...]
>
> Not being a computer scientist, I hope you can excuse a profoundly
ignorant
> question, but what are (or is?) "list comprehensions"? And another
question

In Python, a list comprehension can be seen as a nifty abbreviation
for a loop that builds a list.  A list comprehension can have _nested_
loops, but assuming a single loop, then the list comprehension
notation may be written as:

    result =  [ <expression> for <var> in <sequence> if <condition> ]

to correspond to

    result = []
    for <var> in <sequence>:
        if <condition>:
            result.append(<expression>)

where <...> notation is meant to suggest "placeholders" for various
things (an expression, for-loop variables, a sequence, a condition)
that you can write.  It's more general than this, even apart from
nesting possibilities -- you may not have the if part, and it's an
expression (you don't have to assign it to something) rather than
a sequence of statements, so it's directly usable in many places
(as a function argument, for example).

> (probably harder to answer): is there someplace on the web or in print
where
> I can find a good definition of "functional programming"? I'm pretty sure
it
> doesn't mean classical procedural notation, more like mathematical or
> logical notation, but I can't be sure.

http://www.cs.chalmers.se/~rjmh/tutorials.html has a list of good
tutorials on functional programming.  I see somebody has already
suggested the comp.lang.functional FAQ -- specifically at
http://www.cs.nott.ac.uk/~gmh//faq.html#functional-languages
you will find a proposed definition.


> Many years back I did some application development using such a beast (at
> least I think that is what it was trying to accomplish), but in the end
one
> had to rely on procedural elements to get information in and out and do
some
> other pedestrian things.

Haskell has an interesting solution to I/O and "other pedestrian things"
in rigorous FP terms, called "monads", which some consider by far its
hardest part to grasp.  There IS a lot of introduction to them, and if
you're interested in seeing if "pedestrian things" can be avoided it may
be worthwhile to study Haskell in enough depth to really grasp monads.


Akex