[issue25843] lambdas on the same line may incorrectly share code objects

[Mark Dickinson]

Changes by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

Let me try to explain this issue again.

"f1, f2 = lambda: 1, lambda: 1.0" is compiled to two MAKE_FUNCTION 
instructions, MAKE_FUNCTION takes a code object as parameter (and a name). The 
Python compiler merges constants which are seen as "equal", with exceptions to 
not merge values of different types, or float of different sign.

Merging duplicate code objects is a cool micro optimization, I prefer to keep 
it. My patch keeps this micro optimization, but fix the bug: it ensures that 
equal constants having different types are not seen as equal. For example, 0 is 
equal to 0.0, but if when used for code constants, the code objects are seen a 
different.

Patch version 3:

* as suggested by Armin Rigo & Serhiy Storchaka: use id(obj) in the constant 
key for unknown constant types -- in practice, this patch is never taken, it's 
just to be extra safe (I checked manually by running the whole test suite when 
an assertion, assertion not in the posted patch)
* add a lot of unit tests
* add a documentation to _PyCode_ConstantKey()

@Serhiy: does it look good to you now?

> Would option (1) work if wrap 1 and 1.0 in a tuple? In a list? In a custom 
> collection?

My patch now uses id(obj) in the "constant key" for unknown types. The compiler 
only emits simple type (int, str, ...), tuple, frozenset and code objects.

You *can* other types if you patch manually constants with custom objects, 
since code_richcomp() now uses the "constant key" function to compare 
constants. For example, my fat project has a replace_consts() function to 
inject builtin functions in constants:
http://fatoptimizer.readthedocs.org/en/latest/fat.html#replace_consts

There is also @asconstants decorator of codetransformer which allow to inject 
arbitrary types in function constants:
https://pypi.python.org/pypi/codetransformer

--
Added file: http://bugs.python.org/file41671/code_richcompare-3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

FYI this issue is linked to the issue #26146 which allows to emit constants 
from an AST optimizer (see also the PEP 511).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Mark Lawrence]

Mark Lawrence added the comment:

http://code.activestate.com/recipes/578353-code-to-source-and-back/ compares 
code objects as part of round trip testing.

--
nosy: +BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Emanuel Barry]

Emanuel Barry added the comment:

I see. Is there any to special-case those so that only closures use that? Maybe 
by checking on the function object itself - the function itself would be quite 
similar, as well.

@Mark - I think you've misunderstood me (others did too, so I'm going to assume 
I just explained poorly) - I'm not debating the use of comparing code objects, 
I'm talking about the implicit replacement of code objects in functions. 
However, it seems to be of use, so outright removing the behaviour isn't an 
option.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

[Emanuel Barry]
> In which circumstances does comparing two code objects
> (at function creation time, what's more) make any sense?

It makes closures efficient:

>>> def f(x):
def g(y):
return x + y
return g

>>> h = f(1)
>>> i = f(2)
>>> h.__code__ is i.__code__
True

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> It makes closures efficient:

No, code objects are not compared here. The code object is constant, and f() 
returns different closure objects using the same code object.

AFAIK the comparison of different code objects is used exclusively in testing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[R. David Murray]

R. David Murray added the comment:

Ah, haypo explained the code to me, and now I understand your comment Serhiy.

So, the replacement happens because of (a) an optimizer general rule and (b) 
the fact that code object *can* be compared.

So it sounds like Armin's suggestion of making an exception for code objects in 
the optimizer is the correct solution.

The issue with code objects that aren't really equal comparing equal would then 
be a separate bug that affects, as Serhiy said, only testing (that we know 
of...who knows what people like PJE might be doing with comparing code objects 
:)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Indeed. My answer actually is an answer to implicit question: could we make 
different code objects be always non-equal? Answer: no, because we use the 
comparison of different code objects to test compiler and marshaller.

May be we can get rid of code objects comparability and provide separate 
function specially for testing. Of course this likely will break tests in 
third-party packages that do low-level hacking on code objects.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

compiler_add_o() uses an heuristic to compare and merge duplicated constants. 
It has special cases for float and complex numbers, but it's not designed to 
handle more types.

Funny, I had the same isue last week why I added support for tuple and 
frozenset "constants" in AST. I had to explicitly support these types in 
compiler_add_o().

I see two options:

(1) share code between compiler_add_o() and code_richcompare() to ensure that 1 
and 1.0 constants are not seen as equal
(2) modify compiler_add_o() to never merge code objects, always considere them 
as unequal

For (2), there is a minor technical issue: you have to generate an unique key 
for the dictionary.

I prefer option (1) for consistency.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

code_richcompare.patch: fix code_richcompare() to not consider that constants 
(1,) and (1.0,) are equal.

The patch lacks an unit test.

We may use the new _PyCode_ConstantKey() function to compare other code 
attributes?

--
keywords: +patch
Added file: http://bugs.python.org/file41307/code_richcompare.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

> Would option (1) work if wrap 1 and 1.0 in a tuple? In a list? In a custom 
> collection?

Right now, the Python compiler is quite limited. It only produces constants for 
integers and strings, not complex types. The peephole optimizers is responsible 
to produce tuple and frozenset constants, and the optimizer is more naive. It 
doesn't try to merge constants, nor remove items from co_consts to only keep 
the new container. Example:

>>> def f():
...  return (1,2,3)
... 
>>> f.__code__.co_consts
(None, 1, 2, 3, (1, 2, 3))

1, 2, 3 constants are kept, whereas only (1, 2, 3) constant is used.

Test with my patch:

>>> f1, f2 = lambda x: x in {1,}, lambda x: x in {1.0,}
>>> 
>>> f1.__code__ is f2.__code__
False
>>> f1.__code__.co_consts
(None, 1, frozenset({1}))
>>> f2.__code__.co_consts
(None, 1.0, frozenset({1.0}))

The frozenset are different are expected.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

> The frozenset are different are expected.

Oh wait, in this example, it works, but not because of the expected reason. 
frozenset({1}) is equal to frozenset({1.0}) and code_richcompare() doesn't 
create a special key to make them different.

The example only works because the peephole optimizer is lazy and leave 1 and 
1.0 in co_consts which are seen as different by the patched code_richcompare().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

code_eq.py: code to test that frozenset() are inequal. The code hacks 
constants, don't run the code with new constants or it will crash!

--
Added file: http://bugs.python.org/file41309/code_eq.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[R. David Murray]

R. David Murray added the comment:

Serhiy: that can't be entirely true, since we have here a bug where two lambdas 
on the same line are getting the same code object incorrectly, and that is not 
a testing context.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Would option (1) work if wrap 1 and 1.0 in a tuple? In a list? In a custom 
collection?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

code_richcompare-2.patch: Updated patch to handle also frozenset, the other 
constant type generated by the peephole optimizer.

--
Added file: http://bugs.python.org/file41308/code_richcompare-2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

If go this way, I would add explicit support of all types supported in marshal, 
and include id(obj) into the key of all other types.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> The lowest impact fix from a code change would be to add a type equivalence 
> check for constants as Raymond first suggested, as that only involves adding 
> an extra check to code_richcompare: 
> https://hg.python.org/cpython/file/tip/Objects/codeobject.c#l416

It is not so easy. (1,) and (1.0,) are equal and have the same type. To make 
correct type-sensitive equivalence check, you need to introduce new protocol, 
new special method on low level and new operator/function on high level.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> I think we should focus on fixing the spec for code object equivalents.  
> Perhaps the test can be simplified to use (co_firstlineno, co_firstrowno, 
> co_filename).

This is not enough if the code was compiled from a string.

>>> x = eval('lambda: 1')
>>> y = eval('lambda: 1.0')
>>> x.__code__ == y.__code__
True
>>> x.__code__.co_filename == y.__code__.co_filename
True

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[David MacIver]

David MacIver added the comment:

Note that 3.x does not correctly handle -0.0, you just have to work a bit 
harder:

>>> (lambda: (-0.0, 0.0), lambda: (0.0, -0.0))[1]()
(-0.0, 0.0)

--
nosy: +David MacIver

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Emanuel Barry]

Emanuel Barry added the comment:

Nobody seems to have asked this, so I'll be that guy. In which circumstances 
does comparing two code objects (at function creation time, what's more) make 
any sense? I mean, I'm fine with being able to compare two code objects, but I 
don't think that's something that should be automated.

Is there any particular reason why this is so? The only reason I could think of 
was that small, identical functions could use the same code object -- but then 
Raymond proved that different files will not share the code object, and 
identical functions on different lines will not, either.

As functions grow in size and complexity, having two virtually identical 
functions is probably bad design to begin with. So, seeing as this causes more 
harm than good (and I doubt it's of any use nowadays - it might have been back 
then, I don't know), I suggest we simply drop the implcit code objects 
compare-and-replace that's happening here.

--
nosy: +ebarry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Armin Rigo]

Armin Rigo added the comment:

That's what I suggested ("compile.c:compiler_addop(): special-case code objects 
too, and stick their identity in the tuple 't'.") and how I fixed the same bug 
in PyPy (https://bitbucket.org/pypy/pypy/commits/7ec3e1d02197).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I suppose this is needed above all for testing. test_compile, test_codeop, 
test_marshal, and few other tests compare code objects.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Emanuel Barry]

Emanuel Barry added the comment:

I'm not suggesting to get rid of the rich compare ability of code objects, 
which makes sense to me. What doesn't make sense to me, however, is when a 
function's code object is replaced by another one because it compares equal. I 
see no use case for this, and only leads to head-scratching.

I believe code objects should not be touched at all.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Armin Rigo]

Armin Rigo added the comment:

Other possible minimal fixes:

* compile.c:compiler_addop(): special-case code objects too, and stick their 
identity in the tuple 't'.

* or, in compile.c:makecode(), append the first row number to co_consts.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, the bug is present in PyPy as well.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Nick Coghlan]

Nick Coghlan added the comment:

>From what I can see:

* checking constant types in addition to their values should be a two line 
change (plus tests)
* checking the column number in addition to the line number would be a more 
comprehensive fix, but also a constructor API change (since PyCode_New doesn't 
currently accept a column parameter)

The "values of the same constant type that are distinct but equivalent may 
still compare equal" case is obscure enough that I think the lower impact 
change is likely a better option, especially as 3.x currently "handles" the 
"lambda: -0.0" case by having both the unfolded 0.0 and the folded -0.0 in the 
constant list.


Additional detail for those interested:

The lowest impact fix from a code change would be to add a type equivalence 
check for constants as Raymond first suggested, as that only involves adding an 
extra check to code_richcompare: 
https://hg.python.org/cpython/file/tip/Objects/codeobject.c#l416

However, the idea of tracking "co_firstcolno" in addition to "co_firstlineno" 
is a more robust fix, as it means any lexically distinct code objects will 
necessarily be considered distinct by the interpreter. The downside is that it 
means touching more code and adding a new public API, since PyCode_New doesn't 
currently accept a "firstcolno" parameter - code objects are implicitly assumed 
to be one-per-line.

Out of curiosity, I also went looking for the code in the code generator that 
collapses the "equivalent" code objects together. The issue is that constants 
are stored in a dict (mapping them to their co_consts index) during compilation 
and assembly, so equivalent objects will be merged together (and refer to the 
index of the first one defined).

--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Ismail Donmez]

Changes by Ismail Donmez :


--
nosy: +donmez

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

Interestingly, co_filename is not used as part of the equivalence criteria, so 
code object equivalence can be fooled across multiple input files.  Fortunately 
in this case, the false equivalence isn't relied on by the code generator.

  $ cat a.py
  def f():
  return 1

  $ cat b.py
  def f():
  return 1.0

  $ ./python.exe -q
  >>> import a, b
  >>> a.f.__code__ == b.f.__code__  # False equivalence
  True
  >>> a.f()
  1
  >>> b.f() # Generated code is correct
  1.0

Besides aliasing int/float/decimal/fraction/complex/bool, codeobj.__eq__() can 
also alias str/unicode on Python 2.7.  Likewise, 0.0 and -0.0 can be conflated. 
 NaNs don't seem to be a problem.

I think we should focus on fixing the spec for code object equivalents.  
Perhaps the test can be simplified to use (co_firstlineno, co_firstrowno, 
co_filename).

--
nosy: +arigo, fijall

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Torsten Landschoff]

Changes by Torsten Landschoff :


--
nosy: +torsten

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

The equality of code objects is determined by the code_richcompare() logic in 
Objects/codeobject.c.

Two code objects are equal if all of their attributes compare equal.  That 
includes co_name, co_argcount, co_kwonlyargcount, co_nlocals, co_flags, 
co_firstlineno, co_code, co_consts, co_names, co_varnames, co_freevars, and 
co_cellvars.

At the heart of David Murray's minimal example, the reason the two distinct 
code objects compare equal is that their co_consts compare as equal.

If you wanted to fix this, code objects would need to recursively check for 
both normal equality and type equality.

>>> f1 = lambda: 1
>>> f2 = lambda: 1.0
>>> f1.__code__.co_consts == f2.__code__.co_consts
True
>>> map(type, f1.__code__.co_consts) == map(type, f2.__code__.co_consts)
False

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

Here's another variant (courtesy of Nick Coghlan):

python3.5 -c "seq1 = [1.0 for x in range(5)]; seq2 = [True for x in range(5)]; 
print(seq1); print(seq2)"

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Kevin Shweh]

Kevin Shweh added the comment:

A type-based check runs into problems with 0.0 vs -0.0. For example, on Python 
2.7.11:

>>> x, y = lambda: 0.0, lambda: -0.0
>>> y()
0.0

I wasn't able to reproduce the -0.0 problem with Python 3.4 on Ideone; 
y.__code__.co_consts seems to have an unused 0.0 in it on 3.4. I don't have 
access to Python 3.5, so I don't know what the situation is like on that 
version.

--
nosy: +Kevin Shweh

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

One possible solution for all these variants is to let code objects track both 
the co.firstlineno and co.firstrowno.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25843] lambdas on the same line may incorrectly share code objects

[R. David Murray]

R. David Murray added the comment:

Thanks for posting the bug.  I added the aside because this is the third or 
fourth of these reference-only things I've seen in the past couple weeks and I 
finally figured out what bothered me about them.  We should put something about 
this in the devguide on bug reporting, but of course most people reporting bugs 
will for good reason not read that.  So, I just have to live with it :)

And yes, the reproducer reproduces the problem in all python versions currently 
under maintenance.

I've now changed the title to reflect the underlying bug.

--
title: unexpected output using pythons ternary operator in combination with 
lambda -> lambdas on the same line may incorrectly share code objects

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com