Update freeze to operate on pyrsistent data structures

[phil-arh]

Fixes issue #81 in theory. In practice we might want to also update thaw:

# currently
thaw({'a': m(b=1)})
# returns {'a': m(b=1))}

# improved thaw
thaw({'a': m(b=1)})
# would return {'a': {'b': 1}}

If you think that makes sense I should prob make that change in this PR so we can add all the new functionality at once.

One other thing - I'm not a fan of the name nonstrict that I chose for the flag to make freeze ignore pmaps and pvectors. If you've got a better suggestion I'm very happy to change it.

[tobgu]

Thanks! Will have a look in the coming days. The failing tests for 3.5 are not related to this PR. Hopefully fixed on master now (by dropping them ahead of 3.5 EOL).

[tobgu]

Yeah, I agree, making the thaw function symetrical to freeze is probably a good thing!

[tobgu]

How about calling it strict instead with a default value of True? Would get rid of some of the double negation below.

[tobgu]

If you want to these functions could probably be modernised a bit while you're at it. They were initially written with Python 2.6 compatibility in mind, hence the use of dict() for example. Also the map calls could perhaps be replaced with list comprehensions to allow skipping the lambdas as well. Not sure if a iterator expression (without square brackets) or list comprehension is best from a perf standpoint. If you want to you could do some quick measurements.

If you don't feel like doing the above that's fine too. I can fix it at a later stage.

[phil-arh]

Happy to do that. I'll have another look at it at some point this week and update thaw as well. I had some reasoning for using nonstrict instead of strict but tbh it is prob better just to use strict=False as the flag :)

[tobgu]

You probably need to rebase this on latest master since there were some issues with the Python 3.5 builds.

[tobgu]

Hi! Did you lose steam on this one? :-)

[phil-arh]

My bad, been very busy over the last month or so. Will have a look at it this afternoon!

[tobgu]

No worries, take your time! Basically just wanted to check if you were still interested in it.

[phil-arh]

Just a quick aside about some basic performance testing I've been doing (very basic, and only on my machine, so take this with a pinch of salt). I've been comparing list comprehensions, generator expressions, and map for mapping over a collection.

It seems that generator expressions are just pretty slow whatever you do and are only worth using for low performance applications due to the nice syntax they offer. List comprehensions are much faster and are preferable from a speed perspective (unless you're doing something memory-bound as they use much more memory).

The choice of which is fastest between a list comprehension and a map call depends on whether a function call must be made for each iteration. If the transformation logic can be inlined into the list comprehension, it's a lot faster to use that; if a function call is necessary regardless, it seems that using map is faster - interestingly, this seems to be true even if the expected output is a list rather than some other collection type.

Like I said, this is hardly science, but felt worth mentioning to justify my use of map throughout.

[phil-arh]

Might be worth having a look now :)

[tobgu]

This was not meant to be checked in, right?

[tobgu]

Thanks! Will have a deeper look in the coming days. There was a file, "output", that should not be in there I think.

[tobgu]

Great, thanks!