On Mon, Nov 25, 2013 at 6:51 AM, Sean Vig <[email protected]> wrote: > 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.
One should view Python 3.x as just another version of Python. As such, there is no conceptual difference between porting from 2.6 to 2.7, versus 2.7 to 3.2. All such compatibility changes go into the compatibility.py file. Ondrej P.S. I agree with everything Sean wrote in this thread. > >> >> 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > For more options, visit https://groups.google.com/groups/opt_out. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
