<html><body>On 09:04 pm, tcdelaney@optusnet.com.au wrote:<br /><br />>I'm wondering if we might be going the wrong way about warning about<br />>compatibility between 2.x and 3.x. Perhaps it might be better if the 3.0<br />>alpha had a 2.x compatibility mode command-line flag, which is removed late<br />>in the beta cycle.<br /><br />Please, no.<br /><br />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.<br /><br />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.<br /><br />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.<br /></body></html>