Hi Bruno, I think you make some fair points on the contributions made by people with a passable knowledge of the language. However, when I said "maintained", I kind of assumed that there will be someone with a good enough command over the language who will be the arbiter of what patches get applied. Kind of like how you are currently the arbiter of how gnulib-tool is maintained because of your extensive knowledge of Bash and various portability concerns.
Such a maintainer could help clean up the patches when needed. My argument on wanting to stick with a more "pythonic" way of doing things comes from experience of having made the exact same choice long back and seeing with the power of hindsight how it affected things. The only reason the test suite in Wget is in a decent state right now, is we eventually got a contributor who modified quite a bit of it to be more Pythonic. The other reason is that, the way something is stable and maintainable in the long term is if you leverage the strengths of that language. Just as you wouldn't attempt to write bash in a lisp-like fashion because a lot of GNU contributors are well versed with Lisp, you shouldn't attempt to write Python in a C-like fashion. You mention, wanting a programmer to be able to make changes like the commit you linked. I will say, I have a lot of faith in the developers who'd like to make commits like that and that they would be able to infer how to do it based on the examples around it pretty fast :-) I will however concede that modern Python has a lot of syntactic sugar which in a way detracts from Python's original charm of being extremely easy to read and parse. So if we for example end up using complex generators and comprehensions, it will make it hard for a lot of people to follow. Maybe there's a balance we can tread there? P.S.: For those who'd like, there's a great Easter Egg in Python: `import this`, which prints the "Zen of Python". Rules I think are great for programming in general. On Wed, Mar 27, 2024, at 23:50, Bruno Haible wrote: > Hi Darshit, > >> > - Can someone with little exposure to Python understand and modify the >> > code? When you write 'list' and the developer knows that 'list' means >> > what is known as "array" in other programming languages, they can work >> > with the code. Using the abstract interfaces that Python has does not >> > help in this aspect. >> >> I would argue against this line of thinking. Sure, keep it simple, but don't >> reduce the subset of Python available only to something that is easily known >> to, for e.g. a C developer. I made the same decision when writing the >> testsuite for Wget almost 10 years ago, and in hindsight I regret it. >> >> The thing is, when you restrict it something that can be understood by >> someone with little exposure to Python, you end up with a codebase that is >> alien to both groups, the ones that know Python and the ones that don't. You >> get a codebase that neither enjoy working with and want to maintain. > > An interesting thought. > > But the problem is that in GNU, with its traditional focus on C and bash > scripting, "the ones that know Python" are a minority and "the ones that > don't" > are the majority. > > I want that someone with little knowledge of Python is able to make a > commit > like this one: > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=29441fd7bc60ec6010e64f5e8b702c4b6290cec4 > without needing to learn the ins and outs of regular expressions in > Python. > >> Instead, I would argue that following the standard Python best practices >> is a better choice. The person maintaining the script needs to be a Python >> developer anyways. > > No, that does not match reality. A significant portion of development gets > done by people who have not much experience with the specific language or > technology. > > When I look at my own skills [1] and what I have been doing with them: > - I'm writing TeXinfo manuals, although I have only base knowledge of > TeXinfo. > - I'm co-authoring gnulib-tool.py with only base knowledge of Python. > - When I wrote CLN, I had only little prior experience with C++. > - I wrote a bunch of TypeScript code with just 2 weeks of exposure to > TypeScript. > - Two weeks ago, I wrote a Bison parser for something; that was > probably only > my 3rd use of Bison ever, and I had beginner's problems. > - Today, I'm considering writing code for a disk-files-based hash table > and realize that I have zero knowledge or experience about it. > > In summary: People write a *lot* of useful code and contributions at a moment > when they still only have base knowledge. > > Please fill in your own skills set on Savannah [2]; I bet you will find that > the same observation will hold true for yourself. > > Bruno > > [1] https://savannah.gnu.org/people/resume.php?user_id=1871 > [2] https://savannah.gnu.org/users/darnir
