I believe I am agree with you. A good example is file handling. There are differences in 2 vs 3 and this was one reason why Steve knight talked about the node object for File and Dir had to support the needed file api’s so that the user would not need to import os or os.path or use have to use the file() or open() api’s.
This is why I think that we have to make it clear that if we add python 3 support we make it clear about this be a major change that may require them to make changes, we also have to document common pitfalls. We should have API for as many of the pitfalls as we can to help user move away from stuff that could break there build files if they have to build with python 2 and 3 on different systems. We will have the same issue with python support in Scons we will have new stuff going to a scons X, while back porting what we can to a scons 2, until python 2 does not exist for use anymore. There will be user that will say let try a different system during this move, unless we can show improvements worth dealing with the current Scons short comings There will be challenges. This will not be easy. Jason From: [email protected] [mailto:[email protected]] On Behalf Of anatoly techtonik Sent: Friday, February 22, 2013 5:30 PM To: SCons developer list Subject: Re: [Scons-dev] Why we need to release separate SCons3 for Python 3 I like you enthusiasm and desire to push Python 3 forward, but I must warn that wrong move will kill many existing SCons users. If Blender + few more projects will not use SCons anymore, I won't be here too. Do you think that all existing users know the intricacies of 2 to 3 compatibility? Do you think they will be willing to port their existing scripts to Python 3 and know how to do this properly? Do you really want them to know about generators and other stuff that changed behavior and don't give immediate syntax errors like print? For example, where do you think can be a problem in this completely obvious and working Python 2 code? d = {"z":23, "x":21} d.items()[1] This code won't work in Python 3, and hence SConstruct will fail as well. Can you explain users how to patch all these uses? I expect that users who faced with non-obvious porting scenario will ask themselves - why do I continue to use SCons and deal with the problem it delivers with its poor 2 to 3 transition management and not learn something new instead and rewrite all this stuff in waf, gyp, cmake or some of those - http://en.wikipedia.org/wiki/List_of_build_automation_software ? -- anatoly t.
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
