On 6/2/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > Whether or not there exists a tool to convert from Python 2.6 to > Python 3.0 (2to3), every tool that currently handles Python source > code encodings via the method specified in the documentation > (just about every Python-centric editor I know) would need to be > changed.
How so? The old regexp can still match the encoding tag unless the user insists on using it in an incompatible way. As syntax changes go, this one causes little trouble for editors. > Guido doesn't always overrule everyone. Yet he makes the decisions. That's why i used his latest comments on the topic to set the defaults in the suggestion. These are easily changed when necessary, and the whole issue of defaults is quite minor. What matters more is having a convenient way of setting the character set restrictions of a module. The reason I quoted him at such length was that I thought that you might have missed some of his posts because you simply ignored what he had to say (and no, I generally don't remember people's names). > There are other solutions (global registry of individual module > allowed identifiers, in-module with a different syntax, etc.). These are more to the point. Do you have anything concrete? A global registry sounds unwieldy and most would probably enable everything instead of going through the trouble of using it. What kind of in-module syntax would you use? > Adding a tool to an arbitrarily large or small previously existing > toolchain, so that the majority of users can verify that their code > doesn't contain characters that shouldn't be allowed in the first > place, isn't a very good solution. I doubt the majority of users care, so the verifiers would be a minority. You're exaggerating the amount of work caused by Guido's solution. I made my suggestion because in my opinion it or something like it is a more convenient solution for most cases, but Guido's isn't as bad as you make it out to be. > Only because it is so rarely used that no one really runs into > unicode identifiers. It doesn't really matter why they're not a problem in practice, just that they aren't. A non-issue is a non-issue, no matter why. > As such, the only sane position is to require > the explicit enabling of unicode identifiers. Neither default would cause big problems, so there are at least two sane positions. One may be better than the other or they may be equally good, it's hard to say which. > where else in Python has the tiny minority defined the defaults for > the vast majority of users? I'm sure you will find tinier minorities if you search for them, but most users don't use extended slice notation to its full extent, yet it's enabled by default even though it silently accepts a probable typo. Confusing non-ascii characters are also accepted by default in strings, even though only a tiny minority uses those particular characters in strings (I'm sure you've seen the examples). > yet you still don't understand that ascii is the only sane default. It is not the default in Java, which is a major language, and I don't hear constant complaints about it having to be changed, so there are quite many people who think that the above statement is not true for programming languages in general. The claim that static typing makes a big enough difference here is less than convincing. _______________________________________________ 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
