python3 status report

[Frédéric Chapoton]

Hello everybody,

here is a small progress report on porting sage to python3. Good, but still too slow for my taste. The sooner we can catch up with jupyter, the better..

(1) with the latest beta (8.7.b1), there are now exactly 200 files having failing doctests, and a total of 866 failing doctests. Among those, 74 files have 1 failing doctest.

(2) the most badly failing file is "explain_pickle" with 70 failing doctests. Hopefully, this will be treated very carefully by Erik M. Bray

(3) after that, we still have problems with graph, where generic_graph.py has 50 failing doctests. But good progress was made by David Coudert,

(4) then, various small issues, such as sorting sets and dictionaries, etc. Some good python3 changes are blocked by the long awaited ticket https://trac.sagemath.org/ticket/23572

STATEMENT : I would to advocate that *every developer switch to python3 NOW*.

This will help to prevent regressions, as the one that happened recently in elliptic curves. This will also motivate people to fix the part of the code base that they use and that still fails.

Please vote !

Frédéric

[Simon King]

Hi Frédéric,

On 2019-01-27, Frédéric Chapoton <fchap...@gmail.com> wrote:
> (2) the most badly failing file is "explain_pickle" with 70 failing
> doctests. Hopefully, this will be treated very carefully by Erik M. Bray
>
> (3) after that, we still have problems with graph, where generic_graph.py
> has 50 failing doctests. But good progress was made by David Coudert,

Is there an apparent common reason for most of these failing tests? Such
as code that makes assumptions on sorting (which, IIRC, is different in
Python 2 and Python 3)?

> *STATEMENT *: I would to advocate that **every developer switch to python3
> NOW**.

How?

To make my question more precise: For production I would like to
keep a python 2 installation of Sage. So, given my existing Sage
installation, what would be the easiest way to create a second
installation with python 3 that is automatically configured to work
well with "git trac"? I guess it is some kind of git clone. Also I
don't know what make target is needed.

Best regards,
Simon

[Vincent Delecroix]

You need a different clone of your git repo, let say sage-py3. In that
clone, do

$ make configure
$ ./configure --with-python=3

Then, unless you rerun configure, every call to make will take care
of the Python 3 switch automatically.

See also https://wiki.sagemath.org/Python3-compatible%20code

Vincent

[Frédéric Chapoton]

> *STATEMENT *: I would to advocate that **every developer switch to python3
> NOW**.

How?

To make my question more precise: For production I would like to
keep a python 2 installation of Sage.

I am pretty sure you would be rather happy working only with python3.

 

So, given my existing Sage
installation, what would be the easiest way to create a second
installation with python 3 that is automatically configured to work
well with "git trac"? I guess it is some kind of git clone. Also I
don't know what make target is needed.

How to build sage with python3:

first "git clone" into another dir, say "sage3" then inside this dir:

make configure

./configure --with-python=3

make build

The first two lines need only be used once and for all.

concerning the tests, there is currently a partial test target that ensure that thing know to pass still pass

if you want to run all tests, then all course, you will meet failures in some parts of sage

[Simon King]

Hi Vincent,

On 2019-01-27, Vincent Delecroix <20100.d...@gmail.com> wrote:
> You need a different clone of your git repo, let say sage-py3.

How to do so most easily, so that "git pull" etc. still referes to trac?
That was part of my question. Doing "git pull
/path/to/my/old/installation" would mean that I need to go to my old
installation, "git pull" (pulls develop from trac), go to the new
installation, and to "git pull" again (pulling develop from my old
installation, but NOT directly from trac).

That's awkward and could certainly be done better.

>In that
> clone, do
>
> $ make configure
> $ ./configure --with-python=3

Thank you!

Best regards,
Simon

[Simon King]

Hi Frédéric,

On 2019-01-27, Frédéric Chapoton <fchap...@gmail.com> wrote:

> I am pretty sure you would be rather happy working only with python3.

That's too early. For teaching, I need to know that I have a working
Sage installation, and for research I also have to have a working
installation of my group cohomology spkg.

So far, there is no way for me to be sure that python3 would work for
me. Also, there is a high probability that I need to refactor my group
cohomology spkg so that it works in python3. So, FOR NOW, I won't
immediately drop python2.

Best regards,
Simon

[Frédéric Chapoton]

git clone git://github.com/sagemath/sage.git sage3

[Vincent Delecroix]

Le 27/01/2019 à 14:50, Simon King a écrit :
> Hi Vincent,
>
> On 2019-01-27, Vincent Delecroix <20100.d...@gmail.com> wrote:
>> You need a different clone of your git repo, let say sage-py3.
>
> How to do so most easily, so that "git pull" etc. still referes to trac?
> That was part of my question. Doing "git pull
> /path/to/my/old/installation" would mean that I need to go to my old
> installation, "git pull" (pulls develop from trac), go to the new
> installation, and to "git pull" again (pulling develop from my old
> installation, but NOT directly from trac).

This has nothing to do with python 3. You only need to set up
properly your remote and branches.

After

$ git clone sage-original sage-py3

The default remote in sage-py3 will be the sage-original local
folder. First step, add the remote for trac

(sage-py3) $ git remote add trac g...@trac.sagemath.org:sage.git

Second step set trac to be the default upstream

(sage-py3) $ git branch --set-upstream-to trac

For all this, the best is to read the git documentation.

Vincent

PS: the Frederic version is less trouble but more bandwidth!

[Vincent Delecroix]

PPS: if you intend to have a py2 and py3 installation it is a good
idea to have a shared $SAGE_ROOT/upstream/ repository (where
package tarballs are downloaded). This can be done via a simple
simlink in the py3 installation.

Maybe we could create a configure option --with-upstream=PATH for
this?

Vincent

Le 27/01/2019 à 14:56, Frédéric Chapoton a écrit :
> git clone git://github.com/sagemath/sage.git sage3
>
> Le dimanche 27 janvier 2019 14:50:22 UTC+1, Simon King a écrit :
>>
>> Hi Vincent,
>>

>> On 2019-01-27, Vincent Delecroix <20100.d...@gmail.com <javascript:>>

[Dima Pasechnik]

Why does one need two clones? We have functionality to allow a custom build location. It should be possible to give it to configure as a parameter...

--
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[Vincent Delecroix]

Please tell us how. None of us claimed that two clones were needed.

[Simon King]

Hi Vincent,

On 2019-01-27, Vincent Delecroix <20100.d...@gmail.com> wrote:
> This has nothing to do with python 3.

Sure.

> You only need to set up
> properly your remote and branches.

Exactly. And that's already more than what I can do in git without
reading tons of documentation.

> After
>
> $ git clone sage-original sage-py3
>
> The default remote in sage-py3 will be the sage-original local
> folder. First step, add the remote for trac
>
> (sage-py3) $ git remote add trac g...@trac.sagemath.org:sage.git
>
> Second step set trac to be the default upstream
>
> (sage-py3) $ git branch --set-upstream-to trac

Doesn't work for me.

king@klap:~/Sage/py3/sage$ git remote add trac g...@trac.sagemath.org:sage.git
king@klap:~/Sage/py3/sage$ git branch --set-upstream-to trac
error: the requested upstream branch 'trac' does not exist
hint:
hint: If you are planning on basing your work on an upstream
hint: branch that already exists at the remote, you may need to
hint: run "git fetch" to retrieve it.
hint:
hint: If you are planning to push out a new local branch that
hint: will track its remote counterpart, you may want to use
hint: "git push -u" to set the upstream config as you push.

> PS: the Frederic version is less trouble but more bandwidth!

Exactly. I thought a local copy would be both faster and easier to
obtain.

Best regards,
Simon

[Dima Pasechnik]

I believe it was added by

What I am unsure about now (too hard to dig using a phone :-)) is how to switch between different SAGE_LOCAL.

Probably by setting an env. variable.

https://trac.sagemath.org/ticket/21479

[Vincent Delecroix]

Hi Simon,

Le 27/01/2019 à 15:19, Simon King a écrit :
> On 2019-01-27, Vincent Delecroix <20100.d...@gmail.com> wrote:
>> This has nothing to do with python 3.
>
> Sure.
>
>> You only need to set up
>> properly your remote and branches.
>
> Exactly. And that's already more than what I can do in git without
> reading tons of documentation.
>
>> After
>>
>> $ git clone sage-original sage-py3
>>
>> The default remote in sage-py3 will be the sage-original local
>> folder. First step, add the remote for trac
>>
>> (sage-py3) $ git remote add trac g...@trac.sagemath.org:sage.git
>>
>> Second step set trac to be the default upstream
>>
>> (sage-py3) $ git branch --set-upstream-to trac
>
> Doesn't work for me.

My bad.

> king@klap:~/Sage/py3/sage$ git remote add trac g...@trac.sagemath.org:sage.git

After that, you should see "trac" among your remotes

$ git remote -v

And "origin" should be your local repo.

> king@klap:~/Sage/py3/sage$ git branch --set-upstream-to trac

This was an erroneous command. It is

$ git branch --set-upstream-to trac/develop

(or trac/mater if you cloned the master branch)

Note that this will only take care of the current
branch (develop).

Vincent

[Jeroen Demeyer]

On 2019-01-27 14:23, Frédéric Chapoton wrote:
> Some good python3 changes are blocked by the long awaited ticket
> https://trac.sagemath.org/ticket/23572

What do you mean with that? It's a ticket adding doctests for a book,
how is that related to Python 3 porting?

[Simon King]

Hi Vincent,

On 2019-01-27, Vincent Delecroix <20100.d...@gmail.com> wrote:
>> king@klap:~/Sage/py3/sage$ git remote add trac g...@trac.sagemath.org:sage.git
>
> After that, you should see "trac" among your remotes
>
> $ git remote -v
>
> And "origin" should be your local repo.

Correct!

king@klap:~/Sage/py3/sage$ git remote -v
origin /home/king/Sage/py3/../git/sage (fetch)
origin /home/king/Sage/py3/../git/sage (push)
trac g...@trac.sagemath.org:sage.git (fetch)
trac g...@trac.sagemath.org:sage.git (push)

> $ git branch --set-upstream-to trac/develop

king@klap:~/Sage/py3/sage$ git branch
* develop
t/13447/make_libsingular_multivariate_polynomial_rings_collectable

So, indeed we are talking about "develop", but:

king@klap:~/Sage/py3/sage$ git branch --set-upstream-to trac/develop
error: the requested upstream branch 'trac/develop' does not exist

hint:
hint: If you are planning on basing your work on an upstream
hint: branch that already exists at the remote, you may need to
hint: run "git fetch" to retrieve it.
hint:
hint: If you are planning to push out a new local branch that
hint: will track its remote counterpart, you may want to use
hint: "git push -u" to set the upstream config as you push.

So, still something is wrong.

Best regards,
Simon

[Frédéric Chapoton]

It is blocking https://trac.sagemath.org/ticket/26792

[Vincent Delecroix]

git has no clue what is on trac (of course) but apparently does not
want to find out automatically. Do

$ git fetch trac develop

so that it knows. And then

$ git branch --set-upstream-to trac/develop

(I tried and it worked). Though "git pull" is not a so good idea
since that would pull *all* branches from trac. You would better run

$ git pull trac develop

Vincent

[Timo Kaufmann]

Am Sonntag, 27. Januar 2019 14:32:16 UTC+1 schrieb Simon King:

> *STATEMENT *: I would to advocate that **every developer switch to python3
> NOW**.

How?

Git worktrees would be a solution. Essentially you keep one git repository, but check out two branches at the same time in different directories. From your main repo do this:

$ git worktree add /path/to/the/new/checkout branch-to-checkout

You'll keep your python2 checkout and the new directory will be part of the same repo. That means that remotes are set up as before and you have access to the same branches. You can also create a new branch and immediately create a worktree for that:

$ git worktree add -b my-feature-branch /path/to/the/new/checkout branch-to-checkout

[Simon King]

Hi Timo,

On 2019-01-27, Timo Kaufmann <eisf...@gmail.com> wrote:
> Git worktrees would be a solution. Essentially you keep one git repository,
> but check out two branches at the same time in different directories. From
> your main repo do this:
>
> $ git worktree add /path/to/the/new/checkout branch-to-checkout

Thank you! I am trying this, also having a symlink to the original
worktree's "upstream" directory.

Best regards,
Simon

[Frédéric Chapoton]

Does this mean that everything dependent on python will have to be recompiled when you switch ?

F

[Simon King]

Hi Frédéric,

On 2019-01-27, Frédéric Chapoton <fchap...@gmail.com> wrote:

> Does this mean that everything dependent on python will have to be
> recompiled when you switch ?

My original worktree was ~/Sage/git/sage. I added a new worktree
~/Sage/git/py3 using "git worktree add". The fact that
~/Sage/git/sage/local and ~/Sage/git/py3/local are not the same probably
means that no recompilation will be needed.

Best regards,
Simon

[David Coudert]

Is there an apparent common reason for most of these failing tests? Such
as code that makes assumptions on sorting (which, IIRC, is different in
Python 2 and Python 3)?

Many many methods were relying on sorted list of vertices and edges. We have done significant progresses to reduce that.

Another source of problems is that the order of keys of dictionary, i.e., list(mydict.keys()) or list(myset), might be different in py2 and py3. This breaks many doctests, but may be more complicated, it changes the order in which the neighbors of a vertex are visited (check G._backend.iterator_nbrs??). Consequently, the returned solution of some algorithms might be differents (but still correct). A solution is to tag doctests with py2 and py3.

The most complicated issue is certainly edges of Graph: we sort the vertices of an edge before returning it... I have no solution for this issue. We can decide to stop ordering the vertices, but then we will have to update a very large number of algorithms. We could also design a method to compare object of different types.

In fact, the main issue is that we use and compare vertices by id instead of mapping vertices to integer and work only with these integers. That would ease our life, but it's not easy to change that.

David.

[Simon King]

Dear all,

using "git worktree", I now have both python 2 and python 3 versions of
Sage on my computer. Thank you!

Of course, I started to check packages that I care about --- and
immediately found a problem with the "meataxe" optional package.

When trying to create a matrix of type Matrix_gfpn_dense, I get a
TypeError: expected bytes, str found.

Is there a ticket for meataxe on python 3 already? I guess not. So,
unless someone stops me in the next hour or so, I'll open one...

Best regards,
Simon

[Simon King]

Hi,

On 2019-01-27, Simon King <simon...@uni-jena.de> wrote:
> Is there a ticket for meataxe on python 3 already? I guess not. So,
> unless someone stops me in the next hour or so, I'll open one...

I created https://trac.sagemath.org/ticket/27152.

First problem: In py2,
PyBytes_AsString(os.path.join(DOT_SAGE,'meataxe')) works. In py3 it
doesn't, since os.path.join returns str not bytes.

The funny thing is that 2 years ago, I was told by Jeroen:
"""
For Python 3 compatibility, you should use bytes instead of str for
pickling.

This means changing the PyString_... functions to PyBytes_...
"""

So, I guess for Python 3 compatibility, I need to revert the change and
return to PyString_..., as os.path.join returns str.

Cheers,
Simon

[Simon King]

PS:

On 2019-01-27, Simon King <simon...@uni-jena.de> wrote:
> The funny thing is that 2 years ago, I was told by Jeroen:
> """
> For Python 3 compatibility, you should use bytes instead of str for
> pickling.
>
> This means changing the PyString_... functions to PyBytes_...
> """

To be fair, Jeroen talked about pickling, where PyBytes probably still
is the way to go.

But do py3 experts agree that to transform os.path.join(...) to char*
(which is not in pickling but in module initialisation), I need
PyString_...?

Best regards,
Simon

[Jeroen Demeyer]

On 2019-01-27 22:36, Simon King wrote:
> But do py3 experts agree that to transform os.path.join(...) to char*
> (which is not in pickling but in module initialisation), I need
> PyString_...?

No! Please see src/sage/cpython/string.pyx

(sorry no time now to answer more)

[Simon King]

Hi Jeroen,

On 2019-01-27, Jeroen Demeyer <J.De...@UGent.be> wrote:
> On 2019-01-27 22:36, Simon King wrote:
>> But do py3 experts agree that to transform os.path.join(...) to char*
>> (which is not in pickling but in module initialisation), I need
>> PyString_...?
>
> No! Please see src/sage/cpython/string.pyx

Thank you for the pointer!

Best regards,
Simon

[E. Madison Bray]

On Sun, Jan 27, 2019 at 2:55 PM Simon King <simon...@uni-jena.de> wrote:
>
> Hi Frédéric,
>
> On 2019-01-27, Frédéric Chapoton <fchap...@gmail.com> wrote:
> > I am pretty sure you would be rather happy working only with python3.
>
> That's too early. For teaching, I need to know that I have a working
> Sage installation, and for research I also have to have a working
> installation of my group cohomology spkg.

Although I do think Frédéric is jumping the gun *slightly*, he did
explicitly write "every developer switch to Python 3", which I took to
mean, use `./configure --with-python=3` in any Sage you use for
development of Sage itself.

If you are both developing Sage and using Sage for teaching you should
have separate installations anyways. You should be using a stable
version for teaching and research (unless actively doing development
for said research).

[Samuel Lelievre]

Sun 2019-01-27 14:23:08 UTC+1, Frédéric Chapoton:

>

> here is a small progress report on porting sage to python3.

> Good, but still too slow for my taste. The sooner we can

> catch up with jupyter, the better..

>

> (1) with the latest beta (8.7.b1), there are now exactly 200 files

> having failing doctests, and a total of 866 failing doctests.

> Among those, 74 files have 1 failing doctest.

>

> (2) the most badly failing file is "explain_pickle" with 70 failing

> doctests. Hopefully, this will be treated very carefully by Erik M. Bray

>

> (3) after that, we still have problems with graph, where generic_graph.py

> has 50 failing doctests. But good progress was made by David Coudert,

>

> (4) then, various small issues, such as sorting sets and dictionaries,

> etc. Some good python3 changes are blocked by the long awaited ticket

> https://trac.sagemath.org/ticket/23572

>

> STATEMENT: I would to advocate that *every developer switch to python3 NOW*.

>

> This will help to prevent regressions, as the one that happened recently

> in elliptic curves. This will also motivate people to fix the part of the

> code base that they use and that still fails.

>

> Please vote!

Strong +1 from me.

Many, many thanks to you Frédéric, and the small team who got involved,

for your efforts on getting Sage Python 3 ready. I have been using the

Python 3 version exclusively for a while now and enjoying it a lot.

I would also encourage all developers (and users) to use their `init.sage`

to help use Python3 habits even whey working with Python2-based Sage.

Here is my `init.sage`, suggestions welcome:

    https://github.com/slel/sagemath-tips/blob/master/init-dot-sage/init.sage

In particular it forces me to always use Python3-style print!

[Eric Gourgoulhon]

Le mardi 29 janvier 2019 10:29:43 UTC+1, Samuel Lelievre a écrit :

Sun 2019-01-27 14:23:08 UTC+1, Frédéric Chapoton:

>

>

> STATEMENT: I would to advocate that *every developer switch to python3 NOW*.

>

>

> Please vote!

Strong +1 from me.

+1 from me too.

Many, many thanks to you Frédéric, and the small team who got involved,

for your efforts on getting Sage Python 3 ready.

A big +1 !

I have been using the

Python 3 version exclusively for a while now and enjoying it a lot.

+1

As a side note, let me point that the manifold examples posted at

https://sagemanifolds.obspm.fr/examples.html

work like a charm with Python 3 (I've tested a selected sample and they all work, including those involving SymPy, without any modification).

I would also encourage all developers (and users) to use their `init.sage`

to help use Python3 habits even whey working with Python2-based Sage.

Here is my `init.sage`, suggestions welcome:

    https://github.com/slel/sagemath-tips/blob/master/init-dot-sage/init.sage

In particular it forces me to always use Python3-style print!

Thanks for sharing.

Eric.

[Daniel Krenn]

On 2019-01-27 14:50, Simon King wrote:
> How to do so most easily, so that "git pull" etc. still referes to trac?
> That was part of my question. Doing "git pull
> /path/to/my/old/installation" would mean that I need to go to my old
> installation, "git pull" (pulls develop from trac), go to the new
> installation, and to "git pull" again (pulling develop from my old
> installation, but NOT directly from trac).

I use `git worktree` a lot and might be helpful for you as well

[Thierry]

Hi,

On Sun, Jan 27, 2019 at 11:21:21AM -0800, David Coudert wrote:
[...]

> The most complicated issue is certainly edges of Graph: we sort the
> vertices of an edge before returning it... I have no solution for this
> issue. We can decide to stop ordering the vertices, but then we will have
> to update a very large number of algorithms. We could also design a method
> to compare object of different types.
> In fact, the main issue is that we use and compare vertices by id instead
> of mapping vertices to integer and work only with these integers. That
> would ease our life, but it's not easy to change that.

We discussed the difference between mathematical and algorithmic level
various times (for equality, comparison, etc).

Here, at the "algorithmic" level, the vertices are of course comparable,
and most algorithms in graph theory rely on this (starting by the most
fundamental such as DFS, BFS, etc). Trying to avoid comparison of
vertices would be suicidary, and trying to do that with Sage will just
lead to unreadable artificially complicated code.

If you want an integer label for each vertex, why not just ask to the
backend:

sage: G = graphs.WorldMap()
sage: G
World Map: Graph on 251 vertices
sage: G.vertices()[0]
'Afghanistan'

sage: GG = G._backend.c_graph()[0]
sage: GG
<sage.graphs.base.sparse_graph.SparseGraph object at 0x7ff500875768>
sage: GG.verts()[0]
0

So, somehow, you do not have to map Sage objects back to integers, since
we already have a map from integers to Sage objects.

I did not check the implementations, but though it is kind of too late
given the size of Sage, i would advocate to have two explicit layers for
combinatorial objects such as words, graphs, permutations, etc, one
"algorithmic" where the atoms are integers, with all the good
properties, and a "label" dictionary, where we could attach any Sage
object to them for "mathematical" questions. And it would be amazing if
they were an specified way to do that uniformly.


That said, regarding the .edges() method, i think that returning a list
of pairs is a very wrong approach (though this is what is done for
years). Indeed, a list is not only an iterator, but also a container. In
particular:

(a,b) in G.edges()

is a syntaxially correct statement, but it is far from equivalent to:

G.has_edge(a,b)

Which is extremely misleading and can lead to silent mistakes
(personally, i used lot of hand-made reorderings in my pyograms before i
discovered has_edge).

Here i would advocate that G.edges() returns a *view* on G, with a
dedicated __iter__ method corresponding to the edge_iterator method and
a __contains__ method corresponding to the has_edge method. By having a
view, you will save a lot of time and memory, and have the benefit that
it will follow the graph's mutations.

Ciao,
Thierry



> David.

[Volker Braun]

Also, I have now set up a Python3 buildbot to catch regressions!

[David Coudert]

In fact we already have methods to do that, but changing the code to use these methods is not an easy task...

sage: G = graphs.PetersenGraph()
sage: G.set_vertex(0, 'abc')
sage: G.set_vertex(1, graphs.CycleGraph(3))
sage: print(G.get_vertices())
{0: 'abc', 1: Cycle graph: Graph on 3 vertices, 2: None, 3: None, 4: None, 5: None, 6: None, 7: None, 8: None, 9: None}

That said, regarding the .edges() method, i think that returning a list
of pairs is a very wrong approach (though this is what is done for
years). Indeed, a list is not only an iterator, but also a container. In
particular:

    (a,b) in G.edges()

is a syntaxially correct statement, but it is far from equivalent to:

    G.has_edge(a,b)

Which is extremely misleading and can lead to silent mistakes
(personally, i used lot of hand-made reorderings in my pyograms before i
discovered has_edge).

Here i would advocate that G.edges() returns a *view* on G, with a
dedicated __iter__ method corresponding to the edge_iterator method and
a __contains__ method corresponding to the has_edge method. By having a
view, you will save a lot of time and memory, and have the benefit that
it will follow the graph's mutations.

This is an interesting idea, although I'm not sure how to implement that efficiently.

David.

PS: when all currently in "needs review" tickets will be closed, the number of py3 failing doctests in the graph module will be small (HELP welcome here to review tickets and fix remaining doctests). It will then become easier to see the effect of changes like not sorting end vertices of edges (we could try that), implement a *view* on G, etc.

 

[Jeroen Demeyer]

I don't see why it should be inefficient (assuming you implement it in
Cython of course).

[Thierry]

Hi,

On Mon, Feb 11, 2019 at 11:14:35AM +0100, Jeroen Demeyer wrote:
> On 2019-02-11 11:12, David Coudert wrote:
> >
> >
> > Le mardi 29 janvier 2019 23:19:12 UTC+1, Thierry (sage-googlesucks@xxx)
> > a écrit :

[...]

> >
> > That said, regarding the .edges() method, i think that returning a list
> > of pairs is a very wrong approach (though this is what is done for
> > years). Indeed, a list is not only an iterator, but also a
> > container. In
> > particular:
> >
> > (a,b) in G.edges()
> >
> > is a syntaxially correct statement, but it is far from equivalent to:
> >
> > G.has_edge(a,b)
> >
> > Which is extremely misleading and can lead to silent mistakes
> > (personally, i used lot of hand-made reorderings in my pyograms
> > before i
> > discovered has_edge).
> >
> > Here i would advocate that G.edges() returns a *view* on G, with a
> > dedicated __iter__ method corresponding to the edge_iterator method and
> > a __contains__ method corresponding to the has_edge method. By having a
> > view, you will save a lot of time and memory, and have the benefit that
> > it will follow the graph's mutations.
> >
> >
> > This is an interesting idea, although I'm not sure how to implement that
> > efficiently.
>
> I don't see why it should be inefficient (assuming you implement it in
> Cython of course).

Actually, a view is somehow pointing to an existing object, so it is
O(1), to be compared to contstructing a list which is O(|E|).

Ciao,
Thierry

[John Cremona]

On Sun, 27 Jan 2019, 13:39 Vincent Delecroix, <20100.d...@gmail.com> wrote:

Le 27/01/2019 à 14:32, Simon King a écrit :
> Hi Frédéric,
>
> On 2019-01-27, Frédéric Chapoton <fchap...@gmail.com> wrote:

>> (2) the most badly failing file is "explain_pickle" with 70 failing
>> doctests. Hopefully, this will be treated very carefully by Erik M. Bray
>>
>> (3) after that, we still have problems with graph, where generic_graph.py
>> has 50 failing doctests. But good progress was made by David Coudert,
>

> Is there an apparent common reason for most of these failing tests? Such
> as code that makes assumptions on sorting (which, IIRC, is different in
> Python 2 and Python 3)?
>

>> *STATEMENT *: I would to advocate that **every developer switch to python3
>> NOW**.
>
> How?
>

> To make my question more precise: For production I would like to
> keep a python 2 installation of Sage. So, given my existing Sage
> installation, what would be the easiest way to create a second
> installation with python 3 that is automatically configured to work
> well with "git trac"? I guess it is some kind of git clone. Also I
> don't know what make target is needed.

You need a different clone of your git repo, let say sage-py3. In that
clone, do

     $ make configure
     $ ./configure --with-python=3

Then, unless you rerun configure, every call to make will take care
of the Python 3 switch automatically.

Not quite: doing make distclean will take you back to the python2 default and you'll need to run configure again.  This just happened to me. (I have a bad habit of doing make distclean; make whenever anything mysterious happens).

See also https://wiki.sagemath.org/Python3-compatible%20code

Vincent