lkml.org 
[lkml]   [2022]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 6/7] perf jevents: Switch build to use jevents.py
On Fri, May 13, 2022 at 8:38 AM John Garry <john.garry@huawei.com> wrote:
>
> On 11/05/2022 22:15, Ian Rogers wrote:
> > # jevents.py uses os.scandir and type hints present in Python 3.5 released in Sept. 2015.
> > + JEVENTS_PYTHON_GOOD := $(shell $(PYTHON) -c 'import sys;print("1" if(sys.version_info.major >= 3 and sys.version_info.minor >= 5) else "0")')
>
> I think that many - like me - will have python 2.7, so now will find no
> pmu-events generated any longer after missing this message in the build :(
>
> Maybe many will have python >= 3.5 - but I don't know...

So Python 2 has been end-of-life for over 2 years now:
https://www.python.org/doc/sunset-python-2/
There have been a number of LKML patches upgrading python to version 3.

Python 3.5 has some very nice features of os.scandir and type hints,
so if I set the bar lower than this it hurts the code quality. It is
also at least 6 years old at this point, and so hopefully not
unreasonable for a distribution to have picked it up :-) Looking at
the change to C11 thread:
https://lore.kernel.org/lkml/20220228103142.3301082-1-arnd@kernel.org/
It seems the motivation for picking a language version is the features
it provides and compatibility. If we choose pre-Python 3.5 we get more
compatibility but we lose language features.

My feeling is that we shouldn't need to support things that are no
longer maintained (like Python 2) but I'm less clear if Python 3.5 is
sufficiently compatible for everyone's needs. I kind of hope so, hence
making the patches this way.

> > + ifneq ($(JEVENTS_PYTHON_GOOD), 1)
> > + $(warning Python interpreter too old (older than 3.5) disabling
> jevent generation)
> > + NO_JEVENTS := 1
>
> It is possible to flip NO_JEVENTS to be JEVENTS, i.e. no
> double-negatives, like NO_JEVENTS := 0

Agreed that double negatives are bad. The NO_... pattern is kind of
throughout the make files and build files. I preferred the NO_... for
consistency but if there's a consensus I'm happy to change.

Thanks,
Ian

> > + endif
>
> Thanks,
> John

\
 
 \ /
  Last update: 2022-05-13 18:00    [W:1.257 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site