Python Iterables struggling using map() built-in

[Chris Angelico]

On Fri, Dec 12, 2014 at 10:28 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> I think that there is a legitimate debate to be had as to whether this
> conservativeness and resistance to change is a good thing or a bad thing,
> but I don't think that there should be any debate about the reality of the
> Python community being strongly conservative, compared to the "anything
> goes" attitude of (say) Ruby, Perl and Lisp programmers. We don't like code
> that does anything we haven't seen a hundred times before.

I agree that Python is a lot more conservative than many languages,
and personally, I think it's good. When it comes to monkeypatching,
less is *definitely* better - less places where you have to figure out
what import changed the meanings of your built-ins, and so on. (Case
in point: A logger replacement tampered with the
log.info()/log.error() family of functions, adding a keyword
parameter. Took me a fair amount of digging to find out exactly where
that happened, and it made REPL importing of the module's functions
rather awkward.) The same is true of obscure namespaces, specifically
because they're obscure; if I do a JSON decode of something, I'm not
going to check to see if numbers came through as a subclass of float
with a ".warnings" attribute to tell me about loss of numeric
precision, even though that would be perfectly possible. Since almost
nobody does this, nobody will expect it to be done, ergo nobody will
go looking for it, and the feature may as well not even have been
implemented if it's never seen. Popularity *is* sometimes a legitimate
argument.

ChrisA