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: Look free ID genertion (was: Is there a more efficient threading lock?)

[Jon Ribbens via Python-list]

On 2023-03-02, Chris Angelico  wrote:
> On Thu, 2 Mar 2023 at 08:01, <2qdxy4rzwzuui...@potatochowder.com> wrote:
>> On 2023-03-01 at 14:35:35 -0500,
>> avi.e.gr...@gmail.com wrote:
>> > What would have happened if all processors had been required to have
>> > some low level instruction that effectively did something in an atomic
>> > way that allowed a way for anyone using any language running on that
>> > machine a way to do a simple thing like set a lock or check it?
>>
>> Have happened?  I don't know about "required," but processors have
>> indeed had such instructions for decades; e.g., the MC68000 from the
>> early to mid 1980s (and used in the original Apple Macintosh, but I
>> digress) has/had a Test and Set instruction.
>
> As have all CPUs since; it's the only way to implement locks (push the
> locking all the way down to the CPU level).

Indeed, I remember thinking it was very fancy when they added the SWP
instruction to the ARM processor.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

[Chris Angelico]

On Thu, 2 Mar 2023 at 13:02, Weatherby,Gerard  wrote:
>
> So I guess we know what would have happened.
>

Yep. It's not what I was talking about, but it's also a very important
concurrency management feature.

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

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

[Weatherby,Gerard]

So I guess we know what would have happened.

Get Outlook for iOS

From: Python-list  on 
behalf of Chris Angelico 
Sent: Wednesday, March 1, 2023 8:45:50 PM
To: python-list@python.org 
Subject: Re: Look free ID genertion (was: Is there a more efficient threading 
lock?)

*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

On Thu, 2 Mar 2023 at 08:01, <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2023-03-01 at 14:35:35 -0500,
> avi.e.gr...@gmail.com wrote:
>
> > What would have happened if all processors had been required to have
> > some low level instruction that effectively did something in an atomic
> > way that allowed a way for anyone using any language running on that
> > machine a way to do a simple thing like set a lock or check it?
>
> Have happened?  I don't know about "required," but processors have
> indeed had such instructions for decades; e.g., the MC68000 from the
> early to mid 1980s (and used in the original Apple Macintosh, but I
> digress) has/had a Test and Set instruction.

As have all CPUs since; it's the only way to implement locks (push the
locking all the way down to the CPU level).

ChrisA
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!g70S067RzF2oPCFUYpFFzUvPHRfS0AHIGEvVyww1Tlj7BCCrsU3DWIqCE9UBO_ex0ZVanquFLHGe1d2b$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to fix this issue

[Thomas Passin]

On 3/1/2023 8:23 PM, Rob Cliffe via Python-list wrote:



On 01/03/2023 18:46, Thomas Passin wrote:


If this is what actually happened, this particular behavior occurs 
because Python on Windows in a console terminates with a  
instead of the usual .



I think you mean .


Correct! I double checked all three of them and then typed the wrong 
one. I suppose I should have included that you have to also type an 
 after the .

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

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

[Chris Angelico]

On Thu, 2 Mar 2023 at 08:01, <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2023-03-01 at 14:35:35 -0500,
> avi.e.gr...@gmail.com wrote:
>
> > What would have happened if all processors had been required to have
> > some low level instruction that effectively did something in an atomic
> > way that allowed a way for anyone using any language running on that
> > machine a way to do a simple thing like set a lock or check it?
>
> Have happened?  I don't know about "required," but processors have
> indeed had such instructions for decades; e.g., the MC68000 from the
> early to mid 1980s (and used in the original Apple Macintosh, but I
> digress) has/had a Test and Set instruction.

As have all CPUs since; it's the only way to implement locks (push the
locking all the way down to the CPU level).

ChrisA
-- 
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: How to fix this issue

[Rob Cliffe via Python-list]

On 01/03/2023 18:46, Thomas Passin wrote:


If this is what actually happened, this particular behavior occurs 
because Python on Windows in a console terminates with a  
instead of the usual .



I think you mean .
--
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: Look free ID genertion (was: Is there a more efficient threading lock?)

[2QdxY4RzWzUUiLuE]

On 2023-03-01 at 14:35:35 -0500,
avi.e.gr...@gmail.com wrote:

> What would have happened if all processors had been required to have
> some low level instruction that effectively did something in an atomic
> way that allowed a way for anyone using any language running on that
> machine a way to do a simple thing like set a lock or check it?

Have happened?  I don't know about "required," but processors have
indeed had such instructions for decades; e.g., the MC68000 from the
early to mid 1980s (and used in the original Apple Macintosh, but I
digress) has/had a Test and Set instruction.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: How to escape RE

[avi.e.gross]

Cameron,

The topic is now Regular Expressions and the sin tax. This is not
exclusively a Python issue as everybody and even their grandmother uses it
in various forms.

I remember early versions of RE were fairly simple and readable. It was a
terse minilanguage that allowed fairly complex things to be done but was
readable.

You now encounter versions that make people struggle as countless extensions
have been sloppily grafted on. Who ordered multiple uses where "?" is now
used? As an example. Many places have sort of expanded the terseness and
both made it more and also less legible. UNICODE made lots of older RE
features  not very useful as definitions of things like what whitespace can
be and what a word boundary or contents might be are made so different that
new constructs were added to hold them.

But, if you are operating mainly on ASCII text, the base functionality is
till in there and can be used fairly easily.

Consider it a bit like other mini languages such as the print() variants
that kept adding functionality by packing lots of info tersely so you
specify you want a floating point number with so many digits and so on, and
by the way, right justified in a wider field and if it is negative, so this.
Great if you can still remember how to read it. 

I was reading a python book recently which kept using a suffix of !r and I
finally looked it up. It seems to be asking print (or perhaps an f string)
to use __repr__()  if possible to get the representation of the object. Then
I find out this is not really needed any more as the context now allows you
to use something like {repr(val)) so a val!r is not the only and confusing
way.

These mini-languages each require you to learn their own rules and quirks
and when you do, they can be powerful and intuitive, at least for the
features you memorized and maybe use regularly. 

Now RE knowledge is the same and it ports moderately well between languages
except when it doesn't. As has been noted, the people at PERL relied on it a
lot and kept changing and extending it. Some Python functionality lets you
specify if you want PERL style or other styles.

But hiding your head in the sand is not always going to work for long. No,
you do not need to use RE for simple cases. Mind you, that is when it is
easiest to use it reliably. I read some books related to XML where much of
the work had been done in non-UNIX land years ago and they often had other
ways of doing things in their endless series of methods on validating a
schema or declaring it so data is forced to match the declared objectives
such as what type(s) each item can be or whether some fields must exist
inside others or in a particular order, or say you can have only three of
them and seeming endless other such things. And then, suddenly, someone has
the idea to introduce the ability for you to specify many things using
regular expressions and the oppressiveness (for me) lifts and many things
can now be done trivially or that were not doable before. I had a similar
experience in my SQL reading where adding the ability to do some pattern
matching using a form of RE made life simpler.

The fact is that the idea of complex pattern matching IS complex and any
tool that lets you express it so fluidly will itself be complex. So, as some
have mentioned, find a resource that helps you build a regular expression
perhaps through menus, or one that verifies if one you created makes any
sense or lets you enter test data and have it show you how it is matching or
what to change to make it match differently. The multi-line version of RE
may also be helpful as well as sometimes breaking up a bigger one into
several smaller ones that your program uses in multiple phases.

Python recently added new functionality called Structural Pattern Matching.
You use a match statement with various cases that match patterns and if
matched, execute some action. Here is one tutorial if needed:

https://peps.python.org/pep-0636/

The point is that although not at all the same as a RE, we again have a bit
of a mini-language that can be used fairly concisely to investigate a
problem domain fairly quickly and efficiently and do things. It is an
overlapping but different form of pattern matching. And, in languages that
have long had similar ideas and constructs, people often cut back on using
other constructs like an IF statement, and just used something like this!

And consider this example as being vaguely like a bit of regular expression:

match command.split():
case ["go", ("north" | "south" | "east" | "west")]:
current_room = current_room.neighbor(...)

Like it or not, our future in programming is likely to include more and more
such aids along with headaches.

Avi

-Original Message-
From: Python-list  On
Behalf Of Grant Edwards
Sent: Wednesday, March 1, 2023 12:04 PM
To: python-list@python.org
Subject: Re: How to escape strings for re.finditer?

On 2023-02-28, Cameron Simpson  wrote:

> Regexps are:
> - cryptic 

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

[Chris Angelico]

On Thu, 2 Mar 2023 at 06:37,  wrote:
>
> If a workaround like itertools.count.__next__() is used because it will not
> be interrupted as it is implemented in C, then I have to ask if it would
> make sense for Python to supply something similar in the standard library
> for the sole purpose of a use in locks.

That's not lock-free :) The only way that it works is because it's
locked against other threads doing the same job. Lock-free ID
generation means that:

1) Two threads can request IDs simultaneously and will not block each other
2) No two "request an ID" calls will ever return the same value
3) Preferably (but not required), IDs are not wasted.

PostgreSQL has ways of doing this, and there are a few other ways, but
simply using a count object and relying on the GIL isn't going to
achieve the first (though it'll happily achieve the other two).

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

RE: Look free ID genertion (was: Is there a more efficient threading lock?)

[avi.e.gross]

If a workaround like itertools.count.__next__() is used because it will not
be interrupted as it is implemented in C, then I have to ask if it would
make sense for Python to supply something similar in the standard library
for the sole purpose of a use in locks.

But realistically, this is one place the concept of an abstract python
language intersects aspects of what is bundled into a sort of core at or
soon after startup, as well as the reality that python can be implemented in
many ways including some ways on some hardware that may not make guarantees
to behave this way.

Realistically, the history of computing is full of choices made that now
look less useful or obvious.

What would have happened if all processors had been required to have some
low level instruction that effectively did something in an atomic way that
allowed a way for anyone using any language running on that machine a way to
do a simple thing like set a lock or check it?

Of course life has also turned out to be more complex. Some architectures
can now support a small number of operations and implement others as sort of
streams of those operations liked together.  You would need to be sure your
program is very directly using the atomic operation directly.

-Original Message-
From: Python-list  On
Behalf Of Dieter Maurer
Sent: Wednesday, March 1, 2023 1:43 PM
To: Chris Angelico 
Cc: python-list@python.org
Subject: Look free ID genertion (was: Is there a more efficient threading
lock?)

Chris Angelico wrote at 2023-3-1 12:58 +1100:
> ...
> The
>atomicity would be more useful in that context as it would give 
>lock-free ID generation, which doesn't work in Python.

I have seen `itertools.count` for that.
This works because its `__next__` is implemented in "C" and therefore will
not be interrupted by a thread switch.
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: How to fix this issue

[Thomas Passin]

On 3/1/2023 1:26 PM, Mats Wichmann wrote:

On 2/27/23 17:51, Arslan Mehmood wrote:
How I can remove python terminl, its again and again open during 
working in python. Please help me to resolve this issue.
Python 3.11.1 (tags/v3.11.1:a7a450f, Dec  6 2022, 19:58:39) [MSC 
v.1934 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.





We have no idea what you think the "issue" is. Perhaps if you attempted 
a bit more of an explanation?  You're working with Python, and the 
Python interpreter appears. On the surface, that doesn't seem horribly 
unusual.


Let me spell it out more clearly.  I do not know what you mean by 
"remove python terminal", "again and again open", or "during working 
with python".


It would be more helpful if you said what you did, what happened when 
you did it, and what messages you noticed during all this.


For example:

"I opened a Windows console.  I started a Python interpreter session by 
typing "py" in the console (or "I started an ipython session", or 
whatever you actually did).  I tried to end the session by pressing the 
 keys but the session did not end. When I pressed , I 
saw a message that said


KeyboardInterrupt
>>>"

If this is what actually happened, this particular behavior occurs 
because Python on Windows in a console terminates with a  
instead of the usual .


So please say clearly what you did and what happened.  Then you may be 
able to get some help.


We understand that you may not know the terminology that would be the 
most helpful because you are not familiar with it yet.  But please try 
to say clearly what you did and what happened.




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

Look free ID genertion (was: Is there a more efficient threading lock?)

[Dieter Maurer]

Chris Angelico wrote at 2023-3-1 12:58 +1100:
> ...
> The
>atomicity would be more useful in that context as it would give
>lock-free ID generation, which doesn't work in Python.

I have seen `itertools.count` for that.
This works because its `__next__` is implemented in "C" and
therefore will not be interrupted by a thread switch.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to fix this issue

[Mats Wichmann]

On 2/27/23 17:51, Arslan Mehmood wrote:

How I can remove python terminl, its again and again open during working in 
python. Please help me to resolve this issue.
Python 3.11.1 (tags/v3.11.1:a7a450f, Dec  6 2022, 19:58:39) [MSC v.1934 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.





We have no idea what you think the "issue" is. Perhaps if you attempted 
a bit more of an explanation?  You're working with Python, and the 
Python interpreter appears. On the surface, that doesn't seem horribly 
unusual.


Have you read this?

https://docs.python.org/3/using/windows.html


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

Re: How to escape strings for re.finditer?

[Thomas Passin]

On 3/1/2023 12:04 PM, Grant Edwards wrote:

On 2023-02-28, Cameron Simpson  wrote:


Regexps are:
- cryptic and error prone (you can make them more readable, but the
notation is deliberately both terse and powerful, which means that
small changes can have large effects in behaviour); the "error prone"
part does not mean that a regexp is unreliable, but that writing one
which is _correct_ for your task can be difficult,


The nasty thing is that writing one that _appears_ to be correct for
your task is often fairly easy. It will work as you expect for the
test cases you throw at it, but then fail in confusing ways when
released into the "real world". If you're lucky, it fails frequently
and obviously enough that you notice it right away. If you're not
lucky, it will fail infrequently and subtly for many years to come.

My rule: never use an RE if you can use the normal string methods
(even if it takes a a few lines of code using them to replace a single
RE).


A corollary is that once you get a working regex, don't mess with it if 
you do not absolutely have to.


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

RE: Python 3.10 Fizzbuzz

[avi.e.gross]

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: 

Re: How to escape strings for re.finditer?

[Grant Edwards]

On 2023-02-28, Cameron Simpson  wrote:

> Regexps are:
> - cryptic and error prone (you can make them more readable, but the 
>notation is deliberately both terse and powerful, which means that 
>small changes can have large effects in behaviour); the "error prone" 
>part does not mean that a regexp is unreliable, but that writing one 
>which is _correct_ for your task can be difficult,

The nasty thing is that writing one that _appears_ to be correct for
your task is often fairly easy. It will work as you expect for the
test cases you throw at it, but then fail in confusing ways when
released into the "real world". If you're lucky, it fails frequently
and obviously enough that you notice it right away. If you're not
lucky, it will fail infrequently and subtly for many years to come.

My rule: never use an RE if you can use the normal string methods
(even if it takes a a few lines of code using them to replace a single
RE).

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

pls donate acces

[Tom]

   I need make an scrpit to impressive my friends

    

   Envoyé à partir de [1]Courrier pour Windows

    

References

   Visible links
   1. https://go.microsoft.com/fwlink/?LinkId=550986
-- 
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