PEP: 576 Title: Rationalize Built-in function classes
Hi, At the language summit this year, there was some discussion of PEP 575. I wanted to simplify the PEP, but rather than modify that PEP, Nick Coghlan encouraged me to write an alternative PEP instead. PEP 576 aims to fulfill the same goals as PEP 575, but with fewer changes and to be fully backwards compatible. The PEP can be viewed here: https://github.com/python/peps/blob/master/pep-0576.rst Cheers, Mark. P.S. I'm happy to have discussion of this PEP take place via GitHub, rather than the mailing list, but I thought I would follow the conventional route for now.
mark schrieb am 19.05.2018 um 11:15:
At the language summit this year, there was some discussion of PEP 575. I wanted to simplify the PEP, but rather than modify that PEP, Nick Coghlan encouraged me to write an alternative PEP instead.
PEP 576 aims to fulfill the same goals as PEP 575, but with fewer changes and to be fully backwards compatible.
The PEP can be viewed here:
Quick question, since the PEP doesn't say it explicitly. I assume that the builtin function type would be subclassable, right? That would suggest that it also needs a type flag bit for fast type checking. Basically, subclassing still seems necessary in order to support closure state, non-constant default arguments, etc. Stefan
2018-05-19 11:15 GMT+02:00 mark <mark@hotpy.org>:
The PEP can be viewed here: https://github.com/python/peps/blob/master/pep-0576.rst (...) P.S. I'm happy to have discussion of this PEP take place via GitHub, rather than the mailing list, but I thought I would follow the conventional route for now.
Previously, we required to add the full text of the PEP inside the email to be able to reply inline by email. I know that Guido van Rossum started a discussion on python-commiters to propose to change how we discuss PEPs, but I don't think that any decision has been taken at this point, no? Victor
On Tue, May 22, 2018 at 5:29 AM, Victor Stinner <vstinner@redhat.com> wrote:
2018-05-19 11:15 GMT+02:00 mark <mark@hotpy.org>:
The PEP can be viewed here: https://github.com/python/peps/blob/master/pep-0576.rst (...) P.S. I'm happy to have discussion of this PEP take place via GitHub, rather than the mailing list, but I thought I would follow the conventional route for now.
Previously, we required to add the full text of the PEP inside the email to be able to reply inline by email.
I know that Guido van Rossum started a discussion on python-commiters to propose to change how we discuss PEPs, but I don't think that any decision has been taken at this point, no?
That doesn't stop us from experimenting with the new flow. If it works, we can adopt it officially. If it doesn't work, we can ask Mark to post a copy to python-ideas (or -dev) for discussion later. ISTR there are plenty of PEPs that never get posted to python-ideas because they are discussed on a separate list. -- --Guido van Rossum (python.org/~guido)
On 22May2018 0741, Guido van Rossum wrote:
ISTR there are plenty of PEPs that never get posted to python-ideas because they are discussed on a separate list.
There are often better venues for the initial discussion (such as security-sig, distutils-sig or datetime-sig), but I think that's orthogonal from posting the full text of a PEP. That said, if the aim is to keep discussion in another place (such as github), you really don't want copies floating around any other mailing lists. Eventually I'd hope it comes through for final review though, as I'm sure a number of us are unlikely to click through to github unless we have a specific interest in the topic. Cheers, Steve
On Tue, May 22, 2018 at 10:07 AM, Steve Dower <steve.dower@python.org> wrote:
On 22May2018 0741, Guido van Rossum wrote:
ISTR there are plenty of PEPs that never get posted to python-ideas because they are discussed on a separate list.
There are often better venues for the initial discussion (such as security-sig, distutils-sig or datetime-sig), but I think that's orthogonal from posting the full text of a PEP.
I don't think that the original rationale for posting the full text of a PEP to a mailing list still applies. The raw text is on GitHub in the python/peps repo, and the formatted text is on python.org. We're not some kind of bureaucratic org that pretends to still live in the world of paper and pencil.
That said, if the aim is to keep discussion in another place (such as github), you really don't want copies floating around any other mailing lists. Eventually I'd hope it comes through for final review though, as I'm sure a number of us are unlikely to click through to github unless we have a specific interest in the topic.
IMO if you can't be bothered to click through on GitHub you forfeit your right to comment. (Which isn't a right anyway, it's a privilege.) -- --Guido van Rossum (python.org/~guido)
On 23 May 2018 at 05:47, Guido van Rossum <guido@python.org> wrote:
On Tue, May 22, 2018 at 10:07 AM, Steve Dower <steve.dower@python.org> wrote:
On 22May2018 0741, Guido van Rossum wrote:
ISTR there are plenty of PEPs that never get posted to python-ideas because they are discussed on a separate list.
There are often better venues for the initial discussion (such as security-sig, distutils-sig or datetime-sig), but I think that's orthogonal from posting the full text of a PEP.
I don't think that the original rationale for posting the full text of a PEP to a mailing list still applies. The raw text is on GitHub in the python/peps repo, and the formatted text is on python.org. We're not some kind of bureaucratic org that pretends to still live in the world of paper and pencil.
The raw text being on Github rather than hg.python.org makes the rationale for archiving full copies on mail.python.org stronger, not weaker. That said, if the aim is to keep discussion in another place (such as
github), you really don't want copies floating around any other mailing lists. Eventually I'd hope it comes through for final review though, as I'm sure a number of us are unlikely to click through to github unless we have a specific interest in the topic.
IMO if you can't be bothered to click through on GitHub you forfeit your right to comment. (Which isn't a right anyway, it's a privilege.)
I would never consider it an acceptable process restriction to require people to sign up for an account with a proprietary American software company in order to comment on the future of the Python programming language. If folks get more feedback than they have the ability to process in a short amount of time, then "Deferred" is a perfectly reasonable state to put a PEP into until they *do* have time to go through and account for the feedback - it isn't like it's a major disaster if we put an idea back on the shelf for a couple of months (or years!), let folks mull it over for a while, and then reconsider it later with fresh eyes. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
We should take the discussion about how and where PEP discussions should be hosted off this thread and list. On Wed, May 23, 2018 at 6:59 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 23 May 2018 at 05:47, Guido van Rossum <guido@python.org> wrote:
On Tue, May 22, 2018 at 10:07 AM, Steve Dower <steve.dower@python.org> wrote:
On 22May2018 0741, Guido van Rossum wrote:
ISTR there are plenty of PEPs that never get posted to python-ideas because they are discussed on a separate list.
There are often better venues for the initial discussion (such as security-sig, distutils-sig or datetime-sig), but I think that's orthogonal from posting the full text of a PEP.
I don't think that the original rationale for posting the full text of a PEP to a mailing list still applies. The raw text is on GitHub in the python/peps repo, and the formatted text is on python.org. We're not some kind of bureaucratic org that pretends to still live in the world of paper and pencil.
The raw text being on Github rather than hg.python.org makes the rationale for archiving full copies on mail.python.org stronger, not weaker.
That said, if the aim is to keep discussion in another place (such as
github), you really don't want copies floating around any other mailing lists. Eventually I'd hope it comes through for final review though, as I'm sure a number of us are unlikely to click through to github unless we have a specific interest in the topic.
IMO if you can't be bothered to click through on GitHub you forfeit your right to comment. (Which isn't a right anyway, it's a privilege.)
I would never consider it an acceptable process restriction to require people to sign up for an account with a proprietary American software company in order to comment on the future of the Python programming language.
If folks get more feedback than they have the ability to process in a short amount of time, then "Deferred" is a perfectly reasonable state to put a PEP into until they *do* have time to go through and account for the feedback - it isn't like it's a major disaster if we put an idea back on the shelf for a couple of months (or years!), let folks mull it over for a while, and then reconsider it later with fresh eyes.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-- --Guido van Rossum (python.org/~guido)
participants (6)
-
Guido van Rossum -
mark -
Nick Coghlan -
Stefan Behnel -
Steve Dower -
Victor Stinner