This is something that I've been pondering over for a while now, but I haven't been able to come to any strong conclusions. I'd appreciate some comment, and possibly a bit of clarification in the documentation for migrating to 3.0.
I'm basically an end user of Python. I don't write libraries or frameworks, but I do depend on a number of 3rd party libraries. As a Windows user, I'm probably more dependent on binary installers than the average Unix/MacOS user. As far as my own code is concerned, I am able to follow the standard migration path (move to 2.6, fix issues in 3.0-warning mode, use 2to3 and test, repeat as needed). As my code is generally not complex, I don't expect this to be a particularly lengthy process. But I'm going to be stuck until 3.0-compatible installers are available for the extensions I use. And that's even true for pure-Python packages, as they will need to do the 2to3 dance as well. So there's a bottleneck in 3.0 adoption, with end users not being able to move to 3.0 until package maintainers have done their bit. In the long run, this will happen, but it could slow down adoption of 3.0. I see this already - as 99.9% of my code depends on either pywin32 or cx_Oracle, and with neither having 3.0 compatible binaries yet, I can't make any practical use of the 3.0 alphas. As I said at the start, I don't have any good answers. But would it be worth maintaining something like a wiki page of key libraries and their expectations for moving to 3.0? It might at least make people aware of reasonable timescales, and set some expectations for chronic early adopters like me :-) Paul. _______________________________________________ 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
