On 6/3/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > Merely to define those is non-trivial, and it is absolutely out > of the question to expect that the average Python user will know > what the character set "strictly-conforms-to-UTR39-restrictions- > allows-confusables" is.
This is a bit of a strawman, as most of the time the charset would be ascii or everything, which are much easier concepts. Point taken about trying anything more complex, as the reader will generally no longer understand that anyway. A special-purpose tool can handle the complex cases much better. > ease of use is "globally restrict to what my students can read = > ASCII + Japanese". I prefer your first definition of ease of use: > Ease of use of audited code is trivial; turn the checks off. This along with your another idea sounds fairly good, actually: > The reason I favor the single command line flag (perhaps even > restricted to the binary choice of compatibility ASCII vs. PEP > 3131 Unicode) is as a transition strategy. The KISS way of having a single flag for either ASCII or PEP 3131 (if the even simpler way of only PEP 3131 is too simple) should take care of most (all?) of the use cases, and nobody's head will explode. If it's this simple, then it's not a problem to have it on the command line, and my suggestion is unnecessary. > I do not agree with Ka-Ping inter alia that there are bogeymen > under the bed, Looks like the only ones who do agree want pure ASCII, so a binary option is sufficient. You could also argue that it's a choice of old behavior and new behavior, and anything else is unnecessary. You might even use "from __future__ import unicode_identifiers" instead of a command line flag, if you view it like that. > but then I live in Japan, and there *is* no "under > the bed" (we sleep on mats on the floor<wink>). ちなみに私も日本で布団で寝たことがあります<wink> > I think it's quite reasonable to provide a non-invasive, *simple* > auditing facility for those who want it. Emphasis on simple, indeed. If you start adding more complex auditing systems, then it would make sense for the files to declare which specification they conform to. > When you're talking about security holes, the burden of proof > should *not* be on the paranoid The default doesn't really matter much. It's simple to use "#!/usr/bin/env python -U" or whatever in scripts, whether that option selects PEP 3131 or ascii. > As James Knight says, the "configure the world in one file" > strategy that jJ and I were batting around is a bit nuts, but it > might not be a bad strategy for configuring a loadable auditing > codec or external utility; I don't think that's wasted mental > effort at all. True, but such details have clearly gone beyond a "*simple* auditing facility" and sound like a solution looking for a problem. _______________________________________________ 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
