Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Dirk,

If we can avoid print in src/engine/SCons/Tool/__init__.py, then each tool
can import print_function() if they need/want it?

-Bill

On Thu, May 26, 2016 at 1:26 AM, Dirk Bächle  wrote:

> Hi there,
>
> On 26.05.2016 03:52, Jason Kenny wrote:
>
>> I am unclear on what people are suggesting as fixes to the issue. However
>> I believe we tweak the way we “load” the Sconstruct we can
>> control which print logic is used when python 2.7 is used. I don’t
>> believe there is any way to allow the “classic” python 2.7 print
>> to work in python 3.
>>
>> I think if we can allow user of python 2 and SCons to not have their
>> files break, that is a win. When using python 3 the users will
>> need to update the SConstruct print statements ( or use some API we might
>> be able to add).
>>
>
> it just came to my mind that we also have to think a little about the
> external tools. They need to get updated too...which is actually more of a
> task for each repo owner, but it would be good to have some kind of support
> here.
>
> Regards,
>
> Dirk
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Dirk Bächle]

Hi there,

On 26.05.2016 03:52, Jason Kenny wrote:

I am unclear on what people are suggesting as fixes to the issue. However I 
believe we tweak the way we “load” the Sconstruct we can
control which print logic is used when python 2.7 is used. I don’t believe 
there is any way to allow the “classic” python 2.7 print
to work in python 3.

I think if we can allow user of python 2 and SCons to not have their files 
break, that is a win. When using python 3 the users will
need to update the SConstruct print statements ( or use some API we might be 
able to add).


it just came to my mind that we also have to think a little about the external tools. They need to get updated too...which is 
actually more of a task for each repo owner, but it would be good to have some kind of support here.


Regards,

Dirk

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Jason Kenny]

I am unclear on what people are suggesting as fixes to the issue. However I 
believe we tweak the way we “load” the Sconstruct we can control which print 
logic is used when python 2.7 is used. I don’t believe there is any way to 
allow the “classic” python 2.7 print to work in python 3.

 

I think if we can allow user of python 2 and SCons to not have their files 
break, that is a win. When using python 3 the users will need to update the 
SConstruct print statements ( or use some API we might be able to add). With 
this python3 capable drop of SCons I believe we should allow people to migrate 
to the new print() api by injecting a print function when SCons is used in 
python2. Such as function would look something like:

 

# print prototype for python 2.7

def print(*lst,**kw):

msg = list(map(str,lst))

msg = kw.get('sep',' ').join(msg) + kw.get('end','\n')

sys.stdout.write(msg)

 

This should allow users of python 2 to have everything work as expected, given 
them time to move to a python3 like print() function over time. The will be 
able with python2 to have print and print(). This should allow user time to 
migrate SConstructs for a safe move python 3 when they are ready.

 

Still think having an official API will be a good thing long term, however this 
should allow current users to not break. We have to remember that no one is 
using python3 at this time, so expecting Sconstuct to change to work in python 
3 is not unreasonable, given we don’t have API’s in SCons today to prevent 
that. Users still may want to SCons to add Api to make this easier. Such as 
case could happen with files. I know Steve Knight had said a number of times he 
wanted to SCons users to use the node File and Dir to do all file based actions 
for example. If that work had happened it could help as well with current 
builders that will break when moving to python3 because of changes needed in 
the API to load data as expected.

 

Just some thoughts, hope this might help

 

Jason

 

 

From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Bill Deegan
Sent: Wednesday, May 25, 2016 1:08 PM
To: SCons developer list 
Subject: Re: [Scons-dev] no more print statements in SConscripts?

 

Gary,

Yup. that's expected.

Not sure how to handle this gracefully (besides as Jason suggests some 
"official" messaging API for SCons, which also would require time for users to 
adjust to).

Out of curiosity, would 2to3 resolve the issues you ran into?

(In theory it should)

Other issues might bit chmod bitmasks (though not until they run via py3)

-Bill

 

On Wed, May 25, 2016 at 5:59 AM, Gary Oberbrunner mailto:ga...@oberbrunner.com> > wrote:

Hi folks; I know I've been out of the loop recently, lots going on. Great work 
getting the python 3 stuff in!

 

I did just try the default branch (with python2.7 on Windows) and I notice 
print statements (not the function, just the statement) in 
SConstructs/SConscripts are now syntax errors. This'll probably be a big change 
for users. Just FYI.


 

-- 

Gary


___
Scons-dev mailing list
Scons-dev@scons.org <mailto:Scons-dev@scons.org> 
https://pairlist2.pair.net/mailman/listinfo/scons-dev

 

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Alexandre Feblot]

Tim, yes, I misread you, thanks for the clarification.
Ok, saved for this time.
--
Alexandre Feblot

> Le 26 mai 2016 à 01:24, Tim Jenness  a écrit :
> 
> 
>> On May 25, 2016, at 16:13, Alexandre Feblot  wrote:
>> 
>> 
>> 
>> Obviously, not introducing any "api break" would be the best, but I don't 
>> see where Tim suggests a solution. Tim wrote about "removing print 
>> statements from his SConscripts", which is exactly the painful case I 
>> described.
>> 
> 
> I don’t think I suggested that. I (thought I) was suggesting that the code in 
> scons that loads the SConscript files should not itself include any print 
> statements so that there would be no need to enable print_function in that 
> file.
> 
> For simple prints in that file you also have the option of doing
> 
> print(some_string)
> 
> which works on both 2.7 and 3.x regardless because in 2.7 those parentheses 
> disappear. It’s only when commas start turning up that you need 
> print_function enabled.
> 
> — 
> Tim Jenness
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

> On May 25, 2016, at 16:13, Alexandre Feblot  wrote:
> 
> 
> 
> Obviously, not introducing any "api break" would be the best, but I don't see 
> where Tim suggests a solution. Tim wrote about "removing print statements 
> from his SConscripts", which is exactly the painful case I described.
> 

I don’t think I suggested that. I (thought I) was suggesting that the code in 
scons that loads the SConscript files should not itself include any print 
statements so that there would be no need to enable print_function in that file.

For simple prints in that file you also have the option of doing

print(some_string)

which works on both 2.7 and 3.x regardless because in 2.7 those parentheses 
disappear. It’s only when commas start turning up that you need print_function 
enabled.

— 
Tim Jenness

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Alexandre Feblot]

Well,

It's not specific to this print issue.
This is something which already came up when discussing installation through 
pip and the idea to stop supporting installing multiple scons versions on the 
same machine.
It also almost happened with Dirk changes some times ago (removing path, 
abspath, ...), but we came up with a fix to keep compatible.

It's about how to deal with a scons change breaking a user build system:

Consider a user who has one single scons installed on his server, and who wants 
to use the new scons version requiring updating SConstruct or SConscripts.
As he will be updating the single scons installed on his server, he'll be 
forced to update his SConstruct and SConscripts, not only in his current dev 
branch, but also in all his active maintenance branches. And even after this 
update work, some use cases will remain broken: any time he'll need to checkout 
and rebuild an old tag, this will fail as well, he'll have to fix his 
SConsctruct again. And if this checkout+build is handled automatically from a 
Jenkins, it won't even be possible at all.

On a user perspective, I think this is not acceptable. His only alternative 
would be to stick with his current scons and never update it again.

So, my point is, if the port to python3 requires the use of print(), which I 
can totally understand, the user should have the possibility to use different 
scons versions according to his product versions, whatever the solution is:
- multiple versions installed side by side, selected for example by a 
different PATH
- virtualenv, as Bill wrote.
- build bootstrap which downloads a portable scons install
- 

But a solution must be given and documented if a scons release requires a 
change in users build systems, to keep supporting all old versions of theirs 
products. I obviously speak about my situation here, but I can't imagine I'm 
the only one to have to support years of old versions of my products. And my 
feeling is that without a clear solution to this issue, I can't afford 
upgrading.

Obviously, not introducing any "api break" would be the best, but I don't see 
where Tim suggests a solution. Tim wrote about "removing print statements from 
his SConscripts", which is exactly the painful case I described.

--
Alexandre Feblot

> Le 26 mai 2016 à 00:32, Bill Deegan  a écrit :
> 
> Alexandre,
> 
> the code in Default is not currently released.
> So if you're running against the development code it's always "Buyer beware".
> 
> It seems likely we will be able to resolve the print_function issue as Tim 
> has suggested.
> 
> Additionally, I don't see the need to install multiple versions of a tool on 
> a system as onerous.
> Especially one which can be installed via virtualenv. (once it completely is)
> 
> -Bill
> 
> On Wed, May 25, 2016 at 2:57 PM, Alexandre Feblot  > wrote:
> So, here we are, we get an incompatibility with existing product build 
> systems based on current scons, and thus, the need to support multiple 
> versions of scons installed on the same machine, so we can keep compiling all 
> old maintenance branches and all old tags of our products without having to 
> fix all of them?
> 
>  
> --
> Alexandre Feblot
> 
>> Le 25 mai 2016 à 23:47, Tim Jenness > > a écrit :
>> 
>>> 
>>> On May 25, 2016, at 14:38, Bill Deegan >> > wrote:
>>> 
>>> Tim,
>>> 
>>> Here's the implementation:
>>> https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default&fileviewer=file-view-default#SConscript.py-251
>>>  
>>> 
>>> 
>>> Basically it exec()'s the SConscript as follows:
>>>  <>exec(compile(_file_.read(), _file_.name, 
>>> 'exec'),
>>>  <> call_stack[-1].globals)
>>> 
>>> So given that print_function() is already imported from __future__ at that 
>>> point I don't think we can do a per SConscript exclusion?
>>> 
>> 
>> Right. It compiles a string so print_function is in effect.
>> 
>> I think what I’d do is ban the use of print in that file so that the 
>> print_function directive is not active. There are only two prints in there 
>> so I’d move those two routines to a different file or provide a utility 
>> print routine from somewhere else that those functions use.
>> 
>> — 
>> Tim Jenness
>> 
>> 
>> 
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org 
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
>> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org 
> https://pairlis

Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Alexandre,

the code in Default is not currently released.
So if you're running against the development code it's always "Buyer
beware".

It seems likely we will be able to resolve the print_function issue as Tim
has suggested.

Additionally, I don't see the need to install multiple versions of a tool
on a system as onerous.
Especially one which can be installed via virtualenv. (once it completely
is)

-Bill

On Wed, May 25, 2016 at 2:57 PM, Alexandre Feblot 
wrote:

> So, here we are, we get an incompatibility with existing product build
> systems based on current scons, and thus, the need to support multiple
> versions of scons installed on the same machine, so we can keep compiling
> all old maintenance branches and all old tags of our products without
> having to fix all of them?
>
>
> *--*
> Alexandre Feblot
>
> Le 25 mai 2016 à 23:47, Tim Jenness  a écrit :
>
>
> On May 25, 2016, at 14:38, Bill Deegan  wrote:
>
> Tim,
>
> Here's the implementation:
>
> https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default&fileviewer=file-view-default#SConscript.py-251
>
> Basically it exec()'s the SConscript as follows:
>
> exec(compile(_file_.read(), _file_.name, 'exec'), 
> call_stack[-1].globals)
>
> So given that print_function() is already imported from __future__ at that 
> point I don't think we can do a per SConscript exclusion?
>
>
> Right. It compiles a string so print_function is in effect.
>
> I think what I’d do is ban the use of print in that file so that the
> print_function directive is not active. There are only two prints in there
> so I’d move those two routines to a different file or provide a utility
> print routine from somewhere else that those functions use.
>
> —
> Tim Jenness
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

> On May 25, 2016, at 14:57, Alexandre Feblot  wrote:
> 
> So, here we are, we get an incompatibility with existing product build 
> systems based on current scons, and thus, the need to support multiple 
> versions of scons installed on the same machine, so we can keep compiling all 
> old maintenance branches and all old tags of our products without having to 
> fix all of them?
> 

I’m not entirely sure what you are trying to say. I’m a huge proponent of 
python 3 and print as a function but I thought at issue here was the risk of 
shipping scons v3 to users and having everything break. I assumed there was a 
desire to have current scons users who are happy using scons on their 2.7 
system to continue to be able to use scons without editing all their sconstruct 
files.

I am assuming that people can put “from __future_…” in their SConstruct files 
if they wish to being migrating their scons-usage to modern Python. The Scons 
test suite would have to do that to let things pass on 2.7 and 3.x.

Can we agree that it should be desirable for a current scons user to install v3 
without having to make any changes to their code? If we have no choice but to 
insist on __future__ usage then v3 would be a great time to make that change 
but I’m pretty sure it’s not needed.

— 
Tim Jenness

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Alexandre Feblot]

So, here we are, we get an incompatibility with existing product build systems 
based on current scons, and thus, the need to support multiple versions of 
scons installed on the same machine, so we can keep compiling all old 
maintenance branches and all old tags of our products without having to fix all 
of them?

 
--
Alexandre Feblot

> Le 25 mai 2016 à 23:47, Tim Jenness  a écrit :
> 
>> 
>> On May 25, 2016, at 14:38, Bill Deegan > > wrote:
>> 
>> Tim,
>> 
>> Here's the implementation:
>> https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default&fileviewer=file-view-default#SConscript.py-251
>>  
>> 
>> 
>> Basically it exec()'s the SConscript as follows:
>>  <>exec(compile(_file_.read(), _file_.name, 
>> 'exec'),
>>  <> call_stack[-1].globals)
>> 
>> So given that print_function() is already imported from __future__ at that 
>> point I don't think we can do a per SConscript exclusion?
>> 
> 
> Right. It compiles a string so print_function is in effect.
> 
> I think what I’d do is ban the use of print in that file so that the 
> print_function directive is not active. There are only two prints in there so 
> I’d move those two routines to a different file or provide a utility print 
> routine from somewhere else that those functions use.
> 
> — 
> Tim Jenness
> 
> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org 
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> 
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

> On May 25, 2016, at 14:38, Bill Deegan  wrote:
> 
> Tim,
> 
> Here's the implementation:
> https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default&fileviewer=file-view-default#SConscript.py-251
>  
> 
> 
> Basically it exec()'s the SConscript as follows:
>  <>exec(compile(_file_.read(), _file_.name, 
> 'exec'),
>  <> call_stack[-1].globals)
> 
> So given that print_function() is already imported from __future__ at that 
> point I don't think we can do a per SConscript exclusion?
> 

Right. It compiles a string so print_function is in effect.

I think what I’d do is ban the use of print in that file so that the 
print_function directive is not active. There are only two prints in there so 
I’d move those two routines to a different file or provide a utility print 
routine from somewhere else that those functions use.

— 
Tim Jenness



___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Tim,

Here's the implementation:
https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default&fileviewer=file-view-default#SConscript.py-251

Basically it exec()'s the SConscript as follows:

exec(compile(_file_.read(), _file_.name,
'exec'), call_stack[-1].globals)

So given that print_function() is already imported from __future__ at
that point I don't think we can do a per SConscript exclusion?

-Bill



On Wed, May 25, 2016 at 11:19 AM, Tim Jenness  wrote:

>
> > On May 25, 2016, at 11:16 , Bill Deegan 
> wrote:
> >
> > I think this is a python global flag isn't it?
> > I don't think you can turn it on and off selectively?
> >
>
> It’s per file. If you add
>
> from __future__ import print_function
>
> at the top of your file that file will have print(). Without it the print
> will be a statement. What you can’t do is change print from a statement to
> a function or vice versa in the middle of a file (so that __future__ import
> must be at the top of the file).
>
> I don’t really know how SConstruct files are imported so it may be that
> there is something about the importing that inherits the print_function
> state of the code doing the reading of the file (are they read and then
> evaled?). If they are read and then the string evaluated that might explain
> the problem. If they are imported with importlib then I’m confused.
>
> —
> Tim Jenness
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

> On May 25, 2016, at 11:16 , Bill Deegan  wrote:
> 
> I think this is a python global flag isn't it?
> I don't think you can turn it on and off selectively?
> 

It’s per file. If you add

from __future__ import print_function

at the top of your file that file will have print(). Without it the print will 
be a statement. What you can’t do is change print from a statement to a 
function or vice versa in the middle of a file (so that __future__ import must 
be at the top of the file).

I don’t really know how SConstruct files are imported so it may be that there 
is something about the importing that inherits the print_function state of the 
code doing the reading of the file (are they read and then evaled?). If they 
are read and then the string evaluated that might explain the problem. If they 
are imported with importlib then I’m confused.

— 
Tim Jenness
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Tim,

I think this is a python global flag isn't it?
I don't think you can turn it on and off selectively?

-Bill

On Wed, May 25, 2016 at 11:14 AM, Tim Jenness  wrote:

>
> > On May 25, 2016, at 11:12 , Bill Deegan 
> wrote:
> >
> > Tim,
> >
> > The issue then is that we've migrated the SConstructs/SConscripts in the
> test suite to use print() so we can work on getting py3 also working.
> >
>
> I think those tests can have “from __future__ import print_function” added
> to them and the tests would pass.
>
> My worry is releasing scons v3 and having all the python 2.7 users scream.
> If we can just make it so that the importing code for external files does
> not inherit print_function by default then everyone will be happy.
>
> —
> Tim Jenness
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

> On May 25, 2016, at 11:12 , Bill Deegan  wrote:
> 
> Tim,
> 
> The issue then is that we've migrated the SConstructs/SConscripts in the test 
> suite to use print() so we can work on getting py3 also working.
> 

I think those tests can have “from __future__ import print_function” added to 
them and the tests would pass.

My worry is releasing scons v3 and having all the python 2.7 users scream. If 
we can just make it so that the importing code for external files does not 
inherit print_function by default then everyone will be happy.

— 
Tim Jenness


___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Tim,

The issue then is that we've migrated the SConstructs/SConscripts in the
test suite to use print() so we can work on getting py3 also working.

-Bill

On Wed, May 25, 2016 at 11:11 AM, Tim Jenness  wrote:

> I think “futurize -1 -w SConstruct” would fix everyone’s problems (2.7 is
> the scons minimum version) but it is of course a problem. I don’t know how
> you can tell the scons parser to not enable print_function if it’s running
> in 2.7. Is there a way to disable that __future__ directive for the code
> that is dealing with the SConstruct files?
>
> —
> Tim Jenness
>
> On May 25, 2016, at 11:07 , Bill Deegan  wrote:
>
> Gary,
>
> Yup. that's expected.
> Not sure how to handle this gracefully (besides as Jason suggests some
> "official" messaging API for SCons, which also would require time for users
> to adjust to).
>
> Out of curiosity, would 2to3 resolve the issues you ran into?
> (In theory it should)
>
> Other issues might bit chmod bitmasks (though not until they run via py3)
>
> -Bill
>
> On Wed, May 25, 2016 at 5:59 AM, Gary Oberbrunner 
> wrote:
>
>> Hi folks; I know I've been out of the loop recently, lots going on. Great
>> work getting the python 3 stuff in!
>>
>> I did just try the default branch (with python2.7 on Windows) and I
>> notice print statements (not the function, just the statement) in
>> SConstructs/SConscripts are now syntax errors. This'll probably be a big
>> change for users. Just FYI.
>>
>> --
>> Gary
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Dirk Bächle]

Hi Gary,

On 25.05.2016 14:59, Gary Oberbrunner wrote:

Hi folks; I know I've been out of the loop recently, lots going on. Great work 
getting the python 3 stuff in!

I did just try the default branch (with python2.7 on Windows) and I notice 
print statements (not the function, just the statement)
in SConstructs/SConscripts are now syntax errors. This'll probably be a big 
change for users. Just FYI.



we'd probably have to advise them to use a conversion script like "2to3" on all their SConstructs, right? I'd think this is not too 
much to ask for, if people are really interested in using the Python3 version of SCons...


Regards,

Dirk

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Tim Jenness]

I think “futurize -1 -w SConstruct” would fix everyone’s problems (2.7 is the 
scons minimum version) but it is of course a problem. I don’t know how you can 
tell the scons parser to not enable print_function if it’s running in 2.7. Is 
there a way to disable that __future__ directive for the code that is dealing 
with the SConstruct files?

— 
Tim Jenness

> On May 25, 2016, at 11:07 , Bill Deegan  wrote:
> 
> Gary,
> 
> Yup. that's expected.
> Not sure how to handle this gracefully (besides as Jason suggests some 
> "official" messaging API for SCons, which also would require time for users 
> to adjust to).
> 
> Out of curiosity, would 2to3 resolve the issues you ran into?
> (In theory it should)
> 
> Other issues might bit chmod bitmasks (though not until they run via py3)
> 
> -Bill
> 
> On Wed, May 25, 2016 at 5:59 AM, Gary Oberbrunner  > wrote:
> Hi folks; I know I've been out of the loop recently, lots going on. Great 
> work getting the python 3 stuff in!
> 
> I did just try the default branch (with python2.7 on Windows) and I notice 
> print statements (not the function, just the statement) in 
> SConstructs/SConscripts are now syntax errors. This'll probably be a big 
> change for users. Just FYI.
> 
> -- 
> Gary
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org 
> https://pairlist2.pair.net/mailman/listinfo/scons-dev 
> 
> 
> 
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Bill Deegan]

Gary,

Yup. that's expected.
Not sure how to handle this gracefully (besides as Jason suggests some
"official" messaging API for SCons, which also would require time for users
to adjust to).

Out of curiosity, would 2to3 resolve the issues you ran into?
(In theory it should)

Other issues might bit chmod bitmasks (though not until they run via py3)

-Bill

On Wed, May 25, 2016 at 5:59 AM, Gary Oberbrunner 
wrote:

> Hi folks; I know I've been out of the loop recently, lots going on. Great
> work getting the python 3 stuff in!
>
> I did just try the default branch (with python2.7 on Windows) and I notice
> print statements (not the function, just the statement) in
> SConstructs/SConscripts are now syntax errors. This'll probably be a big
> change for users. Just FYI.
>
> --
> Gary
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] no more print statements in SConscripts?

[Jason Kenny]

I think the issue of print was discussed before. I had stated I had some stuff 
in Parts to deal with this, ie a API for outputting data. I recall someone 
saying make it a library SCons could depend on. I have not finished that but do 
have it underway, latest version is in the work of me separating my testing 
code in Parts into a separate module. If interested you can find the code here:

 

https://bitbucket.org/dragon512/reusable-gold-testing-system/src/4c849613824f70a79d47a5cff61d14ac2a495e4b/src/hosts/?at=master
 

 

The code is not 100% done, as such I have not made it a separate pip 
installable module yet.. but it pretty close.

 

I agree that since SCons does not provide an API for outputting information, 
and SCons have not released a injected print() api for people to migrate to 
this will be a big deal for many people using scons at the moment as there 
scripts will break. We might want to consider this before making a new drop. 
This could be a show stopper for a lot of people.

 

Jason

 

From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Gary 
Oberbrunner
Sent: Wednesday, May 25, 2016 7:59 AM
To: SCons Dev List 
Subject: [Scons-dev] no more print statements in SConscripts?

 

Hi folks; I know I've been out of the loop recently, lots going on. Great work 
getting the python 3 stuff in!

 

I did just try the default branch (with python2.7 on Windows) and I notice 
print statements (not the function, just the statement) in 
SConstructs/SConscripts are now syntax errors. This'll probably be a big change 
for users. Just FYI.


 

-- 

Gary

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] no more print statements in SConscripts?

[Gary Oberbrunner]

Hi folks; I know I've been out of the loop recently, lots going on. Great
work getting the python 3 stuff in!

I did just try the default branch (with python2.7 on Windows) and I notice
print statements (not the function, just the statement) in
SConstructs/SConscripts are now syntax errors. This'll probably be a big
change for users. Just FYI.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev