On Sun, Sep 1, 2019 at 9:14 PM Thierry <sage-googlesu...@lma.metelu.net> wrote: > > Hi, > > it seems to me that Python 3 migration should not only be a syntax > adaptation (like print('blah')), unicode, or the mitigation of issues > related to the fact that different objects are not always comparable. > > It should also take into account some deep changes in the logic. > > > Lists vs Iterables > ------------------ > > In Python 2, lists are a central type. In Python 3, most of them are > turned into iterators, including the very important range(): > > Python 2: > > In [1]: range(3) > Out[1]: [0, 1, 2] > > Python 3: > > In [1]: range(3) > Out[1]: range(0, 3) > > > In Sage, there are a lot of blah() methods that return lists or tuples, > which have a blah_iterator() counterpart. > > For me, in such situations, the Python 3 migration should let blah() > become an iterator and deprecate blah_iterator(). We should avoid > returning lists when we can return iterators, and this by default to > follow this Python 3 change. > > > Copies vs Views > --------------- > > Lot of basic methods do not return copies of (part of) an object, but > remains linked to that object. > > Here is an example with dicts: > > Python 2: > > In [1]: d = {1:2, 3:4} > > In [2]: d > Out[2]: {1: 2, 3: 4} > > In [3]: k = d.keys() > > In [4]: k > Out[4]: [1, 3] > > In [5]: d[5] = 6 > > In [6]: d > Out[6]: {1: 2, 3: 4, 5: 6} > > In [7]: k > Out[7]: [1, 3] > > Python 3: > > In [1]: d = {1:2, 3:4} > > In [2]: d > Out[2]: {1: 2, 3: 4} > > In [3]: k = d.keys() > > In [4]: k > Out[4]: dict_keys([1, 3]) > > In [5]: d[5] = 6 > > In [6]: d > Out[6]: {1: 2, 3: 4, 5: 6} > > In [7]: k > Out[7]: dict_keys([1, 3, 5]) > > > Our methods should also reflect this logic when migrating to Python 3. > > A few examples: vertices() and edges() of graphs should not be lists, > but keep links to the graph itself. Similar for rows, columns of > matrices, as it is already the case in numpy: > > In [1]: import numpy as np > > In [2]: M = np.array([[1, 2], [3, 4]]) > > In [3]: M > Out[3]: > array([[1, 2], > [3, 4]]) > > In [4]: row = M[0] > > In [5]: row > Out[5]: array([1, 2]) > > In [6]: M[0,0] = 5 > > In [7]: M > Out[7]: > array([[5, 2], > [3, 4]]) > > In [8]: row > Out[8]: array([5, 2]) > > > One might argue that it will break backward consistency, but > Sage-Python2 user code will break anyway, and users will have to work on > adapting their scripts when Python 3 will become Sage's default. > > Hence, more generally, i wonder whether one could take the opportunity, > from Python 3 becoming the default, to fix all other inconsistencies of > Sage, that are kept forever in the name of backward-compatibility. > > This would imply not making Python 3 the default too early, let is not > miss this opportunity !
Agreed, and that's just the beginning! E.g. there are so many possibilities for use of type annotations in Sage :) See https://docs.python.org/3/library/typing.html -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAOTD34b9eyZCJ%3Dp0Ox%2BHHtNFp_7tQ7%2B%3D6e1ko5qHUuU%3D0D%3DRLw%40mail.gmail.com.