[Python-Dev] Re: PEP 558, the simplest thing I could come up with
On Thu, Jul 29, 2021 at 4:52 PM Nick Coghlan wrote: > > On Fri, 30 Jul 2021, 6:05 am Mark Shannon, wrote: >> >> Hi Nick, >> >> Our discussion on PEP 558 got me thinking >> "What is the simplest thing that would work?". >> >> This is what I came up (in the form of a draft PEP): >> https://github.com/markshannon/peps/blob/pep-locals/pep-06xx.rst >> >> It doesn't have O(1) len(f_locals), and it does break >> `PyEval_GetLocals()` but I think the that is a small price to pay for >> simplicity and consistency. > > > I don't think it is OK to break PyEval_GetLocals() when we really don't need > to, > and the proposal also discards all the feedback that I received on earlier > iterations of PEP 558. (I particularly recommend reading Nathaniel's analysis > of why returning the proxy from locals() would be more likely to cause bugs > in existing code than it would be to eliminate any). Heh, I was actually just re-reading PEP 558 and going to ask you to include more details to justify the complexity, as compared to something like Mark's latest proposal here -- I'd totally forgotten I wrote that old post :-). So that was a timely reminder! Looking at the references in the PEP, is this the writeup you're talking about? https://mail.python.org/pipermail/python-dev/2019-May/157738.html The conclusion there is: > I'm leaning towards saying that on net, [snapshot] beats [PEP-minus-tracing]: > it's dramatically simpler, and the backwards incompatibilities that we've > found so far seem pretty minor, on par with what we do in every point release. (In fact, in 3/4 of the cases I looked at, [snapshot] is actually what users seemed to trying to use in the first place.) > > For [proxy] versus [snapshot], a lot depends on what we think of changing the > semantics of exec(). [proxy] is definitely more consistent and elegant, and > if we could go back in time I think it's what we'd have done from the start. Its compatibility is maybe a bit worse than [snapshot] on non-exec() cases, but this seems pretty minor overall (it often doesn't matter, and if it does just write dict(locals()) instead of locals(), like you would in non-function scope). But the change in exec() semantics is an actual language change, even though it may not affect much real code, so that's what stands out for me. I *think* (please correct me if I'm wrong) that what that calls [PEP-minus-tracing] is now corresponds to the current PEP draft, and [proxy] corresponds to Mark's draft at the beginning of this thread? -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/TB6FZXVO3LQFFVCKAN7OTAJ427HY67TF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 558, the simplest thing I could come up with
On Fri, 30 Jul 2021, 6:05 am Mark Shannon, wrote: > Hi Nick, > > Our discussion on PEP 558 got me thinking > "What is the simplest thing that would work?". > > This is what I came up (in the form of a draft PEP): > https://github.com/markshannon/peps/blob/pep-locals/pep-06xx.rst > > It doesn't have O(1) len(f_locals), and it does break > `PyEval_GetLocals()` but I think the that is a small price to pay for > simplicity and consistency. > I don't think it is OK to break PyEval_GetLocals() when we really don't need to, and the proposal also discards all the feedback that I received on earlier iterations of PEP 558. (I particularly recommend reading Nathaniel's analysis of why returning the proxy from locals() would be more likely to cause bugs in existing code than it would be to eliminate any). As it looks like we have some fairly fundamental disagreements regarding the level of behaviour change and API breakage that is acceptable for the sake of a simpler implementation, I think we're going to need competing PEPs for the SC to evaluate (or delegate to Nathaniel for evaluation) if you want to pursue that path further. (I'm only OK with explicitly breaking PyEval_LocalsToFast because the write-back strategy is already intrinsically broken. By contrast, maintaining a frame cache for optimised frames isn't fundamentally flawed, it's just a matter of figuring out when and how to pay the cost of updating it to avoid wasting those CPU cycles in code that doesn't care if the cache is up to date or not) Cheers, Nick. > > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/57BOZNO3GCVUDJ6FPF2OCKMTHE4U36Q2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Fri, 30 Jul 2021, 8:47 am Barry Warsaw, wrote: > > Hello Nick, Ethan, > > The Python Steering Council reviewed PEP 467 -- Minor API improvements for > binary sequences at our 2021-07-26 meeting. > > Thank you for work on this PEP. We’re generally very favorable for adding > to Python 3.11 the features and APIs described in the PEP. Thank you! > > Let us know what you think about making these changes. We aren’t making > acceptance contingent on these changes, but we do think they make the PEP > and the new APIs better. > Those changes all sound reasonable to me, so if Ethan is also amenable, I think we should incorporate them. Cheers, Nick. > -Barry (on behalf of the Python Steering Council) > > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/5DW4PRS3W4Q5KLARYKS3Y2QP2RNFZSFA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 467 feedback from the Steering Council
Hello Nick, Ethan, The Python Steering Council reviewed PEP 467 -- Minor API improvements for binary sequences at our 2021-07-26 meeting. Thank you for work on this PEP. We’re generally very favorable for adding to Python 3.11 the features and APIs described in the PEP. We have some requests for changes that we’d like you to consider. * The Python-Version in the PEP needs to target Python 3.11 of course. * We think it would be better if bytes.fromsize()’s second argument was a keyword-enabled or keyword-only argument. We understand the rationale given in the PEP for not doing so, but ultimately we think the readability of (at least allowing) a keyword argument to be more compelling. Some possible options include `fill`, `value`, or `byte`. * We all really dislike the word “ord” as in `bytes.fromord()`. We understand the symmetry of this choice, but we also feel like we have an opportunity to make it more understandable, so we recommend `bytes.fromint()` and `bytearray.fromint()`. * We think the `bchr()` built-in is not necessary. Given the `.fromint()` methods, it’s better not to duplicate the functionality, and everything has a cost. A built-in that exists only for the symmetry described in the PEP is just a little extra complexity for little value. Let us know what you think about making these changes. We aren’t making acceptance contingent on these changes, but we do think they make the PEP and the new APIs better. -Barry (on behalf of the Python Steering Council) signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/PJQPR2CGMKTBADB66GCFHYASYHZGQRT2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 558, the simplest thing I could come up with
Hi Nick, Our discussion on PEP 558 got me thinking "What is the simplest thing that would work?". This is what I came up (in the form of a draft PEP): https://github.com/markshannon/peps/blob/pep-locals/pep-06xx.rst It doesn't have O(1) len(f_locals), and it does break `PyEval_GetLocals()` but I think the that is a small price to pay for simplicity and consistency. What do you think? Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/FCWMWQ7TCSHE7LIXRMMR3Z37LJKIOO5J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)
On Thu, Jul 29, 2021 at 3:47 AM Mark Shannon 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-le...@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/GV4CW3T7SUTJOYSCP6IJMV4AHDNNZIPV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/FLPV7EETKZ5F5AQCS3EDVVIKFJEB7V7A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)
On 7/29/2021 6:17 PM, Barry Warsaw wrote: On Jul 29, 2021, at 05:55, Steve Dower 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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/F2WEKHD77EAWFTCW7PWDEESSZMBL64BI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] possibly incorrect docs re: constant initialization
The documentation for PyTypeObject.tp_base
(https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_base) says the
following:
> Note: Slot initialization is subject to the rules of initializing
> globals. C99 requires the initializers to be “address constants”.
> Function designators like PyType_GenericNew(), with implicit
> conversion to a pointer, are valid C99 address constants.
>
> However, the unary ‘&’ operator applied to a non-static variable
> like PyBaseObject_Type() is not required to produce an address
> constant. Compilers may support this (gcc does), MSVC does not. Both
> compilers are strictly standard conforming in this particular
> behavior.
I think this may be incorrect. Specifically, it seems to be confusing "static
variable" with "static storage duration."
It is true that C99 requires address constants to have static storage duration.
The relevant text in C99 is 6.6p9:
> An address constant is a null pointer, a pointer to an lvalue
> designating an object of static storage duration, or a pointer to a
> function designator; it shall be created explicitly using the unary
> & operator or an integer constant cast to pointer type, or
> implicitly by the use of an expression of array or function type.
Note that the language here is "static storage duration", not "static
variable". The standard doesn't define the term "static variable", but in
common usage it means any variable that includes the static storage-class
specifier. Under this definition, PyBaseObject_Type is indeed not a static
variable:
// These are commonly referred to as "static variables" because they
// use the "static" keyword:
static int x;
void f() { static int y; }
// Not a static variable.
extern PyTypeObject PyBaseObject_Type
However "static storage duration" is a broader concept that describes the
lifetime of an object. An object can have static storage duration even if it
does not use the "static" keyword. From 6.2.4p3:
> An object whose identifier is declared with external or internal
> linkage, or with the storage-class specifier static has static
> storage duration. Its lifetime is the entire execution of the
> program and its stored value is initialized only once, prior to
> program startup.
Under this definition, PyBaseObject_Type does indeed have static storage
duration, because it has external linkage. So I believe that _Type
should be a valid address constant according to C99.
Indeed, MSVC accepts an address of an extern as an address constant in the
simple case: https://godbolt.org/z/8Tdc999z3
It is only when the extern is imported from another DLL that MSVC rejects it:
https://godbolt.org/z/fMM1fr743
I believe that MSVC may be out of conformance in rejecting the latter case. If
this is true, it wouldn't necessarily change the guidance in the docs (tp_base
should still be initialized dynamically if the base could possibly come from a
DLL on Windows). However it may make sense to change the language about both
compilers being "strictly standard conforming."
It also may be worth mentioning that this issue appears to be specific to DLLs;
if the base class will never come from another DLL, this workaround may be
unnecessary.
One other minor nit; there is a small typographical error in the docs I quoted
above:
> However, the unary ‘&’ operator applied to a non-static variable
> like PyBaseObject_Type() is not required to produce an address
PyBaseObject_Type is not a function, so it shouldn't have the trailing '()'.
Thanks,
Josh
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/2WUFTVQA7SLEDEDYSRJ75XFIR3EUTKKO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)
On Jul 29, 2021, at 05:55, Steve Dower 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? -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/UVAQOVDRIFFWDWAUHLVSQ5KMRNAOBJ2O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)
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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/3UZZCTFF2PPLS4FCZSRHUDSD6F3YBTVJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)
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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/W7TRTCE3PLLKHPWKFYMRZN4KHFK65RWD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)
+1 2021年7月29日(木) 19:46 Mark Shannon : > 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-le...@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/GV4CW3T7SUTJOYSCP6IJMV4AHDNNZIPV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/5DH7TBYAFN3CPCYPGZU73VBM57YDZPXL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)
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 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-le...@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/GV4CW3T7SUTJOYSCP6IJMV4AHDNNZIPV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/PFQTFODZDVX6AQYZ4OZJKK6CMX2OXQAA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] 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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/GV4CW3T7SUTJOYSCP6IJMV4AHDNNZIPV/ Code of Conduct: http://python.org/psf/codeofconduct/
