On Fri, Mar 29, 2024 at 12:54:12PM +0100, Darshit Shah wrote: > 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.
Python is more Lisp than C, in fact. So using it in a Lisp way should be less of a problem than using it in a C (or, I'd say, Fortran) way. (One can argue it's a Lisp with Algol-like syntax and poor garbade collector :-)) As well, the programming language-wise demographics of GNU contributors is changing, just due to the fact that Python has not been very popular 15 years ago, but since then it's hard to find a programmer who's less than 35 years old and had no exposure to Python. To future-proof Python code in GNU lib, it seems reasonable for it to be sufficiently standard Python. Best, Dima > > 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 >
