Current thinking on required options
Hi,
I have various small programs which tend to have an interface like the
following example:
usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g GROUP]
Command line grouper tool
optional arguments:
-h, --helpshow this help message and exit
-o {check,add,delete}, --operation {check,add,delete}
operation to apply
-u USERS [USERS ...], --users USERS [USERS ...]
users to apply operation to
-g GROUP, --group GROUP
group to apply operation to
However, the options -o, -u, and -g are required, not optional.
The documentation
https://docs.python.org/3/library/argparse.html#required
advises against required options and here
https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments
a way of adding a section 'required arguments' to the usage is
described.
I would be interested to know what the general thinking on "required
options" is. Is there just a better way of designing such interfaces?
Cheers,
Loris
--
This signature is currently under construction.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
Loris Bennett wrote:
usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g GROUP]
Command line grouper tool
optional arguments:
-h, --helpshow this help message and exit
-o {check,add,delete}, --operation {check,add,delete}
operation to apply
-u USERS [USERS ...], --users USERS [USERS ...]
users to apply operation to
-g GROUP, --group GROUP
group to apply operation to
However, the options -o, -u, and -g are required, not optional.
Just a nitpick.
To quote from https://en.wikipedia.org/wiki/Usage_message
"To indicate required arguments, Angled brackets are
commonly used, ..."
So then it should better be written as:
grocli [-h] <-o {check,add,delete}> <-u USERS [USERS ...]> <-g GROUP>
--
--gv
--
https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
On 19/04/2021 11:52, Loris Bennett wrote:
Hi,
I have various small programs which tend to have an interface like the
following example:
usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g GROUP]
Command line grouper tool
optional arguments:
-h, --helpshow this help message and exit
-o {check,add,delete}, --operation {check,add,delete}
operation to apply
-u USERS [USERS ...], --users USERS [USERS ...]
users to apply operation to
-g GROUP, --group GROUP
group to apply operation to
However, the options -o, -u, and -g are required, not optional.
The documentation
https://docs.python.org/3/library/argparse.html#required
advises against required options and here
https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments
a way of adding a section 'required arguments' to the usage is
described.
I would be interested to know what the general thinking on "required
options" is. Is there just a better way of designing such interfaces?
For the example above you could realize the operation through subparsers
and switch group and users. In cases where no such "natural" order of
arguments exists I'd have no qualms to use required options. Personally
I've not yet come across such a case.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
Gisle Vanem writes:
> Loris Bennett wrote:
>
>>usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g
>> GROUP]
>>
>>Command line grouper tool
>>
>>optional arguments:
>> -h, --helpshow this help message and exit
>> -o {check,add,delete}, --operation {check,add,delete}
>>operation to apply
>> -u USERS [USERS ...], --users USERS [USERS ...]
>>users to apply operation to
>> -g GROUP, --group GROUP
>>group to apply operation to
>>
>> However, the options -o, -u, and -g are required, not optional.
>
> Just a nitpick.
>
> To quote from https://en.wikipedia.org/wiki/Usage_message
> "To indicate required arguments, Angled brackets are
> commonly used, ..."
>
> So then it should better be written as:
> grocli [-h] <-o {check,add,delete}> <-u USERS [USERS ...]> <-g GROUP>
I would take that with a pinch of salt. The Wikipedia page doesn't give
any examples, let alone any that might be considered somehow typical or
representative. Looking at a few tools I use regularly (awk, cat, grep,
sed, ssh, tmux) I couldn't find any which use the angled-bracket
notation. So maybe the notation is not common or just not many programs
have this type of option. The latter would correspond with sentiment in
the argparse documentation that it is an approach to be avoided.
In any case, the usage line is generated automatically by argsparse.
However, I am more interested in what an alternative approach might look
like.
Cheers,
Loris
--
This signature is currently under construction.
--
https://mail.python.org/mailman/listinfo/python-list
EuroPython 2021: Ticket sales started
We're pleased to announce the start of the EuroPython 2021 ticket sales: * EuroPython 2021 Ticket Sales Open * https://ep2021.europython.eu/registration/buy-tickets/ Updated ticket structure For EuroPython 2021, we'll have more than 10 training sessions and workshops spread across two days. There is a combined ticket available for those who wish to attend both. We also added a new livestream-only ticket for getting access to the live streams. It's free, but you'll miss out on the interactivity. Ticket types - Combined tickets: Access to the whole seven day conference, including training sessions, workshops, conference days and sprints. - Conference + sprint tickets: Access to conference days and sprints. - Sprint-only tickets: Free access to the sprint days only. - Livestream-only tickets: Free access to the live streams of the conference sessions only. No access to the conference system. Ticket tiers - Business tickets: For people using Python to make a living and people who want to support our grants program. - Personal tickets: For people enjoying Python in their free time or as a freelancer. More details For full details, which include ticket prices, a comparison features and the link to the ticket shop, please see our registration page. Our financial aid program will be available starting Wednesday, April 21. Participate in Talk Voting -- With a conference or combined ticket, you will also be able to tell us what you’d like to see at EuroPython 2021 by voting on the submitted talk proposals. Talk voting will start after the end of the Call for Proposals (CFP). Guido van Rossum Core Developer Grant - For Python Core Developers, we have put a special grant in place, which will allow core developers to get free combined tickets to the conference. If you want to sign up, please check our grant page for details on how to apply. Quick Summary - EuroPython 2021 will be run online from July 26 - August 1: - Two workshop/training days (July 26 - 27) - Three conference days (July 28 - 30) - Two sprint days (July 31 - August 1) The sessions will be scheduled to ensure they are also accessible for those in the Asian and Americas time zones. Help spread the word Please help us spread this message by sharing it on your social networks as widely as possible. Thank you ! Link to the blog post: https://blog.europython.eu/europython-2021-ticket-sales-started/ Tweet: https://twitter.com/europython/status/1384076406418595846 Enjoy, -- EuroPython 2021 Team https://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Determine what the calling program is
> On 18 Apr 2021, at 14:46, Jason Friedman wrote:
>
> I should state at the start that I have a solution to my problem. I am
> writing to see if there is a better solution.
>
> I have a program that runs via crontab every five minutes. It polls a
> Box.com folder for files and, if any are found, it copies them locally and
> performs a computation on them that can exceed five minutes. It pushes the
> results back up to Box. (Box.com ensures that only complete files are
> visible when I poll.) Files are dropped into this Box.com folder rarely,
> but to ensure a good customer experience I do not want to set my crontab to
> run less frequently. My hardware cannot support multiple simultaneous
> computations.
>
> I have written a piece of code to detect if more than 1 instance of my
> program is running, and I put this code into a separate module (support.py)
> so that other programs can use it.
The way to do this simply on a unix system is to use a lock file and code like
this:
lock_file = open(os.path.join(lock_dir, 'lockfile'), 'w')
try:
fcntl.flock(lock_file, fcntl.LOCK_EX|fcntl.LOCK_NB)
except IOError as e:
if e.errno == errno.EWOULDBLOCK:
log('CA base directory "%s" already locked, exiting', ca_base_dir)
sys.exit(0)
else:
log('Non-locking related IOError for file %s', lock_file)
raise
Only the first time the code runs will the lock be granted.
You can then do the possible long running task.
When a second copy of the program runs from cron it will get the
EWOULDBLOCK error and you can just exit.
Barry
>
> support.py contains:
>
> import sys
> def check(calling_program):
>import psutil
># some logic here to count
># count = N
>if count > 1:
>print(f"I was called by {calling_program}.")
>sys.exit()
> if __name__ == "__main__":
>check()
>
>
> actual-program.py contains:
>
> import support.py
> support.check(__file__)
> # Poll, and if files download, perform expensive computations, push results
>
>
> To me it would be more elegant to be able to do something like this:
>
> def check():
># Something here that tells me the name of the calling program
>import psutil
># ...
>
> And then the calling program just does:
> support.check()
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
> On 19 Apr 2021, at 10:57, Loris Bennett wrote:
>
> Hi,
>
> I have various small programs which tend to have an interface like the
> following example:
>
> usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g GROUP]
>
> Command line grouper tool
>
> optional arguments:
>-h, --helpshow this help message and exit
>-o {check,add,delete}, --operation {check,add,delete}
> operation to apply
>-u USERS [USERS ...], --users USERS [USERS ...]
> users to apply operation to
>-g GROUP, --group GROUP
> group to apply operation to
>
> However, the options -o, -u, and -g are required, not optional.
You could use positional args like this:
grocli check user,user group
Barry
>
> The documentation
>
> https://docs.python.org/3/library/argparse.html#required
>
> advises against required options and here
>
>
> https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments
>
> a way of adding a section 'required arguments' to the usage is
> described.
>
> I would be interested to know what the general thinking on "required
> options" is. Is there just a better way of designing such interfaces?
>
> Cheers,
>
> Loris
>
> --
> This signature is currently under construction.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett wrote: > However, the options -o, -u, and -g are required, not optional. > > The documentation > > https://docs.python.org/3/library/argparse.html#required > > advises against required options and here > > > https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments > > a way of adding a section 'required arguments' to the usage is > described. > Of _course_ some options need to be required. I can't imagine what the author of that page was thinking. -- https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
Calling them options—when they're required—seems like a problem. 🙂 On Mon, 2021-04-19 at 09:04 -0700, Dan Stromberg wrote: > On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett > > wrote: > > > However, the options -o, -u, and -g are required, not optional. > > > > The documentation > > > > https://docs.python.org/3/library/argparse.html#required > > > > advises against required options and here > > > > > > https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments > > > > a way of adding a section 'required arguments' to the usage is > > described. > > > > Of _course_ some options need to be required. > > I can't imagine what the author of that page was thinking. -- https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
I guess maybe it seems like a problem to someone who hasn't used command line tools much, based solely on a simplistic interpretation of the terminology. But strictly speaking, they're "command line options", or better "command line arguments", not "options". On Mon, Apr 19, 2021 at 9:30 AM Paul Bryan wrote: > Calling them options—when they're required—seems like a problem. 🙂 > > On Mon, 2021-04-19 at 09:04 -0700, Dan Stromberg wrote: > > On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett > wrote: > > However, the options -o, -u, and -g are required, not optional. > > The documentation > > https://docs.python.org/3/library/argparse.html#required > > advises against required options and here > > > > https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments > > a way of adding a section 'required arguments' to the usage is > described. > > > Of _course_ some options need to be required. > > I can't imagine what the author of that page was thinking. > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
On 2021-04-19, Paul Bryan wrote: > Calling them options—when they're required—seems like a problem. 🙂 The option is what the value is, not whether there is a value at all. If you order a coffee then you may have an option as to what temperature it is, that doesn't mean the coffee having a temperature is optional. -- https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
On 2021-04-19 16:38:24 -, Jon Ribbens via Python-list wrote: > On 2021-04-19, Paul Bryan wrote: > > Calling them options—when they're required—seems like a problem. 🙂 > > The option is what the value is, not whether there is a value at all. > If you order a coffee then you may have an option as to what temperature > it is, that doesn't mean the coffee having a temperature is optional. No, but you having to specify the temperature is optional. Yoy might order an extra-hot coffee or s luke-warm coffee, but most of the time you will just order a coffee and accept it being at the default temperature. I would agree with others that options should in general be optional. I do break that that rule sometimes, though: If there are several required arguments and they have no obvious natural order, I might use required options for those just to prevent the user (me) from swapping them. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
On Mon, Apr 19, 2021, Loris Bennett wrote:
>Hi,
>
>I have various small programs which tend to have an interface like the
>following example:
>
> usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g GROUP]
I would do this with the action is first argument.
Usage: grocli check|add|delete [-u USERS ...]
Bill
--
INTERNET: b...@celestial.com Bill Campbell; Celestial Software LLC
URL: http://www2.celestial.com/ 6641 E. Mercer Way
Mobile: (206) 947-5591 PO Box 820
Fax:(206) 232-9186 Mercer Island, WA 98040-0820
Force always attracts men of low morality. -- Albert Einstein
--
https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
On Tue, Apr 20, 2021 at 4:18 AM Bill Campbell wrote:
>
> On Mon, Apr 19, 2021, Loris Bennett wrote:
> >Hi,
> >
> >I have various small programs which tend to have an interface like the
> >following example:
> >
> > usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g
> > GROUP]
>
> I would do this with the action is first argument.
>
> Usage: grocli check|add|delete [-u USERS ...]
>
Which aligns well with a concept of subcommands (or, in argparse
terms, subparsers).
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: do ya still use python?
On 19.04.2021 17:37, JWS wrote: On Monday, April 19, 2021 at 11:44:11 AM UTC-5, Unbreakable Disease wrote: almost no useful posts here for almost a year. is python dying? I can't tell what group you are referencing. comp.lang.python is still active. I'm doing a tkinter project now. Active for these moron spammers who keep it alive thanks to all stupid dudes who think Stack Overflow has an answer to every solution. -- Tip me: bc1qtwmjzywve5v7z6jzk4dkg7v6masw2erpahsn9f bitcoin:bc1qtwmjzywve5v7z6jzk4dkg7v6masw2erpahsn9f -- https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
On 2021-04-19, Dan Stromberg wrote: > On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett > wrote: > >> However, the options -o, -u, and -g are required, not optional. >> >> The documentation >> >> https://docs.python.org/3/library/argparse.html#required >> >> advises against required options and here >> >> >> https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments >> >> a way of adding a section 'required arguments' to the usage is >> described. >> > > Of _course_ some options need to be required. Traditionally, required "things" were called arguments and were not prefixed with a hyphen. Optional "things" were called options (hence the similarity in spelling between "optional" and "option"). > I can't imagine what the author of that page was thinking. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: do ya still use python?
On 4/19/21 11:22 AM, Unbreakable Disease wrote: [offensive drivel] List, my apologies -- not sure how that one got through. -- ~Ethan~ Python List Moderator -- https://mail.python.org/mailman/listinfo/python-list
Re: Current thinking on required options
On Mon, Apr 19, 2021 at 12:36 PM Grant Edwards wrote: > On 2021-04-19, Dan Stromberg wrote: > > On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett < > loris.benn...@fu-berlin.de> wrote: > > > >> However, the options -o, -u, and -g are required, not optional. > >> > >> The documentation > >> > >> https://docs.python.org/3/library/argparse.html#required > >> > >> advises against required options and here > >> > >> > >> > https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments > >> > >> a way of adding a section 'required arguments' to the usage is > >> described. > >> > > > > Of _course_ some options need to be required. > > Traditionally, required "things" were called arguments and were not > prefixed with a hyphen. Optional "things" were called options (hence > the similarity in spelling between "optional" and "option"). > This is a silly thread. "option" should be conflated with "optional" no more than "argument" should be conflated with "a logician's disagreement". $ cpio below cmd output started 2021 Mon Apr 19 12:47:07 PM PDT cpio: You must specify one of -oipt options. Try `cpio --help' or `cpio --usage' for more information. Try 'cpio --help' or 'cpio --usage' for more information. $ tar below cmd output started 2021 Mon Apr 19 12:49:47 PM PDT tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options Try 'tar --help' or 'tar --usage' for more information. -- https://mail.python.org/mailman/listinfo/python-list
Re: Determine what the calling program is
On 2021-04-19 08:04:10 +1200, dn via Python-list wrote: > In a similar situation, one of my teams used an (OpSys) environment > variable (available in both *nux and MS-Win). > - when the application starts, it checks for the variable > - if exists, stops running, else may proceed That doesn't work on Unix-like OSs. An environment variable can only be passwd to child processes, not to the parent or unrelated processes. So it can't be used to lock out other processes - they wouldn't ever see the variable. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Determine what the calling program is
On 2021-04-19 08:54:06 +1000, Cameron Simpson wrote: > My personal preference is lock directories. Shell version goes like > this: > > if mkdir /my/lock/directory/name-of-task > then >.. do task .. >rmdir /my/lock/directory/name-of-task > else > echo "lock /my/lock/directory/name-of-task already taken" > fi > > Simple, reliable, even works over NFS if you care. Reliable only if "fail locked" is acceptable. If that process dies for some reason the lock directory will stay behind, blocking other processes until somebody notices the problem and removes it. The fcntl method suggested by several people has the advantage that the lock vanished with the process which holds it. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Determine what the calling program is
On 19Apr2021 23:13, Peter J. Holzer wrote: >On 2021-04-19 08:54:06 +1000, Cameron Simpson wrote: >> My personal preference is lock directories. Shell version goes like >> this: >> >> if mkdir /my/lock/directory/name-of-task >> then >>.. do task .. >>rmdir /my/lock/directory/name-of-task >> else >> echo "lock /my/lock/directory/name-of-task already taken" >> fi >> >> Simple, reliable, even works over NFS if you care. > >Reliable only if "fail locked" is acceptable. If that process dies for >some reason the lock directory will stay behind, blocking other >processes until somebody notices the problem and removes it. A Python context manager narrows the range of circumstances for this failure quite a lot. But yes. >The fcntl method suggested by several people has the advantage that the >lock vanished with the process which holds it. This is very true. OTOH, mkdir's easy to debug if it hangs around. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Determine what the calling program is
> On 19 Apr 2021, at 22:49, Cameron Simpson wrote: > > On 19Apr2021 23:13, Peter J. Holzer wrote: >>> On 2021-04-19 08:54:06 +1000, Cameron Simpson wrote: >>> My personal preference is lock directories. Shell version goes like >>> this: >>> >>>if mkdir /my/lock/directory/name-of-task >>>then >>> .. do task .. >>> rmdir /my/lock/directory/name-of-task >>>else >>> echo "lock /my/lock/directory/name-of-task already taken" >>>fi >>> >>> Simple, reliable, even works over NFS if you care. >> >> Reliable only if "fail locked" is acceptable. If that process dies for >> some reason the lock directory will stay behind, blocking other >> processes until somebody notices the problem and removes it. > > A Python context manager narrows the range of circumstances for this > failure quite a lot. But yes. > >> The fcntl method suggested by several people has the advantage that the >> lock vanished with the process which holds it. > > This is very true. OTOH, mkdir's easy to debug if it hangs around. Only the fcntl method is robust. Your suggestion with mkdir is not reliable in practice. If you need a lock in the sh env then there are standard patterns using the flock command. See the man page for examples. Barry > > Cheers, > Cameron Simpson > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
RE: Current thinking on required options
Sidestepping the wording of "options" is the very real fact that providing
names for even required parts can be helpful in many cases.
There re programs that may not require anything on the command line to be
done but many need something to provide some flexibility.
So, I tend to agree that in many cases you need an explicit or implicit
argument for a program to do something useful. If I have a simple program
that looks up a phone number when given a name, it would require a name
UNLESS the default behavior is to show ALL entries or repeat whatever I
asked for last time by keeping track or provide the number I ask for most or
pick a random one or return silently having done nothing ...
But I want to point out something OBVIOUS. The requested program in my view
HAS NO required arguments! All are in a sense optional but at the same time
are all mandatory in some circumstances.
It can be called two equally valid ways:
grocli [-h]
OR
grocli -o {check,add,delete} -u USERS [USERS ...]] -g GROUP
When called to ask for help, none of the other arguments are required or are
ignored or worse. When called with the second properly formed set of
arguments, in any order, I assume any "-h" is either ignored or an error.
So I would possibly have TWO usage statements and in both cases, NO optional
arguments! Either you ask for help or you provide everything else.
Clearly your actual code can be designed many ways including allowing all
combinations and throwing in help when asked for in addition to doing what
is requested or allowing multiple -u arguments instead of multiple arguments
following a single -u and so forth. Heck, it can perhaps accept random
additional arguments and pass them along to another command it uses
internally without question in a "..." situation.
So a syntax for defining a program as documentation like the above may need
an OR approach or be even more complex when say two or more arguments can be
used but only ONE is allowed and then it may be mandatory. Picture a -m to
suggest units are metric versus ...
And this "-h" notation is very common in programs and can cause the
description of how a program should be used more complex than it needs to be
if you insist on just one line showing how to use it rather than giving
several valid usages.
-Original Message-
From: Python-list On
Behalf Of Dan Stromberg
Sent: Monday, April 19, 2021 12:04 PM
To: Loris Bennett
Cc: Python List
Subject: Re: Current thinking on required options
On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett
wrote:
> However, the options -o, -u, and -g are required, not optional.
>
> The documentation
>
> https://docs.python.org/3/library/argparse.html#required
>
> advises against required options and here
>
>
> https://stackoverflow.com/questions/24180527/argparse-required-argumen
> ts-listed-under-optional-arguments
>
> a way of adding a section 'required arguments' to the usage is
> described.
>
Of _course_ some options need to be required.
I can't imagine what the author of that page was thinking.
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: do ya still use python?
On 2021-04-20, Paul Rubin wrote: > Ethan Furman writes: >> List, my apologies -- not sure how that one got through. > > It was trollishly written but was a reasonable observation on the state > of the Usenet group. I didn't realize it had come through (or reached) > the mailing list. Anyway the state of affairs for us Usenet die-hards > isn't so great. Why do you say that? The group seems quite lively to me (and no I'm not counting spam etc). -- https://mail.python.org/mailman/listinfo/python-list
Re: do ya still use python?
On Mon, Apr 19, 2021 at 5:55 PM Jon Ribbens via Python-list < python-list@python.org> wrote: > On 2021-04-20, Paul Rubin wrote: > > Ethan Furman writes: > >> List, my apologies -- not sure how that one got through. > > > > It was trollishly written but was a reasonable observation on the state > > of the Usenet group. I didn't realize it had come through (or reached) > > the mailing list. Anyway the state of affairs for us Usenet die-hards > > isn't so great. > > Why do you say that? The group seems quite lively to me > (and no I'm not counting spam etc). > Actually, this list is less busy than it was a decade or two ago, but that's probably because of things like stackoverflow, python-dev, pypy-dev, cython-devel, python-ideas, distutils-sig, issue trackers, code-quality, and probably others. There was a time when most python-related discussion happened here on python-list/comp.lang.python. -- https://mail.python.org/mailman/listinfo/python-list
