On Thu, Jul 25, 2013 at 10:41 AM, Sean Vig <[email protected]> wrote: > Most of the things in compatibility aren't too annoying, things that moved > or are renamed, but otherwise function exactly the same. > > One big annoyance was working with unicode strings and checking unicode > string output. The u'string' syntax doesn't work in 3.2 (though it was > re-introduced in 3.3), and so a u('string') wrapper has to be used, but in > pretty printing tests, that didn't work and I had to use an other u() > function [1].
Does this work with unicode docstrings? We can drop 3.2 support, though I'd rather not if we don't have to, since we already have been supporting it. > > Using metaclasses is not straightforward; because the standard way to define > metaclasses is different between 2 and 3, a completely different method has > to be used [2] which isn't very clear. This isn't a huge deal, because metaclasses are only used in the core, and no one understands how they work anyway :). But are there any gotchas that you know of doing metaclasses this way instead of the standard way? Is there a performance hit at import time? > > Dealing with map/range/filter was occasionally annoying, as they are now > return iterables in 3, which is usually fine for things like `for ... in > map/range/filter`, but would occasionally mean having to backtrack to find > where assignments were made with these functions and not wrapped in > `list()`. OK, so there are two kinds of annoyances: - Things that have fundamentally changed in Python 2 and 3, and we have to support both (like the metaclass or unicode literal thing). - Things that are different in Python 3, but we can completely do them that way in Python 2 with just some imports (like print function, range iterable). The second things are only annoying because it's different than what we're used to :) Some of these Python 3 decisions are controversial (like the print function), but I think they are ultimately for the best. We should just learn to deal with range being an iterable and print being a function. These are things that we would have to do anyway, when we drop Python 2 and only use Python 3. So it's really only the first things I am concerned about. Aaron Meurer > > Sean > > [1] https://github.com/sympy/sympy/pull/2318/files#L290R22 > [2] https://github.com/sympy/sympy/pull/2318/files#L76R93 > > On Thu, Jul 25, 2013 at 9:45 AM, Aaron Meurer <[email protected]> wrote: >> >> I'll ask here what I asked on the pull request. Can you give a list of >> the things that we would have to do to support both. I'm concerned >> about the annoyance factor here. Obviously, we've had a compatibility >> file for some time, so we are no strangers to such things, but I'd >> like to know what we'd be getting into here, beyond the obvious >> print() instead of print. >> >> Aaron Meurer > > -- > 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.
