I didn’t expect the random module to provide a CLI so I had never attempted to use it before.
$ ./python -m random
usage: random.py [-h] [-c CHOICE [CHOICE ...] | -i N | -f N] [input ...]
positional arguments:
input if no options given, output depends on the input
string or multiple: same as --choice
integer: same as --integer
float: same as --float
options:
-h, --help show this help message and exit
-c, --choice CHOICE [CHOICE ...]
print a random choice
-i, --integer N print a random integer between 1 and N inclusive
-f, --float N print a random floating-point number between 1 and N inclusive
My main question would be about the use case for providing such a CLI (who wants to startup a Python interpreter just to compute a single random number?), and why there are two different ways to pass options. That said, the previous random CLI seemed to exercise the various distributions by measuring their statistical properties, which is not of terrific use for the average person either:
$ python3.10 -m random
0.000 sec, 2000 times random
avg 0.497649, stddev 0.28822, min 9.48959e-05, max 0.999916
0.001 sec, 2000 times normalvariate
avg -0.00977558, stddev 0.99764, min -3.15209, max 3.2292
[...]
Apologies, but requiring a vote for everything is a really bad idea. Some voters aren’t well informed. Some core developers really just don’t like each other. And a vote undermines the premise that the only power given to a committer is the ability to accept or reject something on the tracker. Presumably that ability is granted only to those who have demonstrated responsible decision making.
Rather than increasing the burdens on engaged core developers or diminishing their ability to make decisions, we should have the SC to step up their engagement. Perhaps people on the SC should be required to scan the tracker at least once every two weeks and be required to read whatsnew once a month to see if they object to some of the progress. (Notably, GPS already does this, but the other SC members are almost entirely absent from GitHub).
People are elected to the Steering Committee so that they can steer. That responsibility should not be abdicated to a vote. Also, we should be careful not to drive out productive individual contributors. Committees and working groups are good for some tasks but can be hostile to individual contributors. If a young Guido showed up today, he would not find a home.
We could do something as simple as create a DPO channel just for change visibility for things that don’t start out as PEP-sized.
Do you have an example of a large project where something like this has been implemented and shown to be effective?
My opinion is that long-term module maintainers are much better decision makers that pools of voters who are not likely fully informed. Vinay Sajip is great example of someone with a deep knowledge of the reasons for all the decisions that have ever been made on logging. I trust his judgment far more than.a group of voters who don’t know why there are five logging levels.
Just speaking for myself here: I am happy to confirm that I check GitHub every single day, as well as discourse and I normally take less than 2 days to answer a direct ping in the many issues and reviews I am requested. I normally dedicate at least an hour daily just to catch up with things, PRs that were merged before I could review and do reviews myself. This doesn’t include any other thing that I do almost daily like fix things myself, new features, mentoring, Buildbot improvements, release management, answering contributor emails, offline discussions, catch up with discord and so on.
I literally scan all new issues in the bug tracker to do the “what’s new in CPython” section of our core.py podcast where we highlight the most relevant contributions of the last two weeks. You can check this by listening to the end of every episode we release: core.py • A podcast on Spotify for Podcasters . Before this I had to do it no matter if I wanted or not because I released 3.10 and 3.11 and I personally curated and wrote most of the what’s new section of both releases. I also authored a lot of the changes that there have been in many of these documents. I invite you to search my name in the what’s new documents to confirm this.
I know you were not doing this on purpose and I don’t want to clarify this because I am offended by the comment or anything of the sort: I understand what you want to say. But I think that this statement read “as is” is ignoring a considerable amount of work and effort that I do daily for the project so I wanted to be very clear about this.
Kudos to you for doing that and the other work you do. FWIW you’re not alone. I almost never get accolades or credit for the continuous volunteer work I’ve done for the past two decades.
At issue in this thread is whether the SC is worried that changes are “sneaking through” and whether a voting system needs to implemented to tamp down a core developer’s ability to approve or reject issues (which is their only unique capability). Given that you see everything within two weeks and present it to the world, what do you think?
I think that I don’t think anyone is “sneaking through” changes on purpose and nobody is trying here to be malicious. It looks like with the amount of changes that are happening across the repo and the complexity of those changes it’s super difficult to keep up with what is happening. I find it very challenging and time consuming and it’s very difficult to ensure that the things I care are being taken care of everywhere. I know you (and many others) have similar concerns and that have been expressing this frustration before.
It looks like precisely because of this, many people are worried that some changes do not have enough visibility to ensure that there is consensus. I can also understand that: if someone merges a core change in the parser or the gc and I don’t have time to review it it may be very difficult for me to deal with the consequences, specially if I could have provided context on the change or alternative approaches. I know that you and many others probably feel similar regarding the parts of the codebase that you are more passionate about.
So its a complex problem: On one side I agree that people that normally maintain a specific area have more context and can make more informed decisions, but on the other hand I can understand that some people are worried that things are going too fast and that things are not being discussed enough so they want to discuss alternatives.
Regarding what we can do in the SC: I think the SC should do what PEP 13 says we should do:
The steering council shall work to:
…
Seek consensus among contributors and the core team before acting in a formal capacity,
and
The council should look for ways to use these powers as little as possible. Instead of voting, it’s better to seek consensus. Instead of ruling on individual PEPs, it’s better to define a standard process for PEP decision making (for example, by accepting one of the other 801x series of PEPs).
This doesn’t need to mean that everything should be decided in a vote (that won’t scale and it has many other problems). But we must listen to everyone’s concern and then try to decide what’s best if there is no consensus. If there is consensus what we individually think on the SC matters less because we seek consensus.
What I think we should do here? I still don’t know, I am listening to everyone carefully and paying attention to understand everyone’s point of view. What I can tell you is that your concerns that people close to the specific area have more context are sound but so are the ones from the people that feel that things are going to fast and there may not be consensus (which I assume you also would agree because you have expressed this worry in the past for other reasons).
My main responsibility as a SC member is to listen and understand. And right now I am listening as best as I can.
Also, let me add something so it doesn’t get diluted in my previous message. Just to be absolutely clear @rhettinger: your worries and concerns matter and it’s our responsibility to take them into account. They are valid views and worries based on arguments that reflect your experience and vision, which we absolutely value.
But understand that it’s our job and responsibility to also take everyone’s worries, experience and vision into account, even (and often) if these are totally opposed. This is not an easy job. Actually, it’s a very complicated job that normally ends with many people not happy with the final decision. So let’s have patience and be empathetic meanwhile we discuss and figure out what’s best for everyone and for the project.
I think adding more process is not needed and would, in fact, result in making core dev development less attractive as @rhettinger mentioned.
What does make a lot of sense is adding more visibility for changes to the core by opening up Discourse topics for deeper changes.
This gives them more traction in the larger Python community and the people involved in working on the changes on Github can then use this input as additional source of feedback.
Of course, a discussion can result in more and more people requesting a PEP process for a change, but that’s a good thing, and it doesn’t add more process than we already have.
Whether a change requires a PEP or not is often not obvious and Discourse discussions could help in getting a clearer picture. The SC can ask for a PEP process to be started or simply let the change go in as simple PR, if there no clear conclusion can be reached.
One thing that would be fairly easy: Bedevere could automatically add a label to any PR that touches What’s New. This would be an easy way for anyone to filter open PRs based on what’s about to be new. Github also has some beta feature enabled for the Python organisation that lets you receive notifications based on labels.
(assumptions: most changes we want more visibility on merit What’s New entries; we do a reasonable job encouraging contributors to add What’s New to relevant PRs; we want a mechanism that increases visibility before merge)
IMO, as part of this we should consider what kind of additional planned changes depend on the change in question.
Something like ~bool deprecation is relatively easy to revert. But something like changing object memory layout or repurposing an undocumented attribute is very hard to undo when lots of other work already depends on it, and it’s found to conflict with documented behaviour or existing code. For examples see #112743 or hiding allocators.
Somewhat related, I think we should require more design documents – InternalDocs files, PEP, or just code comments/docstrings where appropriate – for private internal details (or what looks like private details), which don’t end up in What’s New.
Reading code is fine, but if the code is wrong or isn’t self-consistent, documenting the intent is invaluable. And prose is easier to scan for people who aren’t deeply involved in the change, but who might notice unwanted interaction with other uses/features.
And on another note, I think that if you see opposition from another core dev, and you can’t convince them to (reluctantly) agree, you should escalate – from a code review snippet to a dedicated issue, from an issue/PR to Discourse, and if there still isn’t consensus, to the SC (with a PEP if it takes more than a paragraph or two to explain). Don’t push a change through if there’s active disagreement.
+1, and these would make for excellent documentation for new folks diving into particular arcane corners of the implementation. Maybe we should collect them in a common directory.
The SC has previously talked about having the concept of white papers, potentially kept in the devguide. But there was a lack of time to sit down and think about details of how they would work (e.g., what should be a white paper, where exactly to keep them, their format, etc.).
A lot has already been said in this thread, and I have not much to add to that (my own experience is that triagers and core devs have done a good job at pointing out backwards incompatible changes in my PRs, there has been little need to move discussion to DPO).