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
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
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
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.
>
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
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
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
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
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
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
10 matches
Mail list logo