Python 3.10 Fizzbuzz

Wed Mar 1 12:48:34 EST 2023

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.com at python.org> On
Behalf Of Jon Ribbens via Python-list
Sent: Wednesday, March 1, 2023 6:48 AM
To: python-list at python.org
Subject: Re: Python 3.10 Fizzbuzz

On 2023-03-01, Simon Ward <simon+python at bleah.co.uk> wrote:
> On Tue, Feb 28, 2023 at 04:05:19PM -0500, avi.e.gross at 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