+1 to this!
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 !
>
> 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/20190901191448.frswpsu7wqj6gmq6%40metelu.net.
>
--
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/CAMLx2CqJJdb7r87dCNG5%2Bji2K-DKxmh9DJ3Qca%2BkwKcvbiOOvg%40mail.gmail.com.
