This discussion has veered a bit, as it often does, but does raise interesting points about programming in general and also in python.
We seem to be able to easily cite examples where a group of things is lumped for convenience and people end up using them but then tweaking them. S an example, the ggplot2 package in R (a version is available in python) does graphics with some defaults and you can add-in themes that set internal aspects of the object including many that allow you to see what the background of the graph looks like. One common need was to remove color for printing in a black/white situation so someone created a theme_bw() you could call that sets the parameters deemed appropriate. The background can include many things including crosshatchings that can be tweaked independently. Some people thought the theme_bw() was not pleasing and figured out how to tweak a few things after calling it and next thing we know, someone packages a new set and calls it theme_gray(), theme_minimal(), theme_dark(), theme_void() and, of course, theme_classic(). But using more than one of these in a row can be both wasteful and puzzling. The last one is selectively over-riding a data-structure in parts with some changes to the same spot the previous one created or modified and some not. So we have what I consider layers of bundling and abstraction, as is common in many object-oriented programs and quite subtle bugs that can happen when you cannot see inside a black box, or don't know you need to. I often created a graph where I tweaked a few things by myself and got the nice graph I wanted. Then I was asked to not make that nice colorful graph because they could not see it as nicely when printed without color. Simple enough, I added theme_bw() or something at the end of a sort of pipeline and indeed it drained all the color out but did more than I wanted. It also happened to reset something I had crafted that did not really have anything to do with color. To get it to work, I had to rearrange my pipeline and place my changes after theme_bw(). This does not mean the people who created a sort of "standard" were wrong. It means using their standard carelessly can have unanticipated results. Examples like this are quite common but the key is that use of these things is not mandated and you can roll your own if you wish. When you look at our discussion of the computer program called "black" it seems the fault, if any, is in the organization that makes use of it mandatory and inflexible, and even has it change your code for you without any easy way to ... I am guessing that quite a few "black" options chosen are nearly universally agreed upon. A few may be vehemently opposed. And some seem random like the 88 columns one. The standard computer terminals in days of yore (does anyone still use them?) did often have exactly 80 columns frequently. But as the years rolled on, we had windowed machines with no fixed sizes for windows and even often support for different font sizes. We have scroll abilities often built in so often long lines do not wrap but you can scroll to see the rest. And much of our software no longer uses constant fixed length buffers and can adapt the moment a window is resized and much more. And dare I mention we are now getting programs written that no human is expected to read and often is written by a program and eventually more like by an AI. Have you tried to read the HTML with embedded compressed JavaScript in a browser window that is not formatted for human consumption but uses less resources to transmit? I am trying to imagine the output from something like evaluating a complex Regular Expression if written down as code in python rather than a sort of compiled form mainly using C. Is there any reason it would not sometimes dive deeply into something line many nested layers of IF statements. By Python rules, every level has to be indented a minimal amount. If black insisted on say 4 spaces, you could easily exceed the ability to write anything on a line as you are already past the 88th column. I doubt black can fix something like this. It is perfectly valid to have arbitrarily nested concepts like this in many places, including something like a JSON representation of a structure. But it is no longer always reasonable to simply ask programmers to let you select your own changes and options for something like black except in limited ways. Allowing shortening line length to 80 may be harmless. Allowing it to be set to unlimited, maybe not. Aspects may interact with others in ways you are not aware of. As an experiment, this message has hat noting external copied/pasted into it. I am wondering if people who see my text oddly but only sometimes, may be seeing what happens when I copy a segment with a different hidden line ending that is maintained by my editor. Truly this illustrates why having two standards may not be optimal and result in chaos. -----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail....@python.org> On Behalf Of Jon Ribbens via Python-list Sent: Wednesday, March 1, 2023 6:48 AM To: python-list@python.org Subject: Re: Python 3.10 Fizzbuzz On 2023-03-01, Simon Ward <simon+pyt...@bleah.co.uk> wrote: > On Tue, Feb 28, 2023 at 04:05:19PM -0500, avi.e.gr...@gmail.com wrote: >>Is it rude to name something "black" to make it hard for some of us to >>remind them of the rules or claim that our personal style is so often >>the opposite that it should be called "white" or at least shade of >>gray? >> >>The usual kidding aside, I have no idea what it was called black but >>in all seriousness this is not a black and white issue. Opinions may >>differ when a language provides many valid options on how to write >>code. If someone wants to standardize and impose some decisions, fine. >>But other may choose their own variant and take their chances. > > https://pypi.org/project/grey/ > https://pypi.org/project/white/ > https://pypi.org/project/blue/ > https://pypi.org/project/oitnb/ > >:o > > It amuses me that opinionated formatter, with very little > configurability by design, in the face of differing opinions just > results in forks or wrappers that modify the behaviours that might > otherwise have been configuration options. The mysterious bit is that two of the above projects do nothing except change the default of the one configuration option that *does* exist (line length). I mean, "black"'s line-length choice of 88 is insane, but I don't see the point of creating new pypi projects that do nothing except run another project with a single option set! -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
