I hate bringing up something that has been hashed over so many times, but I'm a bear of little brain and am not understanding the migration path. The whole use of the "2to3" tools seems like an abrupt hack. It is workable, but causes a serious plan for near term 2.x to 3.x migration. I'd like to present a different view. Instead of just yelling how it must be wrong, consider it. It's not far from the current migration path and is less rocky.
Moving from 2.6 to 3.0 appears to encompass the following major tasks, and some minor ones: 1. Change of Unadorned strings from default 'b' to default like the (now illegal) 'u' 2. Changed print becomes a function 3. Changed meaning of keys(), items(), and values() changed 4. Removed default ordering operators, string exceptions, old classes, etc. 5. Changed repr() for Long. 6. Completely predictable syntax modifications for Raise, Catch, etc. etc., etc. This is a lot for my head, and even a tool to translate is going to cause odd warnings and syntax errors everywhere. It's especially hard as the advantages to using 3.x are not immediately realized upon conversion. Now, for me this is (hopefully) academic: I'm hoping not to port BLs (metric) of code. Still, my consideration for programmers would much prefer this sequence that could, with changes to 2.6, be done one module at a time in a way that converted and unconverted code could live side by side. Over time, more of the transitional elements would be 'required' in my build environment. That is, I would want to make my changes gradually and have a reasonable expectation that the first time I ran 2to3 would also be my last. The biggest and most thoughtful cost is carefully looking at every single string in my application and deciding if it should be bytes or unicode, and adding the 'b' or 'u' adornment appropriately. This would take an immense amount of time, requiring rethinking APIs, duplicating modules when needing both byte and unicode processing, etc. It's something to do 'later'. I expect a transition period of adorning the strings whenever working on the code anyway. Eventually, I would enable the Python warning about unadorned strings to catch the last cases and times I pull executable code from a file, database, or socket. I would start banning deprecated and changed names, e.g., keys(), range(), input() and the like. When it makes sense, I might use iter_keys(), xrange(), or raw_input(). When it doesn't, I would explicitly call functions, not use idioms, to perform the old tasks: range_as_list() or input_with_eval(). Again the pattern of a period of gradual change, then pulling the compiler switch to warn about old usage. I would start using the handy new printing function, named print3(), instead of the print statement. Then I might, one day, switch to running 2.6 in the mode that warns about old style classes, default comparators, string exceptions, and the like. Likely, I would use the fine grained control to turn those warnings on one at a time over a period of weeks or months. Once there, I could confidently run 2to3 to build a 3.x version. I would do the same amount of work, but spread my risk along a much longer schedule with more options. I would save time by using serendipity when already maintaining code. My 2.6 version would always interact correctly between modules which have been upgraded and those that have not. In many ways, I'm not saying anything new. Without fine grained control in Python, I would expect coders to start running the "-3" option or running "2to3" occasionally to see what would need to be fixed later in the module which has just been opened up. With the fine grained control, this could be managed. About 80% of the way could be done by judicial control of static analyzers, such as PyChecker or PyLInt. 100% would require options in Python. Overall, the 2.x to 3.x transition needs to be fairly painless. The only immediate features for developers are better unicode processing. The other features are all items that will be in 2.6 eventually, or have yet to be shown as really useful. In a perfect world, the gradual transition looks like the more like the transition of C code to ANSI-C code to ANSI-C compiled in a C++ compiler and less like the Perl leaps between version. Once ready, the transition from 2.7 to 3.0 would be mechanical. _______________________________________________ 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
