[python-committers] Deny nonbreaking spaces in the precommit script?

[Benjamin Peterson]

2010/11/8 Łukasz Langa <lukasz at langa.pl>:
> Am 07.11.2010 19:28, schrieb Benjamin Peterson:
>>
>> 2010/11/7 Victor Stinner<victor.stinner at haypocalc.com>:
>>>
>>> I would like to know if it would be
>>> possible to block a commit introducing nonbreaking spaces? A least for me
>>> :-)
>>
>> I don't think add pre-commit hooks for every conceivable mistake is
>> the right way to go.
>
> I see you're basically saying "We're all adults here" and that we should be
> able to control our own environment so these kinds of commits don't happen
> (like Guido said). Well guess what, I believe that isn't going to work. Let
> me tell you why.
>
> 1. Most* contributors work on Python in their spare time. That means they
> also have jobs, families, all kinds of everyday trouble. Even if 99% of the
> time their performance is stellar, there will be times when some stupid
> errors get through.
>
> 2. We invite more contributors now which means there are going to be more
> rookies than ever before. I for one am an example of that. You either expect
> newbies to perform like their own mentors from day one or expect mentors to
> waste time working out dumb rookie mistakes made because of a misconfigured
> environment, etc.
>
> 3. Speaking of environments, they change. Software evolves, people switch
> machines, operating systems, editors, toolchains. If one Debian veteran
> switches to Mac OS X and makes some error because of false assumptions,
> misconfigured software, whatever... his experience should prevent other
> people from making the same mistake in the future.
>
> I could go on and risk boring you to death. The point is, if we can automate
> stuff out of the workflow, we should definitely do it. Each and every time.
> We don't gain anything by not implementing automation.

I don't think you can ever automate "checking for mistakes" out of the
workflow. There will never be a commit hook that checks whether you
created a race condition or deference possibly uninitialized memory.
IMO, if you're unwilling to be looking for simple and complex bugs,
you should think twice before committing at all.

>
> Even if that commit hook prevents a single wrong commit a year, it's worth
> it. As unpaid volunteers, we don't have time for hunting the same mistakes
> twice.
>
> One last disclaimer. I'm not a native speaker so if the tone of my post
> sounds offensive or rude, I apologise in advance because that was not my
> intention. OTOH, the zen says explicit is better than diplomatic. Or
> something like that.




-- 
Regards,
Benjamin