Mailman 3 Naming Accepted PEPs as PAPs - Python-ideas

newer
Suggest mentioning venv --upgrade...

Naming Accepted PEPs as PAPs

Abdur-Rahmaan Janhangeer

21 Sep 2020 21 Sep '20

1:26 a.m.

Greeting lists, I am thinking of proposing to name accepted PEPs as PAPs namely: Python Accepted Proposals. Hence if we say PAP8 we know it's an accepted proposal. Backstory: I quoted V. Stinner in this https://dev.to/abdurrahmaanj/the-zen-of-python-as-related-by-masters-1p9i for PEP 608 https://www.python.org/dev/peps/pep-0608/, he told me by the way it was not accepted. This got me thinking that to know accepted peps on reading or hearing of it without seeing the status, you need to be a PEP historian. But, if on the other hand you see PEP 0608, you instantly know it has not been accepted and when you hear of PAP 561 you know it is an accepted PEP I know that PEPs have different status as enumerated here https://www.python.org/dev/peps/ but at least such a naming would make a clear distinction. Curious to hear your thoughts ^^ Kind Regards, Abdur-Rahmaan Janhangeer about https://compileralchemy.github.io/ | blog https://abdur-rahmaanj.github.io/ github https://github.com/Abdur-RahmaanJ Mauritius

Attachments:

attachment.htm (text/html — 1.7 KB)

Show replies by date

Steven D'Aprano

21 Sep 21 Sep

1:59 a.m.

On Mon, Sep 21, 2020 at 10:26:45AM +0400, Abdur-Rahmaan Janhangeer wrote:

...

Greeting lists,

I am thinking of proposing to name accepted PEPs as PAPs namely: Python Accepted Proposals.

I immediately think of these: https://www.merriam-webster.com/dictionary/pap https://www.mayoclinic.org/tests-procedures/pap-smear/about/pac-20394841 I don't think I'd ever be able to shake those connotations. How would this work in practice? After a PEP is accepted, are we supposed to go back through all the references to it and change them all to PAP? Do we expect people to search for "PAP 12345" and "PEP 12345" if they are unsure whether it is accepted or not? Personally, I don't think that encoding the acceptance status in the ID is very useful. There's so much more about the PEP that doesn't get encoded in the ID, like *what it is about*. For example, if somebody mentioned PEP 450, or PAP 450, to me, I would have no clue what it was, and I wrote it! (I had to look it up to see what the number was.) I would expect that, if you know the context of the discussion and the nature of the PEP, anyone with a good knowledge of Python should be able to make a good guess of whether it was accepted or not. For example, Python doesn't have a "directive" statement, so PEP 244 "The directive statement" is probably not accepted. But Python does have nested scopes, so PEP 227 "Nested Scopes" is probably accepted. I don't think that changing the second to PAP 227 adds enough useful information to outweigh the nuisance and inconvenience of having two ways to refer to PEPs. -- Steve

Greg Ewing

2:12 a.m.

On 21/09/20 6:59 pm, Steven D'Aprano wrote:

...

On Mon, Sep 21, 2020 at 10:26:45AM +0400, Abdur-Rahmaan Janhangeer wrote:

...
I am thinking of proposing to name accepted PEPs as PAPs namely: Python Accepted Proposals.

There's precedent for *not* doing that kind of thing. "RFC" stands for "Request For Comment", and it stays that way long after it has become adopted as a standard!

...

Personally, I don't think that encoding the acceptance status in the ID is very useful. There's so much more about the PEP that doesn't get encoded in the ID, like *what it is about*. For example, if somebody mentioned PEP 450, or PAP 450, to me, I would have no clue what it was, and I wrote it!

Maybe posts to the Python lists could be passed through a filter that looks for PEP references and adds information to them. E.g. if someone typed "PEP 9876" into a post it might get replaced by "PEP 9876 - Add turboencabulation module to stdlib (Rejected)". -- Greg

Abdur-Rahmaan Janhangeer

2:35 a.m.

On Mon, Sep 21, 2020 at 11:13 AM Greg Ewing wrote:

...

There's precedent for *not* doing that kind of thing. "RFC" stands for "Request For Comment", and it stays that way long after it has become adopted as a standard!

Maybe they have not thought of doing it and also, request for comments is like the first mail on python-ideas:

...

RFCs cover many aspects of computer networking, including protocols, procedures, programs, and concepts, as well as meeting notes, opinions, and sometimes humor

PEPs are different. They are concrete documents with rationales, illustrations and now with sponsors

...

Maybe posts to the Python lists could be passed through a filter that looks for PEP references and adds information to them.

E.g. if someone typed "PEP 9876" into a post it might get replaced by "PEP 9876 - Add turboencabulation module to stdlib (Rejected)".

It would also be great to add member details like: Bumble Cee (Core dev)(61 201 karma) --- [1] https://www.ietf.org/standards/rfcs/

Chris Angelico

2:41 a.m.

On Mon, Sep 21, 2020 at 5:39 PM Abdur-Rahmaan Janhangeer wrote:

...

On Mon, Sep 21, 2020 at 11:13 AM Greg Ewing wrote:

...
There's precedent for *not* doing that kind of thing. "RFC" stands for "Request For Comment", and it stays that way long after it has become adopted as a standard!

Maybe they have not thought of doing it and also, request for comments is like the first mail on python-ideas:

...
RFCs cover many aspects of computer networking, including protocols, procedures, programs, and concepts, as well as meeting notes, opinions, and sometimes humor

PEPs are different. They are concrete documents with rationales, illustrations and now with sponsors

Ah yes, there aren't any PEPs with opinions or humour, how silly to think that they're like RFCs. https://www.python.org/dev/peps/pep-0628/ https://www.python.org/dev/peps/pep-0404/ https://www.python.org/dev/peps/pep-0401/ ChrisA

Barry Scott

12:28 p.m.

...

On 21 Sep 2020, at 08:35, Abdur-Rahmaan Janhangeer wrote:

Maybe they have not thought of doing it and also, request for comments is like the first mail on python-ideas

You might find this interesting on RFC process: https://en.wikipedia.org/wiki/Request_for_Comments Or maybe they have thought of doing this and rejected it. Barry

David Lowry-Duda

11:28 a.m.

On Mon, Sep 21, 2020 at 07:12:37PM +1200, Greg Ewing wrote:

...

On 21/09/20 6:59 pm, Steven D'Aprano wrote:

...
On Mon, Sep 21, 2020 at 10:26:45AM +0400, Abdur-Rahmaan Janhangeer wrote:

...
I am thinking of proposing to name accepted PEPs as PAPs namely: Python Accepted Proposals.

There's precedent for *not* doing that kind of thing. "RFC" stands for "Request For Comment", and it stays that way long after it has become adopted as a standard!

Indeed, I also first thought about RFCs and how they remain being called RFCs. I see no reason why we should think about changing PEPs.

...

Maybe posts to the Python lists could be passed through a filter that looks for PEP references and adds information to them.

E.g. if someone typed "PEP 9876" into a post it might get replaced by "PEP 9876 - Add turboencabulation module to stdlib (Rejected)".

This is an interesting thought. I wonder how hard this would be to implement in practice. - DLD -- David Lowry-Duda

Abdur-Rahmaan Janhangeer

12:09 p.m.

Kind Regards, Abdur-Rahmaan Janhangeer about https://compileralchemy.github.io/ | blog https://abdur-rahmaanj.github.io/ github https://github.com/Abdur-RahmaanJ Mauritius On Mon, Sep 21, 2020 at 8:41 PM David Lowry-Duda wrote:

...

I see no reason why we should think about changing PEPs.

Please see first mail in the thread.

Eric V. Smith

12:19 p.m.

On 9/21/2020 1:09 PM, Abdur-Rahmaan Janhangeer wrote:

...

Kind Regards,

Abdur-Rahmaan Janhangeer about https://compileralchemy.github.io/ | blog https://abdur-rahmaanj.github.io/ github https://github.com/Abdur-RahmaanJ Mauritius

On Mon, Sep 21, 2020 at 8:41 PM David Lowry-Duda mailto:david@lowryduda.com> wrote:

I see no reason why we should think about changing PEPs.

Please see first mail in the thread.

I don't find the reasons in the first email persuasive. Having two names for one document, and names that vary over time, will only make searching for information more difficult. Eric

Cameron Simpson

4:20 p.m.

New subject: annotating PEP mentions (was: Naming Accepted PEPs as PAPs)

On 21Sep2020 12:28, David Lowry-Duda wrote:

...

On Mon, Sep 21, 2020 at 07:12:37PM +1200, Greg Ewing wrote:

...
Maybe posts to the Python lists could be passed through a filter that looks for PEP references and adds information to them.

E.g. if someone typed "PEP 9876" into a post it might get replaced by "PEP 9876 - Add turboencabulation module to stdlib (Rejected)".

This is an interesting thought. I wonder how hard this would be to implement in practice.

It is neat. I've certainly worked in Slack channels where there's a robot watching messages, and when someone types a bug number (with its distinctive prefix) the robot inserts a reference (as a clickable link) and a one line title summary much as suggested above. It's extremely useful. And I once wrote a wiki edit form which did the same for bug numbers at a former employment. Certainly I am a bit irritated by bare PEP mentions, particularly in subject lines (where, admittedly, space is tight). If you've involved in that PEP it's all fine because you have the context, but as a spectator it is a bit opaque. Since I use mutt it might be tractable for me to modify the display_filter I use to perform this edit. It'd need a small backing store to avoid having to do an HTTP callout on each reference, but I have one of those... Cheers, Cameron Simpson

Abdur-Rahmaan Janhangeer

2:25 a.m.

...

On Mon, Sep 21, 2020 at 10:26:45AM +0400, Abdur-Rahmaan Janhangeer wrote:

...
Greeting lists,

I am thinking of proposing to name accepted PEPs as PAPs namely: Python Accepted Proposals.

I immediately think of these:

https://www.merriam-webster.com/dictionary/pap

https://www.mayoclinic.org/tests-procedures/pap-smear/about/pac-20394841

**laughs** nice point, it depends on your dictionary: https://dictionary.cambridge.org/dictionary/english/pap gives food that is soft and has little taste or as short for paparazzi Also let's say we found another better replacement, let's see the below point

...

How would this work in practice? After a PEP is accepted, are we supposed to go back through all the references to it and change them all to PAP? Do we expect people to search for "PAP 12345" and "PEP 12345" if they are unsure whether it is accepted or not?

For future PEPs. People have to remember that after PEP x you have PEPs and 'PAP's Personally, I don't think that encoding the acceptance status in the ID

...

is very useful. There's so much more about the PEP that doesn't get encoded in the ID, like *what it is about*. For example, if somebody mentioned PEP 450, or PAP 450, to me, I would have no clue what it was, and I wrote it! (I had to look it up to see what the number was.)

That's why the references exist, so that you look the details up. But knowing at a glance the status of a PEP immediately changes the perception of the text at hand I would expect that, if you know the context of the discussion and the

...

nature of the PEP, anyone with a good knowledge of Python should be able to make a good guess of whether it was accepted or not.

I quote the first mail:

...

... you need to be a PEP historian

...

For example, Python doesn't have a "directive" statement, so PEP 244 "The directive statement" is probably not accepted. But Python does have nested scopes, so PEP 227 "Nested Scopes" is probably accepted.

I quote the first mail:

...

I know that PEPs have different status as enumerated here https://www.python.org/dev/peps/

There are no PEPs as ' is probably accepted.', the status is enumerated above

...

I don't think that changing the second to PAP 227 adds enough useful information to outweigh the nuisance and inconvenience of having two ways to refer to PEPs.

2 ways for past PEPs and 1 way for future PEPs

Steven D'Aprano

2:44 a.m.

On Mon, Sep 21, 2020 at 11:25:52AM +0400, Abdur-Rahmaan Janhangeer wrote:

...

...
How would this work in practice? After a PEP is accepted, are we supposed to go back through all the references to it and change them all to PAP? Do we expect people to search for "PAP 12345" and "PEP 12345" if they are unsure whether it is accepted or not?

For future PEPs. People have to remember that after PEP x you have PEPs and 'PAP's

No, for future PEPs you will still have to look for "PEP x" as well, because they won't be created in the accepted state. So there will be discussion of the PEP under "PEP". Most of the discussion will be prior to acceptance, so most references will be under "PEP" and hardly anything under "PAP".

...

...
Personally, I don't think that encoding the acceptance status in the ID is very useful. There's so much more about the PEP that doesn't get encoded in the ID, like *what it is about*. For example, if somebody mentioned PEP 450, or PAP 450, to me, I would have no clue what it was, and I wrote it! (I had to look it up to see what the number was.)

That's why the references exist, so that you look the details up. But knowing at a glance the status of a PEP immediately changes the perception of the text at hand

Once you look it up, you can tell the status at a glance because it is right there at the top of the PEP with the other headers. If you don't look it up, knowing that it is accepted doesn't tell you much. Why would I care that PEP 12345 is accepted, if I don't know what PEP 12345 is about?

...

...
I would expect that, if you know the context of the discussion and the nature of the PEP, anyone with a good knowledge of Python should be able to make a good guess of whether it was accepted or not.

I quote the first mail:

...
... you need to be a PEP historian

Not always. You often just need to know Python. Surely you can tell the difference between features that are in the existing language like nested scopes, the walrus operator, or the secrets module, and features that aren't, like the directive operator, the list.uniq method, and int for loops, without looking them up? In my opinion, "accepted versus not accepted" is one of the least important and least informative parts of a PEP.

...

There are no PEPs as ' is probably accepted.', the status is enumerated above

I know that "probably accepted" is not a status, it is a judgement or prediction of what the status is without needing to either look it up or be a historian of PEPs. -- Steve

Abdur-Rahmaan Janhangeer

3:37 a.m.

Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius On Mon, Sep 21, 2020 at 11:46 AM Steven D'Aprano wrote:

...

On Mon, Sep 21, 2020 at 11:25:52AM +0400, Abdur-Rahmaan Janhangeer wrote:

...
...
How would this work in practice? After a PEP is accepted, are we supposed to go back through all the references to it and change them all to PAP? Do we expect people to search for "PAP 12345" and "PEP 12345" if they are unsure whether it is accepted or not?

For future PEPs. People have to remember that after PEP x you have PEPs and 'PAP's

No, for future PEPs you will still have to look for "PEP x" as well, because they won't be created in the accepted state. So there will be discussion of the PEP under "PEP". Most of the discussion will be prior to acceptance, so most references will be under "PEP" and hardly anything under "PAP".

By future PEPs i mean future PEP naming, Not about PEP referencing

...

If you don't look it up, knowing that it is accepted doesn't tell you much. Why would I care that PEP 12345 is accepted, if I don't know what PEP 12345 is about?

When someone talks about PEP 12345, they give details etc e.g:

...

PEP 345 talks about introducing type this and that

unless you are robots, the person will give some background info but the above though not saying anything wrong does not tell whether or not it's an accepted PEP, whether you can form further opinions or not

...

...
...
I would expect that, if you know the context of the discussion and the nature of the PEP, anyone with a good knowledge of Python should be able to make a good guess of whether it was accepted or not.

I quote the first mail:

...
... you need to be a PEP historian

Not always. You often just need to know Python.

It depends on what you mean by know

...

Surely you can tell the difference between features that are in the existing language like nested scopes, the walrus operator, or the secrets module, and features that aren't, like the directive operator, the list.uniq method, and int for loops, without looking them up?

In my opinion, "accepted versus not accepted" is one of the least important and least informative parts of a PEP.

By accepted it means the PEP made a significant change in the Python language.

Paul Moore

3:20 a.m.

On Mon, 21 Sep 2020 at 08:29, Abdur-Rahmaan Janhangeer wrote:

...

That's why the references exist, so that you look the details up. But knowing at a glance the status of a PEP immediately changes the perception of the text at hand

You are very optimistic that people will remember to make this distinction. Personally, I suspect I'll consistently forget and just use "PEP" anyway...

...

...
I know that PEPs have different status as enumerated here

I'm surprised you don't feel that "Rejected" status is worth capturing as well. And what about Provisional? Honestly, if it's not clear from context whether someone is talking about an existing language feature (i.e., an accepted PEP) or an open proposal (or, for that matter, a proposal that got abandoned, or a rejected idea, etc) then they probably aren't explaining themselves very clearly anyway. Maybe just ask them to clarify if you don't want to check for yourself? Paul

Abdur-Rahmaan Janhangeer

3:49 a.m.

Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius On Mon, Sep 21, 2020 at 12:20 PM Paul Moore wrote:

...

On Mon, 21 Sep 2020 at 08:29, Abdur-Rahmaan Janhangeer wrote:

...

...
...
I know that PEPs have different status as enumerated here

I'm surprised you don't feel that "Rejected" status is worth capturing as well. And what about Provisional?

Accepted designates PEPs that have been been implemented and released. Not as in ''Accepted; may not be implemented yet", even if it was the case, the case still holds as the dividing line.

...

Honestly, if it's not clear from context whether someone is talking about an existing language feature (i.e., an accepted PEP) or an open proposal (or, for that matter, a proposal that got abandoned, or a rejected idea, etc) then they probably aren't explaining themselves very clearly anyway. Maybe just ask them to clarify if you don't want to check for yourself?

Not always possible if eg in writing or not worth a mail if few searches can be made The question does not arise if one can always find it on his own.

Barry Scott

12:23 p.m.

...

On 21 Sep 2020, at 07:26, Abdur-Rahmaan Janhangeer wrote:

Greeting lists,

I am thinking of proposing to name accepted PEPs as PAPs namely: Python Accepted Proposals.

Hence if we say PAP8 we know it's an accepted proposal.

Backstory:

I quoted V. Stinner in this https://dev.to/abdurrahmaanj/the-zen-of-python-as-related-by-masters-1p9i for PEP 608 https://www.python.org/dev/peps/pep-0608/, he told me by the way it was not accepted. This got me thinking that to know accepted peps on reading or hearing of it without seeing the status, you need to be a PEP historian. But, if on the other hand you see PEP 0608, you instantly know it has not been accepted and when you hear of PAP 561 you know it is an accepted PEP

I know that PEPs have different status as enumerated here https://www.python.org/dev/peps/ but at least such a naming would make a clear distinction.

Curious to hear your thoughts ^^

This is like RFC that can be draft, accepted or rejected. RFC's have not needed to change there names. I'd rather not have PEP's change there names either. As you say there is a Status in the PEP that is clear. I see that the RFC docs have more info like "obsoleted by" and "updated by" info. I work with RFC's all the time an appreciate the forward and backward references. So if I'm working on code that refers to an RFC I can check to see if it is still current for example. Barry

...

Kind Regards,

Abdur-Rahmaan Janhangeer about https://compileralchemy.github.io/ | blog https://abdur-rahmaanj.github.io/ github https://github.com/Abdur-RahmaanJ Mauritius _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MQWM42... Code of Conduct: http://python.org/psf/codeofconduct/

Abdur-Rahmaan Janhangeer

12:42 p.m.

...

This is like RFC that can be draft, accepted or rejected. RFC's have not needed to change there names. I'd rather not have PEP's change there names either.

As you say there is a Status in the PEP that is clear.

I see that the RFC docs have more info like "obsoleted by" and "updated by" info.

I work with RFC's all the time an appreciate the forward and backward references. So if I'm working on code that refers to an RFC I can check to see if it is still current for example.

The 3 last mails have not added much to the discussion. Pinning down on RFC is like saying we'll give cat the same food as catfish as they both do seem similar and we have not found the need to change catfish food since we have been giving them to catfish. I seem to think that people do read each and every mail in an ongoing thread to know what has already covered so as to elaborate and enrich the discussion but i have the impression i am wrong. Saying 'Agile is the new gold' twice or twenty times does not effectively make Agile the new gold.

Barry Scott

12:55 p.m.

...

On 21 Sep 2020, at 18:42, Abdur-Rahmaan Janhangeer wrote:

Kind Regards,

Abdur-Rahmaan Janhangeer about https://compileralchemy.github.io/ | blog https://abdur-rahmaanj.github.io/ github https://github.com/Abdur-RahmaanJ Mauritius

On Mon, Sep 21, 2020 at 9:23 PM Barry Scott mailto:barry@barrys-emacs.org> wrote:

This is like RFC that can be draft, accepted or rejected. RFC's have not needed to change there names. I'd rather not have PEP's change there names either.

As you say there is a Status in the PEP that is clear.

I see that the RFC docs have more info like "obsoleted by" and "updated by" info.

I work with RFC's all the time an appreciate the forward and backward references. So if I'm working on code that refers to an RFC I can check to see if it is still current for example.

The 3 last mails have not added much to the discussion. Pinning down on RFC is like saying we'll give cat the same food as catfish as they both do seem similar and we have not found the need to change catfish food since we have been giving them to catfish. I seem to think that people do read each and every mail in an ongoing thread to know what has already covered so as to elaborate and enrich the discussion but i have the impression i am wrong. Saying 'Agile is the new gold' twice or twenty times does not effectively make Agile the new gold.

No they are saying that PEP and RFC are the same type of thing with the same type of users. RFC is older then PEP and could have changed but did not. The RFC process works. I also think that the PEP process works. Multiple people independently offered up RFC as similar process. I do not see what problem PAP will solve that will not create more problems then it *may* solve. And I'm not convinced that there is a problem to solve. Barry

Abdur-Rahmaan Janhangeer

1:03 p.m.

...

No they are saying that PEP and RFC are the same type of thing with the same type of users.

Any person saying this may refer to reasons on this thread saying that they are not and then he elaborates why he thinks those reasons are not worth it instead of only saying they are effectively like it.

Chris Angelico

12:59 p.m.

On Tue, Sep 22, 2020 at 3:46 AM Abdur-Rahmaan Janhangeer wrote:

...

The 3 last mails have not added much to the discussion. Pinning down on RFC is like saying we'll give cat the same food as catfish as they both do seem similar and we have not found the need to change catfish food since we have been giving them to catfish. I seem to think that people do read each and every mail in an ongoing thread to know what has already covered so as to elaborate and enrich the discussion but i have the impression i am wrong. Saying 'Agile is the new gold' twice or twenty times does not effectively make Agile the new gold.

Can you explain to us what we'd gain by having a complete name change once a PEP becomes accepted? ChrisA

Abdur-Rahmaan Janhangeer

1:13 p.m.

...

Can you explain to us what we'd gain by having a complete name change once a PEP becomes accepted?

A proposal means a suggestion. People propose enhancement suggestions. They were suggestions to the Python committee, but now they have been accepted, carried forward and executed. They now have become documents on which the language bases itself. All law projects remain law projects. But we call law projects which has been accepted as law.

Chris Angelico

1:18 p.m.

On Tue, Sep 22, 2020 at 4:13 AM Abdur-Rahmaan Janhangeer wrote:

...

On Mon, Sep 21, 2020 at 10:00 PM Chris Angelico wrote:

...
Can you explain to us what we'd gain by having a complete name change once a PEP becomes accepted?

A proposal means a suggestion. People propose enhancement suggestions. They were suggestions to the Python committee, but now they have been accepted, carried forward and executed. They now have become documents on which the language bases itself. All law projects remain law projects. But we call law projects which has been accepted as law.

PEPs don't get updated as future requirements cause changes in the language. They remain as they were: the proposal. Changing the name because of a change in the PEP's metadata seems like a very backwards way to do things; among other things, it would lead people to consider "PAPs" to be somehow authorative while "PEPs" are not, which would leave informational and process PEPs in an awkward situation of being neither non-accepted nor accepted, and would also encourage people to treat the "PAP" as superior to the documentation. Neither is, in my opinion, an advantage. Additionally, changing the *name* of a document means that every reference has to be changed, which is an absurd waste of time. The only advantage you've offered is some relatively weak notion that it ceases to be a proposal once it's accepted, and since "PAP" would still have the word "Proposal" in it, you're not really even changing that. Let's not waste everyone's time for zero benefit. Thanks. ChrisA PEP editor who really doesn't feel like trying to support two names for the same things

Abdur-Rahmaan Janhangeer

1:39 p.m.

...

PEPs don't get updated as future requirements cause changes in the language. They remain as they were: the proposal. Changing the name because of a change in the PEP's metadata seems like a very backwards way to do things; among other things, it would lead people to consider "PAPs" to be somehow authorative while "PEPs" are not, which would leave informational and process PEPs in an awkward situation of being neither non-accepted nor accepted,

I referred PEP8, a meta-pep as PAP8 in the first mail itself and should have been one of the first tripping lines of the discussion. If such PEPs are included under PAPs, the 'authorative' point holds as it should be

...

Additionally, changing the *name* of a document means that every reference has to be changed,

I guess you mean on the website itself. It's a nice point which i was expecting. As with any change, some changes are expected and if i am not mistaken, the source is some text documents and updating them means running a script over them locally.

...

The only advantage you've offered is some relatively weak notion that it ceases to be a proposal once it's accepted, and since "PAP" would still have the word "Proposal" in it, you're not really even changing that.

...

All law projects remain law projects. But we call law projects which has been accepted as law.

...

Let's not waste everyone's time for zero benefit. Thanks.

ChrisA PEP editor who really doesn't feel like trying to support two names for the same things

If we change even past accepted PEPs it's one name for one thing. The thread dying off is in itself a sign that the idea is weak and does not hold much value. But if someone brings a point that would re-start the discussion i think it's better to notify him. I'm good if the thread dies off without any further input than rebringing what has already been told.

Chris Angelico

1:44 p.m.

On Tue, Sep 22, 2020 at 4:39 AM Abdur-Rahmaan Janhangeer wrote:

...

Kind Regards,

Abdur-Rahmaan Janhangeer about | blog github Mauritius

(This signature at the TOP of every post is just getting in the way, is there any way to move it to the bottom where it belongs?)

...

On Mon, Sep 21, 2020 at 10:19 PM Chris Angelico wrote:

...
PEPs don't get updated as future requirements cause changes in the language. They remain as they were: the proposal. Changing the name because of a change in the PEP's metadata seems like a very backwards way to do things; among other things, it would lead people to consider "PAPs" to be somehow authorative while "PEPs" are not, which would leave informational and process PEPs in an awkward situation of being neither non-accepted nor accepted,

I referred PEP8, a meta-pep as PAP8 in the first mail itself and should have been one of the first tripping lines of the discussion. If such PEPs are included under PAPs, the 'authorative' point holds as it should be

At what point does an informational PEP turn into a PAP? For instance, PEP 596 is currently "draft" - does that mean it isn't authoritative?

...

...
Additionally, changing the *name* of a document means that every reference has to be changed,

I guess you mean on the website itself. It's a nice point which i was expecting. As with any change, some changes are expected and if i am not mistaken, the source is some text documents and updating them means running a script over them locally.

On the web site, on Stack Overflow, on people's blogs, in published printed books, YouTube videos.... *everywhere*.

...

If we change even past accepted PEPs it's one name for one thing. The thread dying off is in itself a sign that the idea is weak and does not hold much value. But if someone brings a point that would re-start the discussion i think it's better to notify him. I'm good if the thread dies off without any further input than rebringing what has already been told.

If someone brings up a point that would restart the discussion, I hope that all these preceding arguments cause it to be left by the wayside immediately. ChrisA

Abdur-Rahmaan Janhangeer

1:55 p.m.

On Mon, Sep 21, 2020 at 10:47 PM Chris Angelico wrote:

...

(This signature at the TOP of every post is just getting in the way, is there any way to move it to the bottom where it belongs?)

I use Gmail and the signature always floats. I don't remember putting it in that irritating place. Will try to find the setting that moves signatures after replies. I manually deleted it in this mail.

...

At what point does an informational PEP turn into a PAP? For instance, PEP 596 is currently "draft" - does that mean it isn't authoritative?

We must ask the one who formulated the wording: (under consideration)

...

On the web site, on Stack Overflow, on people's blogs, in published printed books, YouTube videos.... *everywhere*.

That you can't change. Take the Python wiki itself which still contains PyQt4 which is obsolete by now and which i put on my list to update it to it's equivalent PyQt5 when and if i get the time

David Mertz

2:13 p.m.

This is a silly proposal with absolutely zero benefit, none that I can even see purported in the suggestion itself, let alone in reality. On Mon, Sep 21, 2020 at 8:47 AM Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:

...

Kind Regards,

Abdur-Rahmaan Janhangeer about https://compileralchemy.github.io/ | blog https://abdur-rahmaanj.github.io/ github https://github.com/Abdur-RahmaanJ Mauritius

On Mon, Sep 21, 2020 at 10:19 PM Chris Angelico wrote:

...
PEPs don't get updated as future requirements cause changes in the language. They remain as they were: the proposal. Changing the name because of a change in the PEP's metadata seems like a very backwards way to do things; among other things, it would lead people to consider "PAPs" to be somehow authorative while "PEPs" are not, which would leave informational and process PEPs in an awkward situation of being neither non-accepted nor accepted,

I referred PEP8, a meta-pep as PAP8 in the first mail itself and should have been one of the first tripping lines of the discussion. If such PEPs are included under PAPs, the 'authorative' point holds as it should be

...
Additionally, changing the *name* of a document means that every reference has to be changed,

I guess you mean on the website itself. It's a nice point which i was expecting. As with any change, some changes are expected and if i am not mistaken, the source is some text documents and updating them means running a script over them locally.

...
The only advantage you've offered is some relatively weak notion that it ceases to be a proposal once it's accepted, and since "PAP" would still have the word "Proposal" in it, you're not really even changing that.

...
All law projects remain law projects. But we call law projects which has been accepted as law.

...
Let's not waste everyone's time for zero benefit. Thanks.

ChrisA PEP editor who really doesn't feel like trying to support two names for the same things

If we change even past accepted PEPs it's one name for one thing. The thread dying off is in itself a sign that the idea is weak and does not hold much value. But if someone brings a point that would re-start the discussion i think it's better to notify him. I'm good if the thread dies off without any further input than rebringing what has already been told. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MGYDRF... 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.

Abdur-Rahmaan Janhangeer

2:37 p.m.

On Mon, 21 Sep 2020, 23:13 David Mertz, wrote:

...

This is a silly proposal with absolutely zero benefit, none that I can even see purported in the suggestion itself, let alone in reality.

Thank you for your thoughts but i guess this mail does not add anything new to the thread nor does it explain what it intends to convey. Kind regards, Abdur-Rahmaan Janhangeer

...

edwin＠211mainstreet.net

2:45 p.m.

September 21, 2020 3:37 PM, "Abdur-Rahmaan Janhangeer" )> wrote: On Mon, 21 Sep 2020, 23:13 David Mertz, wrote:This is a silly proposal with absolutely zero benefit, none that I can even see purported in the suggestion itself, let alone in reality.Thank you for your thoughts but i guessthis mail does not add anything newto the thread nor does it explain whatit intends to convey.Kind regards,Abdur-Rahmaan Janhangeer Actually, it conveys in a very plain manner that David Mertz does not think your idea is a good one. Please stop being so dismissive of others' comments. It does not endear you to them. --Edwin

David Mertz

2:53 p.m.

I knew it wasn't April 1 when I saw the idea, but I tried to think about if there might be some other joke I was missing. Maybe something with the word "pap" that a few people have posted various definitions of. FWIW, I'm one of those authors who has printed works that includes discussion of various PEPs, using that acronym. Also to various RFCs, likewise. And always to ISO 8601, of course :-). I like those acronyms. On Mon, Sep 21, 2020 at 9:45 AM wrote:

...

September 21, 2020 3:37 PM, "Abdur-Rahmaan Janhangeer" < arj.python@gmail.com > wrote:

On Mon, 21 Sep 2020, 23:13 David Mertz, wrote:

This is a silly proposal with absolutely zero benefit, none that I can even see purported in the suggestion itself, let alone in reality.

Thank you for your thoughts but i guess this mail does not add anything new to the thread nor does it explain what it intends to convey. Kind regards, Abdur-Rahmaan Janhangeer

Actually, it conveys in a very plain manner that David Mertz does not think your idea is a good one. Please stop being so dismissive of others' comments. It does not endear you to them.

--Edwin

Abdur-Rahmaan Janhangeer

3:03 p.m.

On Mon, 21 Sep 2020, 23:45 , wrote:

...

Actually, it conveys in a very plain manner that David Mertz does not think your idea is a good one. Please stop being so dismissive of others' comments. It does not endear you to them.

This list is about discussing the idea, not only stating an opinion. I know i am not endearing people to me but i prefer threads to remain short and on topic which helps projects like these: https://abdur-rahmaanj.github.io/pyfaq The lists make great finds but it's more difficult when many mails which don't bring value to the discussion are present I know that taking the pain to write a mail is an act of great consideration but maybe i don't have the tact to express myself as deem ok. On python lists since i have been following them, i prefer threads die than having it continue just for the sake of it continueing, like the present thread is doing. Kind regards, Abdur-Rahmaan Janhangeer

...

Paul Moore

3:54 p.m.

On Mon, 21 Sep 2020 at 21:07, Abdur-Rahmaan Janhangeer wrote:

...

On python lists since i have been following them, i prefer threads die than having it continue just for the sake of it continueing, like the present thread is doing.

If you prefer the thread to die if people are not interested, I respectfully suggest that rather than continually respond (which just feels like you need to always have the last word) you simply stop reiterating your previous comments, and replying to every message posted here saying nothing but that you disagree. It's basically just you that's keeping the thread alive at the moment. For what it's worth, I don't think this idea is workable or useful. If you want this thread to die, as you say you do, please do *not* reply. Either to this message, or to any future messages where all you would say is that you don't agree. Paul

Kyle Stanley

7:01 p.m.

On Mon, Sep 21, 2020 at 4:04 PM Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:

...

This list is about discussing the idea, not only stating an opinion. I know i am not endearing people to me but i prefer threads to remain short and on topic which helps projects like these: https://abdur-rahmaanj.github.io/pyfaq The lists make great finds but it's more difficult when many mails which don't bring value to the discussion are present

Having some number of +1/-1s are useful in python-ideas threads, especially coming from those with significant relevant experience or have some influence in whether the proposal will be eventually accepted (such as core devs, who could potentially sponsor the eventual PEP). In-depth feedback contributes more to the topic, but without those +1/-1s, it's harder to assess if the idea has gained enough traction to justify turning it into a PEP (or simply implementing a feature). Sorry if that adds to the volume of messages to sort through, but that's just simply how python-ideas works. FWIW, I'm personally against the proposal because it's trivial to look up the PEP to figure out those additional details, which you would likely have to do anyways if you weren't familiar with that PEP. It's not worth a significant change in convention that would require a significant mental shift from practically the entire Python community. It would require a conscious effort to check if the PEP was accepted prior to deciding whether to use "PEP" or "PAP", as well as the initial learning to figure out "WTF is a PAP?". For an individual it would be a small cost, but if you were to consider that small cost replicated for all of the millions of Python users and thousands of reference materials that would need to be updated to address "PAP", it doesn't seem worth the marginal at best benefit. Regards, Kyle Stanley

Marco Sulla

22 Sep 22 Sep

8:30 a.m.

For me, the only good thing to differentiate between accepted and rejected PEPs is to get a look at the old rejected ones, to see if there's some ideas I can stea... take inspiration. But https://www.python.org/dev/peps/ already does it. PS: PAP remembers me the PAP test.

Greg Ewing

21 Sep 21 Sep

6:30 p.m.

On 22/09/20 6:39 am, Abdur-Rahmaan Janhangeer wrote:

...

I referred PEP8, a meta-pep as PAP8 in the first mail itself If such PEPs are included under PAPs, the 'authorative' point holds

Informational PEPs such as PEP 8 are relatively rare. I don't think the whole PEP process should be warped just because of them. Arguably they shouldn't even be called PEPs in the first place. -- Greg

David Lowry-Duda

1:52 p.m.

On Tue, Sep 22, 2020 at 04:18:42AM +1000, Chris Angelico wrote:

...

PEPs don't get updated as future requirements cause changes in the language. They remain as they were: the proposal. Changing the name because of a change in the PEP's metadata seems like a very backwards way to do things; among other things, it would lead people to consider "PAPs" to be somehow authorative while "PEPs" are not, which would leave informational and process PEPs in an awkward situation of being neither non-accepted nor accepted, and would also encourage people to treat the "PAP" as superior to the documentation. Neither is, in my opinion, an advantage. Additionally, changing the *name* of a document means that every reference has to be changed, which is an absurd waste of time.

This is very well said. And I'll add that much of this remains in close analogy to RFCs.

...

The only advantage you've offered is some relatively weak notion that it ceases to be a proposal once it's accepted, and since "PAP" would still have the word "Proposal" in it, you're not really even changing that.

The suggestion seems to target situations where a PEP#### is referred to, but is simultaneously - so well-understood that one doesn't need to look it up to see what it says, - and yet so unknown that it's not clear what its status is. This seems so rare that maintaining different names sounds far more troublesome.

...

Let's not waste everyone's time for zero benefit. Thanks.

Indeed. -- David Lowry-Duda

Abdur-Rahmaan Janhangeer

2 p.m.

...

This is very well said. And I'll add that much of this remains in close analogy to RFCs.

...

...
Let's not waste everyone's time for zero benefit. Thanks.

Indeed.

Thanks for your input. That's why i said:

...

Saying 'Agile is the new gold' twice or twenty times does not effectively make Agile the new gold.

If someone well said something and you would only +1 it, it's better not to re-write it.

...

I'm good if the thread dies off without any further input than rebringing what has already been told.

Greg Ewing

6:30 p.m.

On 22/09/20 6:13 am, Abdur-Rahmaan Janhangeer wrote:

...

All law projects remain law projects. But we call law projects which has been accepted as law.

I take it you're referring to the fact that (in some places at least) a proposed law is called a "bill" and when accepted becomes an "act". That's not quite the same thing. The "act" is the defining document of the law, but an accepted PEP is *not* documentation. When a PEP is accepted, the documentation is updated accordingly, and the PEP remains as a historical artifact. What gets implemented and documented doesn't even have to be exactly the same as what is in the PEP. In this regard, PEPs are actually a bit different from RFCs, which do become defining documents. But that's even more reason not to change their name. -- Greg

1309

Age (days ago)

1310

Last active (days ago)

List overview

Download

36 comments

13 participants

participants (13)

Abdur-Rahmaan Janhangeer
Barry Scott
Cameron Simpson
Chris Angelico
David Lowry-Duda
David Mertz
edwin＠211mainstreet.net
Eric V. Smith
Greg Ewing
Kyle Stanley
Marco Sulla
Paul Moore
Steven D'Aprano

Naming Accepted PEPs as PAPs

tags

participants (13)