[Python-Dev] Re: Making code object APIs unstable
13.08.21 20:24, Guido van Rossum пише: > If these weren't part of the stable ABI, I'd choose (E). But because > they are, I think only (A) or (B) are our options. The problem with (C) > is that if there's code that links to them but doesn't call them (except > in some corner case that the user can avoid), the code won't link even > though it would work fine. The problem with (D) is that if it *is* > called by code expecting the old signature it will segfault. I'm not > keen on (A) since it can cause broken code objects when used to copy a > code object with some modified metadata (e.g. a different filename), > since there's no way to pass the exception table (and several other > fields, but the exception table is an integral part of the code now). I agree that (A) and (B) are only options if we preserve binary compatibility. For practical reasons I prefer (B). We can make (A) working if add the exception table to the end of the bytecode array and the endline/column tables to the end of the lineno table. It would allow to re-construct the code object with some simple changes (like filename or replace some constants). Creating the code object from zero is version-specific in any case, because bytecode is changed in every version, and semantic of some fields can be changed too (e.g. support of negative offsets in the lineno table). But it would complicate the code object structure and the code that works with it in long term. ___ 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/B4OGG4EQUB4LPRLQRBZ2RBX4DVQJILST/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
Barry Warsaw wrote: > On Aug 4, 2021, at 07:31, Victor Stinner vstin...@python.org wrote: > > On Tue, Aug 3, 2021 at 7:54 PM Ethan Furman et...@stoneleaf.us wrote: > > I would rather keep `bchr` and lose the `.fromint()` methods. > > I would prefer to only have a bytes.byte(65) method, no bchr() > > built-in function. I would prefer to keep builtins namespace as small > > as possible. > > The Steering Council is also pretty adamantly against adding a new bchr() > > built-in. FYI the PEP still mentions `bchr`. -Brett > > bytes.byte() name is similar to bytes.getbyte(). I cannot find "int" > > in the name of other bytes methods. > > .byte() seems fine to me too. I’m not a fan of smushedwords but .fromint() > > seemed better than .fromord(). > -Barry ___ 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/5XGSSSTSDGG3QSEQSC2IUVNEAKWKLQXS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 558, the simplest thing I could come up with
Bringing the public record up to date with a brief off-list discussion between Mark, Nathaniel and I: * Mark hasn't convinced me that getting rid of the frame value cache entirely for optimised frames is a good idea, so he's going to write that proposal up as a competing PEP. Once it has been drafted and is ready for review, he will request the SC assign a PEP delegate. * On the PEP 558 front, Mark's proposal has highlighted a few inefficiencies in my reference implementation, where the code still implicitly updates the frame value cache in cases where the cache being up to date may not matter to the proxy API client. So I'll be working on another iteration of the implementation that ensures each caching proxy instance (at worst) only pays the O(N) cache refresh price on the first less than O(N) operation that relies on the cache being up to date, rather than paying it every time "f_locals" is retrieved from the frame object. We still have plenty of time before 3.11b1, so we expect it will be a month or two before the two proposals are in a position to be compared directly. Cheers, Nick. On Fri, 30 Jul 2021, 5:25 pm Nick Coghlan, wrote: > > > On Fri, 30 Jul 2021, 2:30 pm Nathaniel Smith, wrote: > >> >> > >> > 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? >> > > At the locals() level, PEP 558 is now [snapshot] (due to your original > analysis showing that it was strictly better than what I had at the time), > while Mark's draft is indeed [proxy]. > > Cheers, > Nick. > > > >> -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/EU2TU6R2HDV6NLZQ56MSDIRMG6EHSOJO/ Code of Conduct: http://python.org/psf/codeofconduct/
