write a loopin one line; process file paths

[bonono at gmail.com]

Xah Lee wrote:
> besides syntactical issues, another thing with doing functional
> programing in imperative languages is that they become very inefficent.
> Functional languages are optimized by various means of functional
> programings styles. Doing them in imperative languages usually comes
> with a order of execution penalty because imperative language compilers
> are usually dumb.

The itertools module and the new generator feature tries to make this
better as it is lazily evaluated, in a sense. But its side effect is
nasty. Usable though need to twist my mind a bit, not like when I do it
in haskell. But the occasion imperative dip makes some of my programs
easier to code.

>
> though, one can't totally blame for Python's lack of ability to do
> functional programing. Its language's syntax of using indentations for
> blocks by design, pretty much is in odds with functional programing's
> sequencing of functions and other ways. (such as generic mechanism for
> prefix/postfix syntax, or macros or other transformations and patterns,
> or heavy reliance on the free flow of expressions/values)

That I am not sure. haskell also use this indentation but I don't see a
problem about it. One thing I find it odd though is the @decorator
construct. I just don't understand why it is viewed as simple. It
becomes very ugly IMO when there is a number of it, I am doing some web
apps which requres varies decorators(one over the other).

@format
@login_block
@validate
@something
def my_func():

I find it easier to read and under stand in the form of

format(login_block(validate(something(my_func))))) though haskell's $
and . is even better.

format.login_block.validate.somethin.my_func

>
> I don't blame Python that it doesn't cater to functional programing BY
> DESIGN. But i do hate the mother fucking fuckheads Pythoners for one
> thing that they don't know what functional programing really is, and on
> the other hand fucking trumpet their righteousness and lies thru their
> teeth of their ignorance. (that Guido guy with his Python 3000 article
> on his blog is one example, possibly forgivable in that particular
> instance. (http://xahlee.org/perl-python/python_3000.html))

That seems to be the case, I mean the design. For fairness, list
comphrehension sometimes looks cleaner, though becomes ugly when you do
the pipe/chain like programming in FP(multiple for). This again is an
odd choice. It seems to be a flattening of multiple line for loop, yet
at the same time python seems to be moving towards being more
explicit(no map/filter/etc as they can be done in for loop).

But I believe Python is designed for easy to code and read and maintain
in mind. One has to admit that without some training, FP is not very
intuitive, my head spin when I see haskell code. A for loop is easier
to understand.

Well, if you want clean FP, you can always try haskell which is getting
better and better in terms of real world module support(file system,
network etc).
>
> (excuse me for lashing out)
> 
>  Xah
>  xah at xahlee.org
> ∑ http://xahlee.org/