On the Unicode side, I am not sure what the issue is. We have Unicode issue with python on windows today already, and these seem to be working fine. Given that I deal with the Unicode for our product here, I happy to look at this more, or help out. However there should be a major issue I believe with scons and Unicode. Well the only issue I can think of is the subst code as the internal string object that scons makes has a number of bugs that need to be fixed, however that is simple to fix.
Jason From: [email protected] [mailto:[email protected]] On Behalf Of Gary Oberbrunner Sent: Friday, February 22, 2013 12:54 PM To: SCons developer list Subject: Re: [Scons-dev] Why we need to release separate SCons3 for Python 3 On Fri, Feb 22, 2013 at 10:10 AM, anatoly techtonik <[email protected]<mailto:[email protected]>> wrote: On Thu, Feb 21, 2013 at 4:03 PM, Gary Oberbrunner <[email protected]<mailto:[email protected]>> wrote: On Thu, Feb 21, 2013 at 5:23 AM, anatoly techtonik <[email protected]<mailto:[email protected]>> wrote: before EnsureVersion() will have a chance to fire, there already will be a syntax error. Can you say more about this? What kind of syntax error? In what conditions? Every construct of Python 2.x that is not compatible with Python 3 will give errors - print statements is the most obvious. We're planning to have a single code base for 2.7 (maybe 2.6 if it's no more work) and 3.x in SCons itself. You've read the links Russel sent out, right? Seems like most things should work. Seems to me there's no reason users can't write SConscripts that work the same way. print is no big deal because you can use the functional form to get cross-version compatibility. It may not be trivial, but for many users who don't care about cross-version compatibility it should be even easier -- they can use python 2 calls if they're using python 2, and python 3 calls if they're using python 3. Right? They shouldn't care how we've written the SCons internals. You said there would be syntax errors before EnsureVersion() will have a chance to fire -- this of course would be a big problem. And not having tried it yet, I don't want to disagree, but I'm not sure how or why this showstopping issue would happen. Can you maybe post a snippet of the SCons-internal code and/or user code that would cause this syntax error? I really want to avoid having to have a "scons3"/SConstruct3 and so on. If you think we can't escape that, let's discuss more. One thing we haven't discussed that seems like it could be a big(?) problem is strings we get from running commands, and then print to SCons's stdout/stderr. We don't know what encoding those strings are originally in, but it seems to me like the python3 string system requires us to know the encoding and provide codecs, and if we get this wrong the output will be mangled. In python 2, we just accept the byte streams from subcommands' stdout and stderr, and print them out unmodified. It seems to me harder (impossible?) to do this in python3 because it really wants everything to be a string. Does anyone understand the python3 unicode stuff well enough to comment? -- Gary
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
