Naming Accepted PEPs as PAPs
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
On Mon, Sep 21, 2020 at 10:26:45AM +0400, Abdur-Rahmaan Janhangeer wrote:
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
On 21/09/20 6:59 pm, Steven D'Aprano 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 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
On Mon, Sep 21, 2020 at 11:13 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
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
It would also be great to add member details like: Bumble Cee (Core dev)(61 201 karma) --- [1] https://www.ietf.org/standards/rfcs/
On Mon, Sep 21, 2020 at 5:39 PM Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:
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
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
On Mon, Sep 21, 2020 at 07:12:37PM +1200, Greg Ewing wrote:
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.
This is an interesting thought. I wonder how hard this would be to implement in practice. - DLD -- David Lowry-Duda <david@lowryduda.com> <davidlowryduda.com>
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 <david@lowryduda.com> wrote:
I see no reason why we should think about changing PEPs.
Please see first mail in the thread.
On 21Sep2020 12:28, David Lowry-Duda <david@lowryduda.com> wrote:
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 <cs@cskk.id.au>
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 11:01 AM Steven D'Aprano <steve@pearwood.info> wrote:
**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
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
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
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
2 ways for past PEPs and 1 way for future PEPs
On Mon, Sep 21, 2020 at 11:25:52AM +0400, Abdur-Rahmaan Janhangeer wrote:
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".
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?
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
Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius On Mon, Sep 21, 2020 at 11:46 AM Steven D'Aprano <steve@pearwood.info> wrote:
By future PEPs i mean future PEP naming, Not about PEP referencing
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
It depends on what you mean by know
By accepted it means the PEP made a significant change in the Python language.
On Mon, 21 Sep 2020 at 08:29, Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:
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
Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius On Mon, Sep 21, 2020 at 12:20 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Mon, 21 Sep 2020 at 08:29, Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:
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.
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.
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 On Mon, Sep 21, 2020 at 9:23 PM Barry Scott <barry@barrys-emacs.org> 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.
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
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:55 PM Barry Scott <barry@barrys-emacs.org> wrote:
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.
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:00 PM Chris Angelico <rosuav@gmail.com> 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.
On Tue, Sep 22, 2020 at 4:13 AM Abdur-Rahmaan Janhangeer <arj.python@gmail.com> 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. 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
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 <rosuav@gmail.com> wrote:
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.
All law projects remain law projects. But we call law projects which has been accepted as law.
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.
On Tue, Sep 22, 2020 at 4:39 AM Abdur-Rahmaan Janhangeer <arj.python@gmail.com> 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?)
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?
On the web site, on Stack Overflow, on people's blogs, in published printed books, YouTube videos.... *everywhere*.
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
On Mon, Sep 21, 2020 at 10:47 PM Chris Angelico <rosuav@gmail.com> 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
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:
-- 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 Mon, 21 Sep 2020, 23:13 David Mertz, <mertz@gnosis.cx> 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
September 21, 2020 3:37 PM, "Abdur-Rahmaan Janhangeer" <arj.python@gmail.com (mailto:arj.python@gmail.com?to=%22Abdur-Rahmaan%20Janhangeer%22%20<arj.python@gmail.com>)> wrote: On Mon, 21 Sep 2020, 23:13 David Mertz, <mertz@gnosis.cx (mailto:mertz@gnosis.cx)> 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
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 <edwin@211mainstreet.net> wrote:
-- 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 Mon, 21 Sep 2020, 23:45 , <edwin@211mainstreet.net> 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 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
On Mon, 21 Sep 2020 at 21:07, Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:
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
On Mon, Sep 21, 2020 at 4:04 PM Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:
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
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.
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
On Tue, Sep 22, 2020 at 04:18:42AM +1000, Chris Angelico wrote:
This is very well said. And I'll add that much of this remains in close analogy to RFCs.
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 <david@lowryduda.com> <davidlowryduda.com>
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:52 PM David Lowry-Duda <david@lowryduda.com> wrote:
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.
On 22/09/20 6:13 am, Abdur-Rahmaan Janhangeer wrote:
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
On Mon, Sep 21, 2020 at 10:26:45AM +0400, Abdur-Rahmaan Janhangeer wrote:
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
On 21/09/20 6:59 pm, Steven D'Aprano 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 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
On Mon, Sep 21, 2020 at 11:13 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
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
It would also be great to add member details like: Bumble Cee (Core dev)(61 201 karma) --- [1] https://www.ietf.org/standards/rfcs/
On Mon, Sep 21, 2020 at 5:39 PM Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:
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
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
On Mon, Sep 21, 2020 at 07:12:37PM +1200, Greg Ewing wrote:
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.
This is an interesting thought. I wonder how hard this would be to implement in practice. - DLD -- David Lowry-Duda <david@lowryduda.com> <davidlowryduda.com>
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 <david@lowryduda.com> wrote:
I see no reason why we should think about changing PEPs.
Please see first mail in the thread.
On 21Sep2020 12:28, David Lowry-Duda <david@lowryduda.com> wrote:
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 <cs@cskk.id.au>
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 11:01 AM Steven D'Aprano <steve@pearwood.info> wrote:
**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
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
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
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
2 ways for past PEPs and 1 way for future PEPs
On Mon, Sep 21, 2020 at 11:25:52AM +0400, Abdur-Rahmaan Janhangeer wrote:
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".
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?
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
Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius On Mon, Sep 21, 2020 at 11:46 AM Steven D'Aprano <steve@pearwood.info> wrote:
By future PEPs i mean future PEP naming, Not about PEP referencing
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
It depends on what you mean by know
By accepted it means the PEP made a significant change in the Python language.
On Mon, 21 Sep 2020 at 08:29, Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:
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
Kind Regards, Abdur-Rahmaan Janhangeer about | blog github Mauritius On Mon, Sep 21, 2020 at 12:20 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Mon, 21 Sep 2020 at 08:29, Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:
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.
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.
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 On Mon, Sep 21, 2020 at 9:23 PM Barry Scott <barry@barrys-emacs.org> 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.
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
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:55 PM Barry Scott <barry@barrys-emacs.org> wrote:
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.
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:00 PM Chris Angelico <rosuav@gmail.com> 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.
On Tue, Sep 22, 2020 at 4:13 AM Abdur-Rahmaan Janhangeer <arj.python@gmail.com> 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. 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
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 <rosuav@gmail.com> wrote:
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.
All law projects remain law projects. But we call law projects which has been accepted as law.
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.
On Tue, Sep 22, 2020 at 4:39 AM Abdur-Rahmaan Janhangeer <arj.python@gmail.com> 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?)
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?
On the web site, on Stack Overflow, on people's blogs, in published printed books, YouTube videos.... *everywhere*.
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
On Mon, Sep 21, 2020 at 10:47 PM Chris Angelico <rosuav@gmail.com> 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
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:
-- 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 Mon, 21 Sep 2020, 23:13 David Mertz, <mertz@gnosis.cx> 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
September 21, 2020 3:37 PM, "Abdur-Rahmaan Janhangeer" <arj.python@gmail.com (mailto:arj.python@gmail.com?to=%22Abdur-Rahmaan%20Janhangeer%22%20<arj.python@gmail.com>)> wrote: On Mon, 21 Sep 2020, 23:13 David Mertz, <mertz@gnosis.cx (mailto:mertz@gnosis.cx)> 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
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 <edwin@211mainstreet.net> wrote:
-- 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 Mon, 21 Sep 2020, 23:45 , <edwin@211mainstreet.net> 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 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
On Mon, 21 Sep 2020 at 21:07, Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:
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
On Mon, Sep 21, 2020 at 4:04 PM Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:
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
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.
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
On Tue, Sep 22, 2020 at 04:18:42AM +1000, Chris Angelico wrote:
This is very well said. And I'll add that much of this remains in close analogy to RFCs.
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 <david@lowryduda.com> <davidlowryduda.com>
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:52 PM David Lowry-Duda <david@lowryduda.com> wrote:
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.
On 22/09/20 6:13 am, Abdur-Rahmaan Janhangeer wrote:
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
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