OK my bad. Adding a print('fr[0]', fr[0].shape) in test() fixes the issue. Argh. I was trying to isolate a real issue I'm seeing along these lines. My real issue is the same, i.e. impossible to resize a member of a tuple after it's been created.
I'm finding that the problem goes away if I use --config pythran.optimizations=pythran.optimizations.ListToTuple
Can someone explain why that would be the case? Does pythran.optimizations=pythran.optimizations.ListToTuple indicate that that's the only optimization being run?

Question:
why is:

pythran -lblas TD.py --config 'pythran.optimizations=pythran.optimizations.ConstantFolding pythran.optimizations.PartialConstantFolding pythran.optimizations.DeadCodeElimination pythran.optimizations.IterTransformation pythran.optimizations.ComprehensionPatterns pythran.optimizations.ListCompToGenexp pythran.optimizations.LoopFullUnrolling pythran.optimizations.ModIndex pythran.optimizations.PatternTransform pythran.optimizations.RangeLoopUnfolding pythran.optimizations.RangeBasedSimplify pythran.optimizations.Square pythran.optimizations.Inlining pythran.optimizations.InlineBuiltins pythran.optimizations.ListToTuple pythran.optimizations.TupleToShape pythran.optimizations.RemoveDeadFunctions pythran.optimizations.ForwardSubstitution pythran.optimizations.ListToTuple'

different than

pythran -lblas TD.py

The former lists all the optimizations available (from the init.py file in the optimizations directory). So I would imagine all of these are on by default, but I get different results in both cases. The former works, the latter does not.

The list of optimization used is defined in pythran/pythran.cfg. order matters!

Does pythran.optimizations=pythran.optimizations.ListToTuple indicate that that's the only optimization being run?

yes

As a side note: the code above is not valid Python:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in test
  File "<stdin>", line 3, in B
TypeError: 'tuple' object does not support item assignment

Yes, of course, I'm aware of that! I'm bending the rules because pythran allows me to do it (and it's really the only way I can create and use a tuple from the C++ created by pythran!).

Cool. I'm going to check it this pm

Well, it's still not working for me:
This is the typical situation: These values are declared in my init function.

        flux                =    np.zeros(0)
        #flux                =    np.zeros(int(0*bogus) # < - this makes it work.
       

Later in my code, during run time, I get this assertion:

Assertion failed: (N == v && "consistent init"), function check_type, file /Users/jlaroche/pyent.py3.Darwin.x86_64/lib/python3.7/site-packages/pythran-0.9.6-py3.7.egg/pythran/pythonic/include/types/tuple.hpp, line 157.

The code, again, is too complex to post here. But maybe that will give you an idea for what's going on?

@jeanlaroche can you double check if this is fixed or not in the latest release?

@serge-sans-paille Nope. I get exactly the same assert with the latest release. I might be able to make a pruned-down example if that's useful.

I'm going to close this, and open a new bug that has a smaller example.