On 6/2/07, Rauli Ruohonen <[EMAIL PROTECTED]> wrote: > On 6/2/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Your suggestion would unnecessarily change the semantics of the encoding > > declarations. I would call this gratuitous breakage. > Depending on what the regular expression for the declarations is, the > difference may not be big. I suspect that if coding were always still first, and the identifier charset followed it (or were on the same line), that would take care of this objection. > something like this is what you'd > have most of the time in practice when you care about character sets: > # identifier_charset: 0-7f Why not ASCII? Why not be more specific, with 0x30-0x39, 0x41-0x5a, 0x5f, 0x61-0x7a When adding characters, this isn't such a problem. When restricting them, a standard spelling is more important. > For quick hacks you could use this and everything would just work: > #!/usr/bin/env python > > # Real code. > This isn't really anything more than a countermeasure against Ka-Ping's > tricky.py -exploit uhh... I don't see any charset comment there, so his coding: with a non-ASCII letter in "coding" would still work. -jJ _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
