SC 2020 recommendation for PEP 634
After much deliberation, the 2020 SC will be making a recommendation to the 2021 SC to accept PEP 634 (although this was not a unanimous decision). This is in no way a binding recommendation to the 2021 SC (even if a majority of current council members get re-elected), but we felt we should pass on our thoughts to the next council as we have been discussing pattern matching for a few months at this point and we promised we would make some decision to the PEP authors.
On 12/7/20 11:29 AM, Brett Cannon wrote:
After much deliberation, the 2020 SC will be making a recommendation to the 2021 SC to accept PEP 634 (although this was not a unanimous decision).
This seems very odd. The Steering Council is elected to make decisions, but it feels like the current SC is passing the buck. You (the current SC) have spent much time on this, so it seems that you are in the best position to make a final decision. If you don't, then the next SC may have to also spend a lot of time on the issue as well to be comfortable accepting your recommendation -- time that could be better spent on other issues. If you (the current SC) were actually accepting PEP 634, would the vote be the same? Then accept it, and let's all move on. -- ~Ethan~
This opens the door for people voting on A or B depending on if they would accept or reject the PEP. Is this something we're willing to accept? On Mon, Dec 7, 2020 at 9:29 PM Ethan Furman via Python-Dev < python-dev@python.org> wrote:
On 12/7/20 11:29 AM, Brett Cannon wrote:
After much deliberation, the 2020 SC will be making a recommendation to the 2021 SC to accept PEP 634 (although this was not a unanimous decision).
This seems very odd. The Steering Council is elected to make decisions, but it feels like the current SC is passing the buck. You (the current SC) have spent much time on this, so it seems that you are in the best position to make a final decision. If you don't, then the next SC may have to also spend a lot of time on the issue as well to be comfortable accepting your recommendation -- time that could be better spent on other issues.
If you (the current SC) were actually accepting PEP 634, would the vote be the same? Then accept it, and let's all move on.
-- ~Ethan~ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EP7GRKHV... Code of Conduct: http://python.org/psf/codeofconduct/
On Mon, Dec 7, 2020, 23:10 Bernat Gabor <jokerjokerer@gmail.com> wrote:
This opens the door for people voting on A or B depending on if they would accept or reject the PEP. Is this something we're willing to accept?
The SC is, and I tried to make that clear in my earlier post about these PEPs ( https://mail.python.org/archives/list/python-dev@python.org/thread/4SBR3J5IQ...) and in my nomination post ( https://discuss.python.org/t/steering-council-nomination-thomas-wouters-2021... ). (If this makes people change their mind about the SC elections, keep in mind you can re-cast your ballot to change your vote as long as the election is open. Your last ballot cast will count.)
On Mon, Dec 7, 2020 at 9:29 PM Ethan Furman via Python-Dev < python-dev@python.org> wrote:
On 12/7/20 11:29 AM, Brett Cannon wrote:
After much deliberation, the 2020 SC will be making a recommendation to the 2021 SC to accept PEP 634 (although this was not a unanimous decision).
This seems very odd. The Steering Council is elected to make decisions, but it feels like the current SC is passing the buck. You (the current SC) have spent much time on this, so it seems that you are in the best position to make a final decision. If you don't, then the next SC may have to also spend a lot of time on the issue as well to be comfortable accepting your recommendation -- time that could be better spent on other issues.
If you (the current SC) were actually accepting PEP 634, would the vote be the same? Then accept it, and let's all move on.
-- ~Ethan~ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EP7GRKHV... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7U466T6N... Code of Conduct: http://python.org/psf/codeofconduct/
On Mon, Dec 7, 2020, 22:34 Ethan Furman via Python-Dev < python-dev@python.org> wrote:
On 12/7/20 11:29 AM, Brett Cannon wrote:
After much deliberation, the 2020 SC will be making a recommendation to the 2021 SC to accept PEP 634 (although this was not a unanimous decision).
This seems very odd. The Steering Council is elected to make decisions, but it feels like the current SC is passing the buck. You (the current SC) have spent much time on this, so it seems that you are in the best position to make a final decision. If you don't, then the next SC may have to also spend a lot of time on the issue as well to be comfortable accepting your recommendation -- time that could be better spent on other issues.
If you (the current SC) were actually accepting PEP 634, would the vote be the same? Then accept it, and let's all move on.
The SC is elected for a single python release. The elections for the next one are currently happening -- about ten more days until we know the result. This is a big, contentious change in the *next* version of Python, not the one the current SC was elected for, so it makes more sense to let the next SC make the final decision.
-- ~Ethan~ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EP7GRKHV... Code of Conduct: http://python.org/psf/codeofconduct/
On Mon, 7 Dec 2020 11:29:55 -0800 Brett Cannon <brett@python.org> wrote:
After much deliberation, the 2020 SC will be making a recommendation to the 2021 SC to accept PEP 634 (although this was not a unanimous decision). This is in no way a binding recommendation to the 2021 SC (even if a majority of current council members get re-elected), but we felt we should pass on our thoughts to the next council as we have been discussing pattern matching for a few months at this point and we promised we would make some decision to the PEP authors.
Perhaps you could also post the thought process which leads to this recommendation, so that the future SC has more input on the matter? Regards Antoine.
As a candidate for the new SC, if elected I would certainly find it more useful to have more specific thoughts from the outgoing SC than simply "we recommend." How divided was the vote? Who took the sides? What were the major points of disagreement? That sort of thing. On Tue, Dec 8, 2020 at 9:39 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
After much deliberation, the 2020 SC will be making a recommendation to
2021 SC to accept PEP 634 (although this was not a unanimous decision). This is in no way a binding recommendation to the 2021 SC (even if a majority of current council members get re-elected), but we felt we should pass on our thoughts to the next council as we have been discussing
On Mon, 7 Dec 2020 11:29:55 -0800 Brett Cannon <brett@python.org> wrote: the pattern
matching for a few months at this point and we promised we would make some decision to the PEP authors.
Perhaps you could also post the thought process which leads to this recommendation, so that the future SC has more input on the matter?
Regards
Antoine.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FTXGXG6U... Code of Conduct: http://python.org/psf/codeofconduct/
-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
On Tue, 8 Dec 2020 at 15:19, David Mertz <mertz@gnosis.cx> wrote:
As a candidate for the new SC, if elected I would certainly find it more useful to have more specific thoughts from the outgoing SC than simply "we recommend." How divided was the vote? Who took the sides? What were the major points of disagreement? That sort of thing.
My understanding was that the outgoing SC would fully brief the new SC. The mail here is simply a summary view for the information of the wider python-dev community. Personally, I'm not sure how I feel about it. It's very much a good thing in terms of transparency, something the SC seems to still be trying to find the right balance on, but I feel that having seen this, I'd be left with a lot of unanswered questions if the incoming SC ends up rejecting the proposal, and therefore I don't really know how to view the information with that context. Paul
On Tue, Dec 8, 2020 at 7:32 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Tue, 8 Dec 2020 at 15:19, David Mertz <mertz@gnosis.cx> wrote:
As a candidate for the new SC, if elected I would certainly find it more
useful to have more specific thoughts from the outgoing SC than simply "we recommend." How divided was the vote? Who took the sides? What were the major points of disagreement? That sort of thing.
My understanding was that the outgoing SC would fully brief the new SC. The mail here is simply a summary view for the information of the wider python-dev community.
Paul, this is a good summary of why the SC posted its recommendation for the incoming SC.
Personally, I'm not sure how I feel about it. It's very much a good thing in terms of transparency, something the SC seems to still be trying to find the right balance on, but I feel that having seen this, I'd be left with a lot of unanswered questions if the incoming SC ends up rejecting the proposal, and therefore I don't really know how to view the information with that context.
That's a fair point. We expect to do a hand-off meeting with the new SC to discuss. Although personally I would like to see a pattern matching solution, we didn't have consensus within the existing SC for many of the reasons already discussed in other posts. We felt it was best to give the new SC an opportunity to make the decision.
Paul _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KA3MJOZI... Code of Conduct: http://python.org/psf/codeofconduct/
On Wed, 9 Dec 2020 at 04:56, Carol Willing <willingc@gmail.com> wrote:
That's a fair point. We expect to do a hand-off meeting with the new SC to discuss. Although personally I would like to see a pattern matching solution, we didn't have consensus within the existing SC for many of the reasons already discussed in other posts. We felt it was best to give the new SC an opportunity to make the decision.
Given that the current SC had also previously announced your intent to let the next SC decide, changing your mind and accepting it now would have been problematic :) I'll change my priorities on getting PEP 642 revised and formally submitted to the new SC for consideration though - the review process on that PEP has shifted me from being +0 on PEP 634 to -1 due to the way name binding works in class and mapping patterns (especially class patterns, where "x=y" looks up "x" as an instance attribute and binds "y" as a local variable). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (9)
-
Antoine Pitrou -
Bernat Gabor -
Brett Cannon -
Carol Willing -
David Mertz -
Ethan Furman -
Nick Coghlan -
Paul Moore -
Thomas Wouters