On 09:04 pm, email@example.com wrote:
I'm wondering if we might be going the wrong way about warning about compatibility between 2.x and 3.x. Perhaps it might be better if the 3.0 alpha had a 2.x compatibility mode command-line flag, which is removed late in the beta cycle.
I don't think command-line flags are going to help much, because the problem is not the complexity of downloading and compiling py3k, it is the complexity of porting software that has modules from a variety of different sources.
More importantly however, I'm not even going to be looking into porting anything to py3k until a year or so after its release - and that's only if 2.6 has given me some tools to deal with the transition. The reason I am posting to this thread is that I had *written off py3k entirely* before Anthony started making noises about forward compatibility. The support cycle of Ubuntu Dapper makes it likely that Twisted will be supporting Python 2.4 until at least 2011. I assume 2.5 will last a year after that, so assuming 2.6 has perfect forward compatibility, we'll be looking at a py3k port in early 2013. Features available in the beta releases aren't going to help me there.
Plus, this defeats the whole purpose of py3k. Why break compatibility if you're going to include a bunch of gross compatibility code? Compatibility has already been broken in the py3k branch, there's no point in putting it back there. Adding it to 2.x might make sense though.