Re: [Python-Dev] MAKE_FUNCTION simplification

2016-04-14 Thread Ethan Furman
On 04/14/2016 10:02 AM, Random832 wrote: "between versions" is ambiguous. It could mean that there's no guarantee that there will be no changes from one version to the next, or it could mean, even more strongly, that there's no guarantee that there will be no changes in a maintenance release

Re: [Python-Dev] MAKE_FUNCTION simplification

2016-04-14 Thread Random832
On Thu, Apr 14, 2016, at 12:56, Terry Reedy wrote: > https://docs.python.org/3/library/dis.html#module-dis > CPython implementation detail: Bytecode is an implementation detail of > the CPython interpreter. No guarantees are made that bytecode will not > be added, removed, or changed between

Re: [Python-Dev] MAKE_FUNCTION simplification

2016-04-14 Thread Terry Reedy
On 4/14/2016 12:03 PM, Nikita Nemkin wrote: I think that Python should make bytecode explicitly unstable and subject to change with any major release. https://docs.python.org/3/library/dis.html#module-dis CPython implementation detail: Bytecode is an implementation detail of the CPython

Re: [Python-Dev] MAKE_FUNCTION simplification

2016-04-14 Thread Brett Cannon
On Thu, 14 Apr 2016 at 09:16 Nikita Nemkin wrote: > On Thu, Apr 14, 2016 at 8:32 PM, Victor Stinner > wrote: > > > > Would you like to work on a patch to implement that change? > > I'll work on a patch. Should I post it to bugs.python.org? > Yep. >

Re: [Python-Dev] MAKE_FUNCTION simplification

2016-04-14 Thread Nikita Nemkin
On Thu, Apr 14, 2016 at 8:27 PM, Guido van Rossum wrote: > Great analysis! What might stand in the way of adoption is concern for > bytecode manipulation libraries that would have to be changed. What > might encourage adoption would be a benchmark showing this saves a lot > of

Re: [Python-Dev] MAKE_FUNCTION simplification

2016-04-14 Thread Nikita Nemkin
On Thu, Apr 14, 2016 at 8:32 PM, Victor Stinner wrote: > > Would you like to work on a patch to implement that change? I'll work on a patch. Should I post it to bugs.python.org? > Since Python 3.6 may get a new bytecode format (wordcode, see the > other thread on this

Re: [Python-Dev] MAKE_FUNCTION simplification

2016-04-14 Thread Victor Stinner
2016-04-14 17:27 GMT+02:00 Guido van Rossum : > Great analysis! What might stand in the way of adoption is concern for > bytecode manipulation libraries that would have to be changed. > (...) > There's also talk of switching to wordcode, in a different thread. I agree that

Re: [Python-Dev] MAKE_FUNCTION simplification

2016-04-14 Thread Victor Stinner
2016-04-14 11:04 GMT+02:00 Nikita Nemkin : > MAKE_FUNCTION opcode is complex due to the way it receives > input arguments: (...) Yeah, I was always disturbed how this opcode gets parameters. > My suggestion is to pre-package 1-4 before calling MAKE_FUNCTION, > i.e. explicitly

Re: [Python-Dev] MAKE_FUNCTION simplification

2016-04-14 Thread Guido van Rossum
Great analysis! What might stand in the way of adoption is concern for bytecode manipulation libraries that would have to be changed. What might encourage adoption would be a benchmark showing this saves a lot of time. Personally I'm expecting it won't make much of a difference for real programs

[Python-Dev] MAKE_FUNCTION simplification

2016-04-14 Thread Nikita Nemkin
MAKE_FUNCTION opcode is complex due to the way it receives input arguments: 1) default args, individually; 2) default kwonly args, individual name-value pairs; 3) a tuple of parameter names (single constant); 4) annotation values, individually; 5) code object; 6) qualname. The counts for