Mailing List Archive

Re: Python 3.10 Fizzbuzz
On Monday, August 29, 2022 at 7:18:22?PM UTC-7, Paul Rubin wrote:
> Just because.
>
> from math import gcd

> def fizz(n: int) -> str:
> match gcd(n, 15):
> case 3: return "Fizz"
> case 5: return "Buzz"
> case 15: return "FizzBuzz"
> case _: return str(n)
>
> for i in range(1,101):
> print(fizz(i))


is there any reason to prefer " over ' ?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
>
> is there any reason to prefer " over ' ?
>

Not really. As an old C programmer for many years I used double
quotes"around "strings" and single word around 'c'haracters, because that's
what I was used to. (This was long before triple quoted strings appeared in
the language.)

Aside: Given all the various ways to quote strings for display, it irks me
a bit to see repr() still use single quotes in all cases, which requires
display of single quotes to be escaped. (In similar fashion, it would be a
minor improvement in my mind if the repr() code used raw strings where they
would simplify the display.)

Skip

>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
Dang auto-correct... Should read

... double quotes around "strings" and single quotes around 'c'haracters ...

On Sun, Feb 26, 2023, 6:28 PM Skip Montanaro <skip.montanaro@gmail.com>
wrote:

> is there any reason to prefer " over ' ?
>>
>
> Not really. As an old C programmer for many years I used double
> quotes"around "strings" and single word around 'c'haracters, because that's
> what I was used to. (This was long before triple quoted strings appeared in
> the language.)
>
> Aside: Given all the various ways to quote strings for display, it irks me
> a bit to see repr() still use single quotes in all cases, which requires
> display of single quotes to be escaped. (In similar fashion, it would be a
> minor improvement in my mind if the repr() code used raw strings where they
> would simplify the display.)
>
> Skip
>
>>
--
https://mail.python.org/mailman/listinfo/python-list
RE: Python 3.10 Fizzbuzz [ In reply to ]
Only sometimes.

Is it an insult to suggest the question about what quotes to use is quite basic? Python has a wide variety of ways to make a string and if you have text that contains one kind of quote, you can nest it in the other kind. Otherwise, it really does not matter.

And, yes, there are triply quoted strings as well as raw and formatted but to know about these things, you might have to read a manual.

Since you won't, I provided an answer. The answer is that for the meaningless Fizzbuzz homework type of problem which is just ASCII text, it does not matter at all which kind of quote you use as long as what you use matches itself at the end of the string and as long as you use the ASCII versions, not the ones you might make in programs like WORD that have a pair for each.

Oh, by the way, people here use lots of editors to deal with their code including versions derived from vi and emacs and MANY others, so many people here need to be told why you are asking some of your editing questions that do not at first seem to relate. We strive to focus here a bit more on using the language than on how to make your editor do tricks.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Hen Hanna
Sent: Sunday, February 26, 2023 4:07 PM
To: python-list@python.org
Subject: Re: Python 3.10 Fizzbuzz

On Monday, August 29, 2022 at 7:18:22?PM UTC-7, Paul Rubin wrote:
> Just because.
>
> from math import gcd

> def fizz(n: int) -> str:
> match gcd(n, 15):
> case 3: return "Fizz"
> case 5: return "Buzz"
> case 15: return "FizzBuzz"
> case _: return str(n)
>
> for i in range(1,101):
> print(fizz(i))


is there any reason to prefer " over ' ?
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 2/26/23 14:07, Hen Hanna wrote:
> On Monday, August 29, 2022 at 7:18:22?PM UTC-7, Paul Rubin wrote:
>> Just because.
>>
>> from math import gcd
>
>> def fizz(n: int) -> str:
>> match gcd(n, 15):
>> case 3: return "Fizz"
>> case 5: return "Buzz"
>> case 15: return "FizzBuzz"
>> case _: return str(n)
>>
>> for i in range(1,101):
>> print(fizz(i))
>
>
> is there any reason to prefer " over ' ?

If you intend to run Black on your code to ensure consistent formatting,
you may as well learn to prefer double quotes, because it's going to
convert single to double (or: don't learn, and set your IDE to "convert
on save" and don't think about it...)

As has already been mentioned, syntactically there is no difference.



--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 2/27/2023 11:01 AM, Mats Wichmann wrote:
> On 2/26/23 14:07, Hen Hanna wrote:
>> On Monday, August 29, 2022 at 7:18:22?PM UTC-7, Paul Rubin wrote:
>>> Just because.
>>>
>>> from math import gcd
>>
>>> def fizz(n: int) -> str:
>>>         match gcd(n, 15):
>>>                case 3: return "Fizz"
>>>                case 5: return "Buzz"
>>>                case 15: return "FizzBuzz"
>>>                case _: return str(n)
>>>
>>> for i in range(1,101):
>>>              print(fizz(i))
>>
>>
>> is there any reason to prefer    "    over    '   ?
>
> If you intend to run Black on your code to ensure consistent formatting,
> you may as well learn to prefer double quotes, because it's going to
> convert single to double (or: don't learn, and set your IDE to "convert
> on save" and don't think about it...)
>
> As has already been mentioned, syntactically there is no difference.

I prefer single quotes because they are easier to type.

--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On Mon, 27 Feb 2023 11:08:22 -0500, Thomas Passin wrote:

> I prefer single quotes because they are easier to type.

There is that. JavaScript makes me lazy and C# slaps my knuckles with a
steel edged ruler.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On Mon, 27 Feb 2023 09:01:26 -0700, Mats Wichmann wrote:


> If you intend to run Black on your code to ensure consistent formatting,
> you may as well learn to prefer double quotes, because it's going to
> convert single to double (or: don't learn, and set your IDE to "convert
> on save" and don't think about it...)

I'd never heard of Black.

"By using Black, you agree to cede control over minutiae of hand-
formatting. In return, Black gives you speed, determinism, and freedom
from pycodestyle nagging about formatting. You will save time and mental
energy for more important matters."

Somehow I don't think we would get along very well. I'm a little on the
opinionated side myself.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 2/27/23 12:20, rbowman wrote:

> "By using Black, you agree to cede control over minutiae of hand-
> formatting. In return, Black gives you speed, determinism, and freedom
> from pycodestyle nagging about formatting. You will save time and mental
> energy for more important matters."
>
> Somehow I don't think we would get along very well. I'm a little on the
> opinionated side myself.

I personally cannot stand Black. It feels like every major choice it makes (and some minor ones) are exactly the
opposite of the choice I make.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On Mon, 27 Feb 2023 at 21:06, Ethan Furman <ethan@stoneleaf.us> wrote:
>
> On 2/27/23 12:20, rbowman wrote:
>
> > "By using Black, you agree to cede control over minutiae of hand-
> > formatting. In return, Black gives you speed, determinism, and freedom
> > from pycodestyle nagging about formatting. You will save time and mental
> > energy for more important matters."
> >
> > Somehow I don't think we would get along very well. I'm a little on the
> > opinionated side myself.
>
> I personally cannot stand Black. It feels like every major choice it makes (and some minor ones) are exactly the
> opposite of the choice I make.

I agree partially. There are two types of decisions black makes:

1. Leave the code alone because it seems okay or make small modifications.
2. Reformat the code because it violates some generic rule (like line
too long or something).

I've recently tried Black and mostly for my code it seems to go with 1
(code looks okay). There might be some minor changes like double vs
single quotes but I really don't care about those. In that sense me
and Black seem to agree.

However I have also reviewed code where it is clear that the author
has used black and their code came under case 2. In that case Black
seems to produce awful things. What I can't understand is someone
accepting the awful rewrite rather than just fixing the code. Treating
Black almost like a linter makes sense to me but accepting the
rewrites that it offers for bad code does not.

--
Oscar
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 28/02/23 5:08 am, Thomas Passin wrote:
> On 2/27/2023 11:01 AM, Mats Wichmann wrote:
>> If you intend to run Black on your code to ensure consistent
>> formatting, you may as well learn to prefer double quotes, because
>> it's going to convert single to double
>
> I prefer single quotes because they are easier to type.

I tend to use the convention of double quotes for strings seen
by the outside world, and single quotes for internal constants
(such as enumerated types that happen to be represented by
strings).

I guess this means I can't use Black. :-(

--
Greg

--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 27/02/2023 21:04, Ethan Furman wrote:
> On 2/27/23 12:20, rbowman wrote:
>
> > "By using Black, you agree to cede control over minutiae of hand-
> > formatting. In return, Black gives you speed, determinism, and freedom
> > from pycodestyle nagging about formatting. You will save time and
> mental
> > energy for more important matters."
> >
> > Somehow I don't think we would get along very well. I'm a little on the
> > opinionated side myself.
>
> I personally cannot stand Black.  It feels like every major choice it
> makes (and some minor ones) are exactly the opposite of the choice I
> make.
>
> --
> ~Ethan~
I've never tried Black or any other code formatter, but I'm sure we
wouldn't get on.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 28/02/2023 12.55, Rob Cliffe via Python-list wrote:
>
>
> On 27/02/2023 21:04, Ethan Furman wrote:
>> On 2/27/23 12:20, rbowman wrote:
>>
>> > "By using Black, you agree to cede control over minutiae of hand-
>> > formatting. In return, Black gives you speed, determinism, and freedom
>> > from pycodestyle nagging about formatting. You will save time and
>> mental
>> > energy for more important matters."
>> >
>> > Somehow I don't think we would get along very well. I'm a little on the
>> > opinionated side myself.
>>
>> I personally cannot stand Black.  It feels like every major choice it
>> makes (and some minor ones) are exactly the opposite of the choice I
>> make.
>>
>> --
>> ~Ethan~
> I've never tried Black or any other code formatter, but I'm sure we
> wouldn't get on.

Does this suggest, that because Black doesn't respect other people's
opinions and feelings, that it wouldn't meet the PSF's Code of Conduct?

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On Wed, 1 Mar 2023 at 06:25, dn via Python-list <python-list@python.org> wrote:
>
> On 28/02/2023 12.55, Rob Cliffe via Python-list wrote:
> >
> >
> > On 27/02/2023 21:04, Ethan Furman wrote:
> >> On 2/27/23 12:20, rbowman wrote:
> >>
> >> > "By using Black, you agree to cede control over minutiae of hand-
> >> > formatting. In return, Black gives you speed, determinism, and freedom
> >> > from pycodestyle nagging about formatting. You will save time and
> >> mental
> >> > energy for more important matters."
> >> >
> >> > Somehow I don't think we would get along very well. I'm a little on the
> >> > opinionated side myself.
> >>
> >> I personally cannot stand Black. It feels like every major choice it
> >> makes (and some minor ones) are exactly the opposite of the choice I
> >> make.
> >>
> >> --
> >> ~Ethan~
> > I've never tried Black or any other code formatter, but I'm sure we
> > wouldn't get on.
>
> Does this suggest, that because Black doesn't respect other people's
> opinions and feelings, that it wouldn't meet the PSF's Code of Conduct?
>

Yes, so if Black ever posts on this list, it will probably get banned...

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Python 3.10 Fizzbuzz [ In reply to ]
> > I've never tried Black or any other code formatter, but I'm sure we
> > wouldn't get on.
>
> Does this suggest, that because Black doesn't respect other people's
> opinions and feelings, that it wouldn't meet the PSF's Code of Conduct?

That much depends on The Measure Of A Man.

Karsten
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 2/27/23 16:42, Oscar Benjamin wrote:
> On Mon, 27 Feb 2023 at 21:06, Ethan Furman <ethan@stoneleaf.us> wrote:
>>
>> On 2/27/23 12:20, rbowman wrote:
>>
>> > "By using Black, you agree to cede control over minutiae of hand-
>> > formatting. In return, Black gives you speed, determinism, and freedom
>> > from pycodestyle nagging about formatting. You will save time and mental
>> > energy for more important matters."
>> >
>> > Somehow I don't think we would get along very well. I'm a little on the
>> > opinionated side myself.
>>
>> I personally cannot stand Black. It feels like every major choice it makes (and some minor ones) are exactly the
>> opposite of the choice I make.
>
> I agree partially. There are two types of decisions black makes:
>
> 1. Leave the code alone because it seems okay or make small modifications.
> 2. Reformat the code because it violates some generic rule (like line
> too long or something).
>
> I've recently tried Black and mostly for my code it seems to go with 1
> (code looks okay). There might be some minor changes like double vs
> single quotes but I really don't care about those. In that sense me
> and Black seem to agree.
>
> However I have also reviewed code where it is clear that the author
> has used black and their code came under case 2. In that case Black
> seems to produce awful things. What I can't understand is someone
> accepting the awful rewrite rather than just fixing the code. Treating
> Black almost like a linter makes sense to me but accepting the
> rewrites that it offers for bad code does not.

The amount of disagreement you see here and elsewhere are exactly why
Black is like it is - virtually without options. It doesn't aim to
solve the challenge of producing The Most Beautiful Code Layout, for
*you*, or even for any moderately sized group of programmers. Instead
it's to remove the bickering:
1. we choose to use black for a project.
2. black runs automatically
3. there is now no need to spend cycles thinking about code-style
aspects in reviews, or when we're making changes, because black makes
sure the code aligns with the chosen style (1).

Many teams find the removal of this potential disagreement valuable -
there's plenty of more important stuff to spend time on. If as an
individual user, not trying to conform to style choices of a project, it
doesn't appeal, there's no need to fuss with it.

One can certainly pick a different code style, and make sure it's
captured in the rules for one of the several more flexible formatting
tools (for example, I *used* to use yapf pretty regularly, and had that
tuned as I wanted)
--
https://mail.python.org/mailman/listinfo/python-list
RE: Python 3.10 Fizzbuzz [ In reply to ]
Dave,

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.

I, for example, like certain features in many languages where if I am only doing one short line of code, I prefer to skip the fanfare. Consider an (non-python)

If (condition) {
print(5)
}

Who needs that nonsense? If the language allows it:

If (condition) print(5)

Or in python:

If condition: print(5)

Rather than a multi-line version.

But will I always use the short version? Nope. If I expect to add code later, might as well start with the multi-line form. If the line gets too long, ditto. And, quite importantly, if editing other people's code, I look around and follow their lead.

There often is no (one) right way to do things but there often are many wrong ways. Tools like black (which I know nothing detailed about) can be helpful. But I have experience times when I wrote carefully crafted code (as it happens in R inside the RSTUDIO editor) and selected a region and asked it to reformat, and gasped at how it ruined my neatly arranged code. I just wanted the bit I had added to be formatted the same as the rest already was, not a complete re-make. Luckily, there is an undo.

There must be some parameterized tools out there that let you set up a profile of your own personal preferences that help keep your code in your own preferred format, and re-arrange it after you have done some editing like copying from somewhere else so it fits together.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of dn via Python-list
Sent: Tuesday, February 28, 2023 2:22 PM
To: python-list@python.org
Subject: Re: Python 3.10 Fizzbuzz

On 28/02/2023 12.55, Rob Cliffe via Python-list wrote:
>
>
> On 27/02/2023 21:04, Ethan Furman wrote:
>> On 2/27/23 12:20, rbowman wrote:
>>
>> > "By using Black, you agree to cede control over minutiae of hand-
>> > formatting. In return, Black gives you speed, determinism, and
>> > freedom from pycodestyle nagging about formatting. You will save
>> > time and
>> mental
>> > energy for more important matters."
>> >
>> > Somehow I don't think we would get along very well. I'm a little on
>> > the opinionated side myself.
>>
>> I personally cannot stand Black. It feels like every major choice it
>> makes (and some minor ones) are exactly the opposite of the choice I
>> make.
>>
>> --
>> ~Ethan~
> I've never tried Black or any other code formatter, but I'm sure we
> wouldn't get on.

Does this suggest, that because Black doesn't respect other people's opinions and feelings, that it wouldn't meet the PSF's Code of Conduct?

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list
RE: Re: Python 3.10 Fizzbuzz [ In reply to ]
Karsten,

Would it be OK if we paused this discussion a day till February is History?

Sarcasm aside, I repeat, the word black has many unrelated meanings as
presumably this case includes. And for those who do not keep close track of
the local US nonsense, February has for some reason been dedicated to be a
National Black History Month.

Can software violate a code for human conduct? The recent AI news suggests
it does! LOL!

But you know, if you hire a program to tell you if your code passes a
designated series of tests and it just points out where they did not, and
suggest changes that may put you in alignment, that by itself is not
abusive. But if you did not ask for their opinion, yes, it can be annoying
as being unsolicited.

Humans can be touchy and lose context. I have people in my life who
magically ignore my carefully thought-out phrases like "If ..." by acting as
if I had said something rather than IF something. Worse, they hear
abstractions too concretely. I might be discussing COVID and saying "If
COVID was a lethal as it used to be ..." and they interject BUT IT ISN'T.
OK, listen again. I am abstract and trying to make a point. The fact that
you think it isn't is nice to note but hardly relevant to a WHAT IF
question.

So a program designed by programmers, a few of whom are not well known for
how they interact with humans but who nonetheless insist on designed user
interfaces by themselves, may well come across negatively. The reality is
humans vary tremendously and one may appreciate feedback as a way to improve
and get out of the red and the other will assume it is a put down that
leaves them black and blue, even when the words are the same.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On
Behalf Of Karsten Hilbert
Sent: Tuesday, February 28, 2023 2:44 PM
To: PythonList@DancesWithMice.info
Cc: python-list@python.org
Subject: Aw: Re: Python 3.10 Fizzbuzz

> > I've never tried Black or any other code formatter, but I'm sure we
> > wouldn't get on.
>
> Does this suggest, that because Black doesn't respect other people's
> opinions and feelings, that it wouldn't meet the PSF's Code of Conduct?

That much depends on The Measure Of A Man.

Karsten
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On Tue, 28 Feb 2023 at 20:55, Mats Wichmann <mats@wichmann.us> wrote:
>
> On 2/27/23 16:42, Oscar Benjamin wrote:
> > On Mon, 27 Feb 2023 at 21:06, Ethan Furman <ethan@stoneleaf.us> wrote:
> >>
> >> On 2/27/23 12:20, rbowman wrote:
> >>
> >> > "By using Black, you agree to cede control over minutiae of hand-
> >> > formatting. In return, Black gives you speed, determinism, and freedom
> >> > from pycodestyle nagging about formatting. You will save time and mental
> >> > energy for more important matters."
> >> >
> >> > Somehow I don't think we would get along very well. I'm a little on the
> >> > opinionated side myself.
> >>
> >> I personally cannot stand Black. It feels like every major choice it makes (and some minor ones) are exactly the
> >> opposite of the choice I make.
> >
> > I agree partially. There are two types of decisions black makes:
> >
> > 1. Leave the code alone because it seems okay or make small modifications.
> > 2. Reformat the code because it violates some generic rule (like line
> > too long or something).
> >
> > I've recently tried Black and mostly for my code it seems to go with 1
> > (code looks okay). There might be some minor changes like double vs
> > single quotes but I really don't care about those. In that sense me
> > and Black seem to agree.
> >
> > However I have also reviewed code where it is clear that the author
> > has used black and their code came under case 2. In that case Black
> > seems to produce awful things. What I can't understand is someone
> > accepting the awful rewrite rather than just fixing the code. Treating
> > Black almost like a linter makes sense to me but accepting the
> > rewrites that it offers for bad code does not.
>
> The amount of disagreement you see here and elsewhere are exactly why
> Black is like it is - virtually without options. It doesn't aim to
> solve the challenge of producing The Most Beautiful Code Layout, for
> *you*, or even for any moderately sized group of programmers. Instead
> it's to remove the bickering:
> 1. we choose to use black for a project.
> 2. black runs automatically
> 3. there is now no need to spend cycles thinking about code-style
> aspects in reviews, or when we're making changes, because black makes
> sure the code aligns with the chosen style (1).

The problem is that although Black runs automatically it doesn't solve
the code problems automatically. Instead it takes something
questionable and produces something worse. If Black just rejected the
author's code and told them to write something better then they
probably would produce something better than what Black produces.

The limitation of Black is that it only reformats but usually at the
point when it does that the option of reformatting is not really the
thing that needs doing. Instead the right option is something like
introducing a new variable to split one statement into two but Black
just goes ahead and reformats without considering that option.

I'm fine with not arguing about what kinds of quotes to use but that
doesn't mean that I'll accept any output from Black without arguing
about the code being improved.

--
Oscar
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On Tue, Feb 28, 2023 at 04:05:19PM -0500, avi.e.gross@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.

Simon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 2023-03-01, Simon Ward <simon+python@bleah.co.uk> wrote:
> On Tue, Feb 28, 2023 at 04:05:19PM -0500, avi.e.gross@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
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 1 Mar 2023 11:28:12 GMT, Stefan Ram wrote:


> IIRC, I've heard of professional video monitors which are set to
> standard values for color saturation, contrast, and brightness. They
> have no way to adjust these values, although they are more expensive
> than normal screens.

Probably a good thing. In the early days of color TV the color values were
user adjustable. A generation grew up thinking Lorne Greene (Bonanza) had
a slightly green complexion to match his name.

--
https://mail.python.org/mailman/listinfo/python-list
RE: Python 3.10 Fizzbuzz [ In reply to ]
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@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+python@bleah.co.uk> wrote:
> On Tue, Feb 28, 2023 at 04:05:19PM -0500, avi.e.gross@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
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 28Feb2023 12:54, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>I guess this means I can't use Black. :-(

Black's treatment of quotes and docstrings is one of the largest reasons
why I won't let it touch my personal code. yapf is far better behaved,
and can be tuned as well!

Cheers,
Cameron Simpson <cs@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.10 Fizzbuzz [ In reply to ]
On 26Feb2023 13:07, Hen Hanna <henhanna@gmail.com> wrote:
>is there any reason to prefer " over ' ?

Not inherently.

It is only important if you want to embed one of those characters in a
string, eg:

x = "That's silly."

versus:

x = 'That\'s silly.'

and the converse for the other quote character.

Cheers,
Cameron Simpson <cs@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list

1 2  View All