I have a PR to pull all version checking back into compatibility.py [1]. Personally, I don't think that it's a big deal to add a hard dependency to > the six module for sympy.
I think this would be a bad decision. There are several things we have modified from six, such as the with_metaclass function, having the six version could throw a wrench into the mix. In addition, since we do have some completely custom stuff, this would create 2 separate locations for Python version compatibility code, further complicating something that is already bordering on messy. > In that case, I think that fact should be clearly visible. > I'd suggest forking out that code from compatibility.py and move it into a > separate six.py, explaining what was taken and what was left out, and why. > That would make it easier to decide when an update would be in order, too > :-) > (We should also mention the origin of the code, in the name of giving > proper credit and such.) > Pulling the code out of compatibility.py would be similarly bad, as we'd again be left with 2 locations for compatibility fixes. Furthermore, at this point, I think the only code that is discernibly from six is 'exec_', everything else is very generic (e.g. `unicode = str` in 3, `unicode = unicode` in 2). If we want to flag `exec_` with the six disclaimer, that's fine, but it shouldn't be in a separate file. I'm also not too happy about the name "compatibility". > One, it's not where you go looking when you hit a Python 2/3 issue. Had it > been named python3.py, I'd have known where to look. (I bet the authors of > the various version tests weren't aware of it either, otherwise, we > wouldn't see different code for Python version checking wherever the need > arises. ... well, in fact we shouldn't see *any* explicit Python version > checking anywhere.) > Two, it's not where you go looking when you hit an issue that involves > NumPy etc. being either installed or not installed. > I.e. the name doesn't say anything about the topic the module covers. > The name was probably born out of the fact that the module was originally for compatibility between Python 2 versions. While changing the name would be okay, there are still some Python 2.6 vs >=Python 2.7 compatibility fixes around, so something along the lines of python3.py would be equally inappropriate. > Oh, and there's another compatibility.py. It covers differences between > dense and sparse matrices. > I think it has the same naming issue, but I guess I'll leave that to the > matrix guys :-) Yeah, it's probably not great to have multiple 'compatibility.py's, but the use other one seems much more straightforward, and is clearly distinct. Sean [1] https://github.com/sympy/sympy/pull/2629 -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
