The pyrepl dependency seems to be not doing so well.
There is rarely any activity and the github and pypi versions have diverged: pypy/pyrepl#36
Additionally, there is python2-only syntax used:
> rg \\braise.\*,
pyrepl/pygame_keymap.py
93: raise KeySpecError, \
97: raise KeySpecError, "doubled \\C- (char %d of %s)"%(
103: raise KeySpecError, \
107: raise KeySpecError, "doubled \\M- (char %d of %s)"%(
122: raise KeySpecError, \
129: raise KeySpecError, \
135: raise KeySpecError, \
164: raise KeySpecError, \
pyrepl/python_reader.py
60: raise cls, val, tb
pyrepl/pygame_console.py
302: raise Exception, "erp!"
Not saying this to flame the people who worked on it of course, but it puts this package and its dependents in a precarious position. I'm using pdbpp in my daily work and haven't run into issues, so I assume the problematic code paths aren't used, but we should probably think if there is a way to support pyrepl or, if necessary, remove the dependency.
I understand that this might be a hard topic and hope we can find a good solution without explicit of implied shaming
The pyrepl dependency seems to be not doing so well.
There is rarely any activity and the github and pypi versions have diverged: pypy/pyrepl#36
Additionally, there is python2-only syntax used:
Not saying this to flame the people who worked on it of course, but it puts this package and its dependents in a precarious position. I'm using pdbpp in my daily work and haven't run into issues, so I assume the problematic code paths aren't used, but we should probably think if there is a way to support pyrepl or, if necessary, remove the dependency.
I understand that this might be a hard topic and hope we can find a good solution without explicit of implied shaming