inconsistent behavior of .copy() on immutable graphs

[maxale]

Is there an existing issue for this?

• I have searched the existing issues for a bug report that matches the one I want to file, without success.

Did you read the documentation and troubleshoot guide?

• I have read the documentation and troubleshoot guide

Environment

- **OS**: Ubuntu 22.04
- **Sage Version**: 9.8.rc0

Steps To Reproduce

Function f(H) below print the immutability status of a given graph H and that of H.copy():

def f(H):
    print('H:', H.is_immutable(),flush=True)
    print('H.copy():', H.copy().is_immutable(),flush=True)
    

G = Graph(immutable=True)
f(G)

import multiprocessing
multiprocessing.Pool().imap_unordered(f,[G])

Expected Behavior

Whether we use multiprocessing or not, H.copy() should inherit the immutability of H.

Actual Behavior

The code output is:

H: True
H.copy(): True
<multiprocessing.pool.IMapUnorderedIterator object at 0x7f05e6ada680>
H: True
H.copy(): False

First, we create an immutable graph G. When we call f(G) directly, the created copy of it is immutable (as expected). However, when we call the same function using via multiprocessing, f reports the the input graph is still immutable (which is good), while its copy somehow becomes not immutable (which is bad).

Additional Information

No response

[mkoeppe]

Larger context:

• Meta-ticket: Support Python's __copy__ / __deepcopy__ protocol #13811

[nbruin]

Actually, an immutable "copy" of an immutable graph could actually just be a reference to the original. It's immutable after all! The only reason to make a copy of an immutable object is to get a mutable copy. I'm pretty sure this is the rationale behind the behaviour. It is consistent with, for instance, vectors:

sage: v=vector([1,2,3],immutable=True)
sage: v.is_immutable()
True
sage: w=copy(v)
sage: w.is_immutable()
False

[mkoeppe]

Previous discussion:

• Meta-ticket: Support Python's __copy__ / __deepcopy__ protocol #13811 (comment)
• Guide for parents with immutable elements #32353

[maxale]

I'm fine with whatever outcome of .copy() (immutable or not), but this bugreport about its behavior being inconsistent across the two calls to f(G) on the same immutable graph G: in one (direct) call it creates an immutable copy, while in the other (via multiprocessing) it creates a mutable copy.

[maxale]

Btw, #34598 is another issue when using multiprocessing breaks behavior of Sage objects. I suspect it having the same origin as the current one.

[nbruin]

A workaround may be to use copy(G). By the looks of it, this is consistent.

It looks like the immutable handling on Graph predates the more standardized approaches: set_immutable doesn't exist on graphs, for one thing, and one can very well imagine this to be useful (build a graph through various mutations and then fix them to get an immutable and hopefully hashable object).

If you change the applied function to

sage: def f(H):
....:     print((H).__dict__,flush=True)

you can see that the reproduction through multiprocessing has a different backend defined. Looking at Graph.copy you'll see that this can have various consequences. It also shows that copy has some other function than to just get a copy of the existing (mutable) object. In fact the documentation has a warning:

   Warning:

     Please use this method only if you need to copy but change the
     underlying data structure or weightedness. Otherwise simply do
     "copy(g)" instead of "g.copy()".

[maxale]

If you change the applied function to

sage: def f(H):
....:     print((H).__dict__,flush=True)

you can see that the reproduction through multiprocessing has a different backend defined.

Thank you for the insight. As I view it now, the current issue is in fact a combination of two rather unrelated ones:

• multiprocessing causes the change in the backend for graph objects passed over to a parallel function: from sage.graphs.base.static_sparse_backend.StaticSparseBackend to sage.graphs.base.sparse_graph.SparseGraphBackend
• the .copy() method has inconsistent behavior across the two backends.

Personally I care more about the first issue as I see some other buggy things happening around it, while .copy() behavior is rather a minor issue.