Am 25.11.2013 08:30, schrieb Sean Vig:
Is there a reason why we aren't using six?
It's covering a lot more ground than what compatibility.py does for Python
2/3 compatibility.
The gist of it is that while six covers a lot of ground, most of it is
ground we don't need covered, and we also do some custom stuff we need [1].
Six supports everything back to 2.4, and we only need to 2.6, which is much
more forgiving.
Agreed.
> The 2/3 lines of code that were added to core/compatibility
is ~100 lines, while six comes in at >500.
Yes, but the six stuff seems to cover aspects that we don't.
I mean stuff like this:
# It's possible to have sizeof(long) != sizeof(Py_ssize_t).
Not that this particular gem is goint to be too relevant for SymPy, but
I'm seeing things that are:
- Finding out whether a value is a primitive numeric type.
- raw_input vs. input
- __builtin__ vs. builtins
- reduce (which we should be using much more)
- xrange vs. range
- URL processing (for SymPy Online)
- iterkeys, itervalues, iteritems, iterlists
There's also some metaclass and wrapper stuff that I don't know what it
does and that might or might not be relevant.
Also, Python version detection could always be "if PY2" and "if PY3".
In SymPy, we sometimes compare for equality with 3, sometimes for being
greater than 2, sometimes we compare the minor version against zero, etc.
And that's just version detection.
Is there anything in particular you needed to do some form of version
sniffing outside of core/compatibility?
Yes, I needed to import __builtin__.
Which was renamed to builtins in Python 3.
The issue being not that the code is particularly nasty or anything,
it's just a simple
if sys.version_info[0] < 3: # Yet another way to do version checking
import __builtin__ as builtins
else:
import builtins
BUT I had to find out what went wrong, figure out the workaround, and
check it would work correctly on both Python versions (which meant
another day-long stall waiting for Travis to complete).
six wouldn't have helped finding out what went wrong :-)
But it would have had a known-to-work workaround available.
> I feel the only explicit 2/3
detection should be done there, and the relevant items imported.
Agreed but that doesn't give any preference to compatibility.py over six
or vice versa.
I have seen the arguments against six, but I don't think they are strong
- avoiding dependencies isn't an issue if you "install" it by copying it
over (and if we find an issue with six we can always upgrade the copy
we're using).
--
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.
