I think the change you propose is reasonable. However, it sounds like a lot
of work, and the support for python2 ends in just a few months. We should
aim to release a python3 based release that passes all tests before the end
of the year.
Do you think it is reasonable to do these deep changes in this short time?
If it is , then i definitely vote for it.
If it is not, then I would propose to leave it as a longer term goal
(hopefully not much longer), and once we have a fully python3 bases sage,
write the guidelines you gave down in the development guide so the new code
follows this approach. Then we can port the old code to the new models you
suggest, without the rush of a deadline.
El domingo, 1 de septiembre de 2019, 21:14:51 (UTC+2), Thierry
(sage-googlesucks@xxx) escribió:
>
> 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 !
>
> Ciao,
> Thierry
>
>
--
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/05f6d001-f8f9-43cf-913c-ccdf613744bb%40googlegroups.com.
