Repealing PEP 509 (Add a private version to dict)
Hi everyone, I would like to repeal PEP 509. We don't really have a process for repealing a PEP. Presumably I would just write another PEP. Before I do so, I would like to know if anyone thinks we should keep PEP 509. The dictionary version number is currently unused in CPython and just wastes memory. I am not claiming that we will never need it, just that we shouldn't be required to have it. It should be an internal implementation detail that we can add or remove depending on requirements. Thoughts? Cheers, Mark.
Maybe you should also mention that in 3.11 we’re introducing a new concept, dict *keys* version, which is more useful (for the specializing interpreter anyway). On Thu, Jul 29, 2021 at 12:47 Mark Shannon <mark@hotpy.org> wrote:
Hi everyone,
I would like to repeal PEP 509. We don't really have a process for repealing a PEP. Presumably I would just write another PEP.
Before I do so, I would like to know if anyone thinks we should keep PEP 509.
The dictionary version number is currently unused in CPython and just wastes memory. I am not claiming that we will never need it, just that we shouldn't be required to have it. It should be an internal implementation detail that we can add or remove depending on requirements.
Thoughts?
Cheers, Mark. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GV4CW3T7... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
+1 2021年7月29日(木) 19:46 Mark Shannon <mark@hotpy.org>:
Hi everyone,
I would like to repeal PEP 509. We don't really have a process for repealing a PEP. Presumably I would just write another PEP.
Before I do so, I would like to know if anyone thinks we should keep PEP 509.
The dictionary version number is currently unused in CPython and just wastes memory. I am not claiming that we will never need it, just that we shouldn't be required to have it. It should be an internal implementation detail that we can add or remove depending on requirements.
Thoughts?
Cheers, Mark. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GV4CW3T7... Code of Conduct: http://python.org/psf/codeofconduct/
On 7/29/2021 11:41 AM, Mark Shannon wrote:
The dictionary version number is currently unused in CPython and just wastes memory. I am not claiming that we will never need it, just that we shouldn't be required to have it. It should be an internal implementation detail that we can add or remove depending on requirements.
Sounds reasonable. Maybe we should have a "Type" other than Standards Track for PEPs that are documenting implementation designs, rather than requirements for standardisation? If/when we ever get to a point where other implementations want to claim to implement "standard" Python, having an explicit distinction here would be helpful. Cheers, Steve
Hi Steve, On 29/07/2021 1:55 pm, Steve Dower wrote:
On 7/29/2021 11:41 AM, Mark Shannon wrote:
The dictionary version number is currently unused in CPython and just wastes memory. I am not claiming that we will never need it, just that we shouldn't be required to have it. It should be an internal implementation detail that we can add or remove depending on requirements.
Sounds reasonable.
Maybe we should have a "Type" other than Standards Track for PEPs that are documenting implementation designs, rather than requirements for standardisation?
That makes sense to me. There a few PEPs that fall into that category, but not many. E.g. 393, 412, 509, 590, 659.
If/when we ever get to a point where other implementations want to claim to implement "standard" Python, having an explicit distinction here would be helpful.
Cheers, Steve
On 7/29/2021 6:17 PM, Barry Warsaw wrote:
On Jul 29, 2021, at 05:55, Steve Dower <steve.dower@python.org> wrote:
Maybe we should have a "Type" other than Standards Track for PEPs that are documenting implementation designs, rather than requirements for standardisation?
Wouldn’t Informational fill that need?
Perhaps, though my understanding was that Informational PEPs aren't tied to specific Python versions (in this case, a CPython release) and are meant to remain "Active" until completely redundant. Maybe if the PEPs got a preamble covering "this describes part of the implementation of CPython as first released in x.y... may have changed since that time... refer to source code" it would be clear enough. We might want to move them to "Final" after implementation though, unlike other Informational PEPs. Seems like there's _just enough_ nuance there to justify a different type. But then, presumably there's also infrastructure around PEP types as well that I'm unaware of (and not volunteering to update!), so those with the investment in it can have it however they'd like :) Cheers, Steve
On Thu, Jul 29, 2021 at 3:47 AM Mark Shannon <mark@hotpy.org> wrote:
Hi everyone,
I would like to repeal PEP 509. We don't really have a process for repealing a PEP. Presumably I would just write another PEP.
Yeah, it's probably a new PEP explaining why the first PEP turned out to not work out since it's undoing a "big" decision. Otherwise it's like withdrawing the PEP post-acceptance. -Brett
Before I do so, I would like to know if anyone thinks we should keep PEP 509.
The dictionary version number is currently unused in CPython and just wastes memory. I am not claiming that we will never need it, just that we shouldn't be required to have it. It should be an internal implementation detail that we can add or remove depending on requirements.
Thoughts?
Cheers, Mark. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GV4CW3T7... Code of Conduct: http://python.org/psf/codeofconduct/
On 7/29/21 1:32 PM, Brett Cannon wrote:
On Thu, Jul 29, 2021 at 3:47 AM Mark Shannon <mark@hotpy.org <mailto:mark@hotpy.org>> wrote:
Hi everyone,
I would like to repeal PEP 509. We don't really have a process for repealing a PEP. Presumably I would just write another PEP.
Yeah, it's probably a new PEP explaining why the first PEP turned out to not work out since it's undoing a "big" decision. Otherwise it's like withdrawing the PEP post-acceptance.
That would allow placing a simple tag in the original, like "Superseded by PEP XXX".
Hi, I wrote the PEP 509 as part of my abandonned "FAT Python" project which was a ahead-of-time optimizer using runtime guards to deoptimize code. I planed to abandon this PEP as well, but the dictionary version was used by LOAD_GLOBAL opcode cache which made the version useful and so the PEP was accepted in Python 3.6. As soon as LOAD_GLOBAL and LOAD_ATTR optimizations are not lost, I'm perfectly fine with removing the dictionary version. As it was said in other messages, there is now a per-key version which can be used instead, if I understand correctly. Victor On Thu, Jul 29, 2021 at 12:41 PM Mark Shannon <mark@hotpy.org> wrote:
Hi everyone,
I would like to repeal PEP 509. We don't really have a process for repealing a PEP. Presumably I would just write another PEP.
Before I do so, I would like to know if anyone thinks we should keep PEP 509.
The dictionary version number is currently unused in CPython and just wastes memory. I am not claiming that we will never need it, just that we shouldn't be required to have it. It should be an internal implementation detail that we can add or remove depending on requirements.
Thoughts?
Cheers, Mark. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GV4CW3T7... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
participants (8)
-
Barry Warsaw -
Brett Cannon -
Guido van Rossum -
Inada Naoki -
Mark Shannon -
Mats Wichmann -
Steve Dower -
Victor Stinner