[U-Boot] [RFC PATCH v2 0/2] Make Python scripts compatible with older versions

[Stephen Warren]

On 08/07/2014 10:57 AM, Tom Rini wrote:
> On Thu, Aug 07, 2014 at 04:17:21PM +0300, Igor Grinberg wrote:
>> On 08/07/14 13:57, Tom Rini wrote:
..
>>> we just need
>>> /usr/bin/env python2 as how we invoke our scripts.
>>
>> This means impose python version dependency for U-Boot source build?
>> Correct me if you think I'm wrong, but I don't think this is a good
>> practice...
>> I think that for tools like buildman, patman, etc. - this is
>> perfectly fine to impose an interpreter/compiler version, but not
>> for the basic source builds.
>
> I agree.  You don't need MAKEALL or buildman to do basic source builds.
> Doing 'make foo_defconfig' doesn't require re-creating boards.cfg.
>
> To me, the gray area is people doing SoC level (or higher) changes that
> want to be good and test more areas.  That's when MAKEALL or buildman
> become handy and some sort of win over a shell forloop.

Why on earth isn't relying specifically on either Python2 (with the 
current script code) or Python3 (after porting the code) a good practice?

There was a major release of the language, and the language changed. 
Such a change is just like any other scripting language. Scripts written 
for one particular version of the language should specify python2 or 
python3 not just python in their #! line. Problem solved.

For now at least, all distros I know of provide both python2 and 
python3, so there's no issue doing this. In N years when there's only 
python3 available, I assumed the scripts would be updated, in the same 
way we use new C features (e.g. bool) and drop support for older tools 
of other kinds.

Banning or replacing the use of Python just because they cleaned up 
their language seems like poking your eye out to spite your nose (or 
whatever the expression is). The same thing will happen with Perl, and 
happened with dtc, etc.