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 ' ?
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
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 ' ?
On Sun, 26 Feb 2023 13:07:19 -0800 (PST), 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 ' ?It depends on if you work in other languages. As Skip pointed out in C and most of it's derivatives "C" is a string and 'C' is a character. It gets chewy with literal strings within strings.
string query = "SELECT pay_grade from employees where last_name =
'hanna'";
works. If your name was O'brien it would have to be o''brien with the
single quote being escaped. afaik the one thing all languages agree on is you can't mix and match. "foo' won't work.
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))
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 ' ?
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.
|'A'"A"
"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.
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 prefer single quotes because they are easier to type.
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.
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.
On 2/27/23 12:20, rbowman wrote:I've never tried Black or any other code formatter, but I'm sure we
"By using Black, you agree to cede control over minutiae of hand- formatting. In return, Black gives you speed, determinism, and freedommental
from pycodestyle nagging about formatting. You will save time and
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~
On 27/02/2023 21:04, Ethan Furman wrote:
On 2/27/23 12:20, rbowman wrote:I've never tried Black or any other code formatter, but I'm sure we
"By using Black, you agree to cede control over minutiae of hand-mental
formatting. In return, Black gives you speed, determinism, and freedom
from pycodestyle nagging about formatting. You will save time and
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~
wouldn't get on.
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:I've never tried Black or any other code formatter, but I'm sure we wouldn't get on.
"By using Black, you agree to cede control over minutiae of hand-mental
formatting. In return, Black gives you speed, determinism, and freedom >> > from pycodestyle nagging about formatting. You will save time and
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~
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?
On Mon, 27 Feb 2023 at 21:06, Ethan Furman <[email protected]> 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.
On 27/02/2023 21:04, Ethan Furman wrote:
On 2/27/23 12:20, rbowman wrote:I've never tried Black or any other code formatter, but I'm sure we
"By using Black, you agree to cede control over minutiae of hand-mental
formatting. In return, Black gives you speed, determinism, and
freedom from pycodestyle nagging about formatting. You will save
time and
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~
wouldn't get on.
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?
On 2/27/23 16:42, Oscar Benjamin wrote:
On Mon, 27 Feb 2023 at 21:06, Ethan Furman <[email protected]> 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).
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.
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.
On Tue, Feb 28, 2023 at 04:05:19PM -0500, [email protected] 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.
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.
On Tue, Feb 28, 2023 at 04:05:19PM -0500, [email protected] 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.
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.
I guess this means I can't use Black. :-(
is there any reason to prefer " over ' ?
Human skin always has the same color
On 2/03/23 10:59 am, gene heskett wrote:
Human skin always has the same color
Um... no?
On 2/03/23 10:59 am, gene heskett wrote:
Human skin always has the same color
Um... no?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 156:31:09 |
| Calls: | 12,093 |
| Calls today: | 1 |
| Files: | 15,000 |
| Messages: | 6,517,738 |