On 08/11/2010 12:59, Nick Coghlan wrote:
On Mon, Nov 8, 2010 at 10:55 PM, Michael Foord<mich...@voidspace.org.uk> wrote:
On 08/11/2010 12:53, Nick Coghlan wrote:
[snip...]
Non-breaking spaces are legal in utf-8 encoded Python source files.
While including them accidentally is less than ideal, it is perfectly
valid to include them deliberately. Trying to design an automated
check that can make a reasonable guess at intent is going to require
far more effort than is needed.
Is it valid though? Standard library rules are ascii only (as referenced by
Guido in this thread). If you need the characters in a string literal you
must escape them.
Nope - those are the "few specific encoding test cases" he mentioned
in that email. They take advantage of the utf-8 encoding of the source
files these days.
Ah, well - if we *do* allow non-ascii characters in standard library
files then we *can't* make it a pre-commit hook unless we hardcode those
exceptions into it.
Adding a pre-commit hook would necessitate someone creating it anyway,
and so far no-one has volunteered.
All the best,
Michael
Cheers,
Nick.
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
