Re: Python 3.10 Fizzbuzz

[Keith Thompson]

Greg Ewing  writes:
> On 2/03/23 10:59 am, gene heskett wrote:
>> Human skin always has the same color
>
> Um... no?

You took that out of context.  The assertion was that "Human skin
always has the same color" and "the difference is not the color,
but the brightness".  I offer no opinion on whether that's accurate.

-- 
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.10 Fizzbuzz

[gene heskett]

On 3/1/23 20:28, Greg Ewing via Python-list wrote:

On 2/03/23 10:59 am, gene heskett wrote:

Human skin always has the same color


Um... no?

Yes, only the intensity of the color changes, the vector angle remains 
the same within a degree or so.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

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

Re: Python 3.10 Fizzbuzz

[Greg Ewing via Python-list]

On 2/03/23 10:59 am, gene heskett wrote:

Human skin always has the same color


Um... no?

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

Re: Python 3.10 Fizzbuzz

[Cameron Simpson]

On 26Feb2023 13:07, Hen Hanna  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 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.10 Fizzbuzz

[Cameron Simpson]

On 28Feb2023 12:54, Greg Ewing  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 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.10 Fizzbuzz

[gene heskett]

On 3/1/23 11:41, rbowman wrote:

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.

Chuckle. That was back in what we called Never Twice Same Color days. 
NTSC IOW. I'm a retired tv Chief Engineer and we as broadcasters always 
had a vectorscope in front of the operator so he could adjust the color 
if it wasn't right. Even if he was color blind! Human skin always has 
the same color and it makes an excellent image on the vectorscope at a 
certain angle. And it does not change that angle when the camera 
switches from my white caucasian face to the blackest basketball or 
football players, the difference is not the color, but the brightness.
A lesson I've had to demo to every colored person we ever hired by 
showing him both of us on camera.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

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

RE: Python 3.10 Fizzbuzz

[avi.e.gross]

inal Message-
From: Python-list  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  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

Re: Python 3.10 Fizzbuzz

[rbowman]

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

[Jon Ribbens via Python-list]

On 2023-03-01, Simon Ward  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

Re: Python 3.10 Fizzbuzz

[Simon Ward]

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.


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

Re: Python 3.10 Fizzbuzz

[Oscar Benjamin]

On Tue, 28 Feb 2023 at 20:55, Mats Wichmann  wrote:
>
> On 2/27/23 16:42, Oscar Benjamin wrote:
> > On Mon, 27 Feb 2023 at 21:06, 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.
> >
> > 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: Re: Python 3.10 Fizzbuzz

[avi.e.gross]

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  On
Behalf Of Karsten Hilbert
Sent: Tuesday, February 28, 2023 2:44 PM
To: pythonl...@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

[avi.e.gross]

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  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: Python 3.10 Fizzbuzz

[Mats Wichmann]

On 2/27/23 16:42, Oscar Benjamin wrote:

On Mon, 27 Feb 2023 at 21:06, 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.


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

Aw: Re: Python 3.10 Fizzbuzz

[Karsten Hilbert]

> > 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

[Chris Angelico]

On Wed, 1 Mar 2023 at 06:25, dn via Python-list  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

Re: Python 3.10 Fizzbuzz

[dn via Python-list]

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

[Rob Cliffe via Python-list]

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

[Greg Ewing via Python-list]

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

[Oscar Benjamin]

On Mon, 27 Feb 2023 at 21:06, 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.

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

[Ethan Furman]

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

[rbowman]

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

[rbowman]

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

[Thomas Passin]

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

[Mats Wichmann]

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

[avi.e.gross]

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  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

[Skip Montanaro]

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 
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

[Skip Montanaro]

>
> 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

[Hen Hanna]

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