This is a response of sorts to Fuzzyman’s post “You don’t really need it”. In any community discussion, people whose views are passionately held and who feel strongly enough to persevere in a discussion will tend to dominate any thread and will eventually be remembered as “the community thinks”. Their views might be representative or not, reasonable or not. But they will be heard. In addition, it’s clear that some commentators come along to the discussion forum with an attitude of “I know what’s wrong with Python…” and no matter what the relative merits of their proposal, this approach will tend to provoke more or less hostility. We’re all human, after all. Tempers can rise, things can get heated. Sometimes the best thing is just to back off before posting for a bit. I’m sure I’m not the only person who’s penned a strong response to a post just to get it off my chest, and then deleted it without sending.
By and large I agree with Michael in the points he makes. “You don’t really need it” can be a valid put-off, especially for inexperienced developers, but it can’t be a universal answer. The flip-side, however, is: ok, you might need it, but should it become part of Python-the-language or even Python-the-stdlib?
The latter is slightly easier to answer: create a module which does what you want; post it on PyPI, advertise it through your blog and the lists; and see what the uptake is. For an example, the pyprocessing module is just making it into the Python stdlib as “multiprocessing” after someone (not its author) proposed it, wrote a PEP, garnered some support — and some opposition — from core developers, and finally got the thumbs-up from the BDFL. Likewise, simplejson I think. Other suggestions haven’t made it in, and sometimes there’s no clear divide except what takes the fancy of the relevant people. This isn’t a democracy, and life isn’t always fair :)
The former — changes to the core language — are of course far more tricky. And I get the impression that people coming fairly fresh to the language imagine that adding some keyword or syntax change is basically just as easy as updating a docstring. They find the use case that supports a (possibly reasonable) change or addition and don’t consider: existing code which might break; wider technical or technosocial[*] ramifications of the change; or simply the amount of work needed to add a new keyword or construct, add tests for it, and make sure it doesn’t do what it shouldn’t. And that’s assuming that enough people agree that it’s a good idea.
A lot of discussion goes on around even approved changes to the language (some of it bikeshedding, certainly) and this can bewilder people who thought that, on the surface, they were proposing a simple and useful thing.
[*] A word I’ve just invented to mean the kind of things technies discuss among themselves.