[Scons-dev] Why we need to release separate SCons3 for Python 3

Gary Oberbrunner garyo at oberbrunner.com
Fri Feb 22 13:53:57 EST 2013


On Fri, Feb 22, 2013 at 10:10 AM, anatoly techtonik <techtonik at gmail.com>wrote:


> On Thu, Feb 21, 2013 at 4:03 PM, Gary Oberbrunner <garyo at oberbrunner.com>wrote:

>

>>

>> On Thu, Feb 21, 2013 at 5:23 AM, anatoly techtonik <techtonik at gmail.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130222/b85f7a68/attachment.html>


More information about the Scons-dev mailing list