Python 3 support

[anlutro]

Hey,

I'm interested in integrating reclass into an existing Python3 library, but there are some incompatibilities. Most of them seem rather easy to fix, like changing print to a function call (with from __future__ imports), using a leading dot for relative imports, and except Exception as e.

Is this something you've considered doing? Would you like a pull request for it?

[Rtzq0]

I think mixed 2 and 3 builds is definitely on the long-term-unofficial wishlist. I promise that if you submit a PR it will get reviewed in a timely fashion!

[anlutro]

PR coming. There's one place where a non-trivial change has to be made - Parameters.interpolate uses .iteritems().next() and some weirdness where it removes items from the dictionary while iterating.

I replaced it with this and no tests failed but might have unintentional side effects.

for path, refvalue in self._occurrences.copy().items():
    self._interpolate_inner(path, refvalue)

[lottspot]

@anlutro you should be able to use something like

path, refvalue = iter(self._occurrences.items()).next()

In order to get the same result which is both py2/3 compatible

[Rtzq0]

I was planning to discuss this more in the review for #58 , the other question that I had with that change was the removal of:

while self.has_unresolved_refs():

at 175. That's why I commented I didn't understand the 2->3 move here.

[Rtzq0]

@lottspot since this is a general question, I guess I'll put it here instead of in the PR

I think we're in agreement that alterations to python 2 behavior should be considered out of scope for this unless utterly required. A bigger question is "should we use a compat library to avoid writing our own wrappers and if so should it be six or future?"

For the record I lean toward future as it's cleaner and has larger coverage, and I don't really care about python 2.4 and 2.5 or 3.2 (RHEL/CENTOS 5 is EOL now)

[lottspot]

I'm not particularly in favor of introducing an additional dependency in order to have py2/3 compatibility. Writing backwards compatible python3 is a trivial task in most cases, and I would want to see something in the code base which is not trivial to rewrite in a backwards compatible way before adding a new dependency to the project.

[Rtzq0]

Alright then that pretty much sets 2 requirements for the resolution to this issue:

1. Any changes to python 2 functionality must pass a high bar of necessity (and must be justified)
2. Additional dependencies are out of scope

Are you in agreement with these limits?

[lottspot]

I would agree with that. I think we could loosen up requirement 2 even to be more along the lines of number 1 in that introducing a new dependency doesn't necessarily have to be out of scope, but an exceptional need should be demonstrated before we accept the introduction of such a dependency