On Thu, Jul 25, 2013 at 10:54 AM, Ondřej Čertík <[email protected]> wrote: > On Thu, Jul 25, 2013 at 9: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]. > > So we can view this as a temporary workaround for Python 3.2, that > eventually we'll drop in the future. A little annoying, but quite simple > syntax change.
I wasn't planning on dropping 3.2 support any time soon, though. We maybe should consider it if this starts to get annoying. Aaron Meurer > >> >> 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. > > So basically, whenever we declare a SymPy class > that uses metaclasses, instead of doing: > > class Pi(NumberSymbol): > __metaclass__ = Singleton > ... > > we now have to do: > > class Pi(with_metaclass(Singleton, NumberSymbol)): > ... > > In other words, if you don't use __metaclass__, then no change is necessary. > If you do use __metaclass__, then you have to understand what it is > doing anyway, > so typically you are not a Python beginner anymore at this point. And > in that case, > a simple syntax change is imho minor. It also doesn't seem to affect many > classes in sympy (fortunately). > >> >> 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()`. > > This seems a minor. > > Ondrej > >> >> 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. > > -- 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.
