map vs. list-comprehension

[Terry Hancock]

On Thursday 30 June 2005 09:49 am, Mike P. wrote:
> That really sucks, I wasn't aware of these plans. Ok, I don't use reduce
> much, but I use lambda, map and filter all the time. 
> [...]
> Also, I don't necessarily think list comprehensions are necessarily easier
> to read. I don't use them all that much to be honest.

Actually, I prefer list comprehension syntax, after having a chance to experience
both, both as a writer and a reader of other people's code.  So I disagree with
this particular issue.

> IMHO I'm not particularly happy with the way Python is going language wise.
> I mean, I don't think I'll ever use decorators, for example. Personally, in
> terms of language features and capabilities I think the language is fine.
> Not much (if anything needs to be added).

This though, I mostly agree with. I'm not sure if I'll ever find use for decorators,
but the "@" signs bother me, I must admit.  I liked the fact that there was a
way to do this without fiddling with the language syntax.
 
> I think at this stage the Python community and Python programmers would be
> better served by building a better, more standardised, cross platform, more
> robust, better documented, and more extensive standard library. I would be
> happy to contribute in this regard, rather than having debates about the
> addition and removal of language features which don't improve my
> productivity.

Now this, I agree with wholeheartedly!  The library is where the real work ought
to be happening.

Either that, or previous suggestions about making access to external packages
should be improved and the "batteries included" focus should be sidelined.

One of the strengths of Python has been that the language itself is small (which
it shares with C and (if I understand correctly, not being a lisp programmer?) Lisp),
but with all the syntax enhancements going on, Python is getting pretty complicated.
I have to wonder if new users won't begin to find it just as intimidating as Perl
or other big languages.

I know something like that happened with HTML.  When I learned it, HTML was
very simple (version 1? I think or maybe 2?).  Later extensions in 3.2 and 4.0 didn't
bother me, because they were incremental increases over what I already knew. But
new users are finding HTML much more daunting, which encourages them to
reach for WYSIWYG tools and the like, rather than just coding it.

So my former experience of HTML as "dead simple" seems to have been undermined
by the later developments.  It still seems "dead simple" to me, but new users don't
seem to have the reaction that I did.

I strongly doubt this is because "new users are wimpier than we were".

Likewise, part of the thing that attracted me to Python and which I still consider
a "selling point" is that it is not only easy for me to use, but easy for potential
collaborators to learn.  Since the projects I am most interested in are free-software
projects primarily interesting to non-programmers or semi-skilled programmers,
the need to make the code as easy for them to understand as possible is important
to me. I want to actually encourage users to *become* programmers to work on
my projects, not just interest existing programmers.

Before I encountered Python, that didn't seem possible.  But I was really impressed
with how easy Python was to learn (that is, Python 1.5.9).  Even 2.1 was pretty easy,
and I acknowledge the benefits of list comps and the like, even though I also see that
they can be abused.  Now, though, I'm starting to wonder if that newfound advantage
is disappearing.

Frankly, I feel like slamming on the brakes. Simplicity is really, really good,
and we shouldn't forget that in our zeal to make Python "a better systems programming
language".  ISTM that it's already pretty good at those tasks, and if it's a little harder
to do a few things, maybe that's the cost of keeping most things easy.

In any case, the Python object model is very flexible, and most things you want
to do can be done using it.  So it seems to me like compartmentalizing changes by
keeping them in modules would be really good.

I guess I've become a python conservative. ;-)

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com