On 04:43 am, [EMAIL PROTECTED] wrote: >Just being able to (voluntarily! on a >per-module basis!) use a different type name and literal style for >data could help forward-looking programmers get started on making the >distinction clear, thus getting ready for 3.0 without making the jump >just yet (or maintaining a 2.6 and a 3.0 version of the same package >easily, using 2to3 to automatically generate the 3.0 version from the >2.6 code base).
Yes! Yes! Yes! A thousand times yes! :-D This is *the* crucial feature which will make porting large libraries like Twisted to 3.0 even possible. Thank you, Guido. To the critics of this idea: libraries which process text, if they are meant to be correct, will need to deal explicitly with the issue of what data-types they believe to be text, what methods they will call on them, and how they deal with them. You cannot get away from this. It is not an issue reserved for the "pure" future of 3.0; if your code doesn't handle these types correctly now, it has bugs in it *now*. (In fact I am fixing some code with just such a bug in it right now :).) It is definitely possible to make your library code do the right thing for different data types, continue to support str literals in 2.6, and eventually require text / unicode input (after an appropriate deprecation period, of course). And it will be a lot easier if the translations imposed by 2to3 are as minimal as possible. >Note that I believe that the -3 flag should not change semantics -- it >should only add warnings. Semantic changes must either be backwards >compatible or be requested explicitly with a __forward__ import (which >2to3 can remove). This also sounds great. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com