What steps will reproduce the problem? 1. Create a non-empty dictionary 2. Create a second dictionary, inserting the first dictionary as an item 3. Insert an empty dictionary into the first

What is the expected output? What do you see instead? I would expect either 1) it to compile fine, or 2) Shedskin to fail and explain that dicts in dicts are unsupported. Instead, Shedskin outputs c++ code with no complaint, but g++ fails to compile it.

What version of the product are you using? On what operating system? Shedskin 3.1, G++ 4.4

Please provide any additional information below. I have attached the relevant code below.

Hello from Reddit! And I have to say, your compiler is quite cool!

thanks for reporting! this should work without any problem.. but unfortunately, it looks like shedskin forgets to add a cast here, so the C++ compiler doesn't like it. I will see if I can fix this in SVN. this is an ugly workaround in any case:

def emptydict(): return {} return {1:1}

d2[2] = emptydict()

to anyone who would like to help, it would be useful to find similar cases that fail, also for other types than dicts.

btw, note that the problem is not from using dicts in dicts (still a static type: dict(int -> dict(int, int))), but using an empty dict in a way such that shedskin forgets to add a cast.. ^^

Your comment gave me something to think about, so I tried with lists... and I found another set of code that fails: definiteinnerlist=[1] outerlist=[] emptyinnerlist=[] outerlist.append(definiteinnerlist) outerlist.append(emptyinnerlist)

The compiler seems to not to find the right cast for a collection, if the only indication of that collection's type is that it is added to another collection alongside other members with more definite types.

Another bypassing solution:

d={1:1} del d[1]

or fancier, but one line: d={} and {1:1}

The empty dict (or list) is False, so the 'and' is short-circuited and the empty-list is returned, and d is set to the empty list.

thanks! I will add both tests to the test set, and try to fix the underlying problem one of these days. I have to rest a bit first after releasing 0.3.. :-)

alright, these code fragments now work in SVN. fortunately, the problem was easier to solve than I expected. I will close the issue after generalizing the solution a bit. thanks again for reporting!

I consider this fixed for now. there are a few wacky cases left, but we'll deal with them when they turn up.