FrozenNFA constructor attempts to call deepcopy on frozendicts

[no-preserve-root]

The VisualNFA constructor attempts to create a deep copy of the passed nfa, especially the transitions dictionary:

visual-automata/visual_automata/fa/nfa.py

Line 469 in 3ea0cdc

all_transitions = all_transitions.deepcopy()

The deepcopy method is monkeypatched onto dict via curse:

visual-automata/visual_automata/fa/nfa.py

Line 32 in 3ea0cdc

curse(dict, "deepcopy", deepcopy)

However, automata-lib 7.0.1 returns a frozendict from the frozendict package instead, so the method call fails. It is not clear if copying the frozendict is at all necessary; deepcopy returns the object as-is.

MRE

Using most recent versions:

• automata-lib 7.0.1
• visual_automata 1.1.1

from automata.fa.nfa import NFA
from visual_automata.fa.nfa import VisualNFA

nfa = NFA(states={"q0"}, input_symbols={"i0"}, transitions={"q0": {"i0": {"q0"}}}, initial_state="q0",
          final_states={"q0"})
VisualNFA(nfa).show_diagram(view=True)

Expected Behavior

The automaton is shown.

Actual Behavior

Traceback (most recent call last):
  File "/path/to/scratch_1.py", line 6, in <module>
    VisualNFA(nfa).show_diagram(view=True)
  File "/path/to/site-packages/visual_automata/fa/nfa.py", line 619, in show_diagram
    all_transitions_pairs = self._transitions_pairs(self.nfa.transitions)
  File "/path/to/site-packages/visual_automata/fa/nfa.py", line 469, in _transitions_pairs
    all_transitions = all_transitions.deepcopy()
AttributeError: 'frozendict.frozendict' object has no attribute 'deepcopy'

[lewiuberg]

Good morning @no-preserve-root! I will have a look at this after work. If you have a fix, feel free to submit a PR to the Dev branch 🙂

[no-preserve-root]

(Im-)mutability seems to be a larger issue with automata-lib 7. Since the automata-lib types are all immutable now, setters can not work as intended any more; also some protected attributes were renamed. I would be willing to try and write a patch for this, but my suggestion would be to

1. release a version (1.1.2?) of visual-automata as-is (perhaps with a fix for VisualDFA constructor implicitly checks wrapped automaton cardinality #7) with version metadata in the requirements that requires automata-lib~=6 to ensure downstream projects use a compatible version, and then
2. release a major release of visual-automata (2.0.0) that requires automata-lib~=7, removes setters for Visual*FA, and fixes the access issues.

What do you think @lewiuberg?

[lewiuberg]

I haven't looked at this library or automata-lib for some time, but I think you are correct 👍🏻 I'll have a look at this today or tomorrow, depending on work.

[ThaddeusOwl]

Is there any update on solutions for resolving this issue?