+1 As others mentioned, there are at least 3 similar cases where future imports should be used:
* The sage library (this thread) * The preparser * Doctest runner I'm in favor of either. A preparser change should probably coincide with a major version change. On Thursday, April 21, 2016 at 10:33:42 AM UTC+2, Jeroen Demeyer wrote: > > Hello, > > concerning the porting of Sagelib(*) to Python 3, I propose to > eventually add > > from __future__ import print_function, division, absolute_import, > unicode_literals > > to *every* .py(x) file in Sagelib (even those modules which don't print, > don't divide, don't import and don't have literals). The reason is > twofold: > - whenever we add such a future import, we force new code to use > printing/division/imports/literals compatible with Python 3. > - adding the future import serves as documentation that a particular > module has been ported to Python 3, at least for the aspects which the > future statements enforce. > > We obviously do not have to add all these imports all at once, we can > gradually add them while we port code to Python 3. I already added a few > __future__.division imports while I was porting some divisions. > > What do you think? > > Jeroen. > > > > (*) As opposed to Sage-the-distribution, Sagelib refers to the Python > package "sage" with sources in $SAGE_ROOT/src/sage > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
