[Scons-dev] Why we need to release separate SCons3 for Python 3
anatoly techtonik
techtonik at gmail.com
Fri Feb 22 18:29:40 EST 2013
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130223/cbe8dec3/attachment.html>
More information about the Scons-dev
mailing list