Porting

[cooperdk]

I will create a new fork later, just testing first.

I have the xml_dump working on Py3. I expect it has been defective always, at least, I couldn't get it to work as it was still coded for Python 2.7.

[cooperdk]

Sorry, it seems that I forgot to change branch. It might actually be working in the prepare-for-publication branch.

[elsiehupp]

Even if you're working in the prepare-for-publication on your computer, it doesn't seem that you've pushed it to the repository. How about you do your work as is for now and let me know when you need to figure out merging?

[elsiehupp]

Actually, you mention creating a fork: because I added you as a collaborator, you should be able work directly with the branches in the repository without having to forking it first. The main limitation is that the python3 branch is protected so that you have to go through the process of doing a Pull Request before being able to merge into it. Ideally once the prepare-for-publication branch is, well, prepared for publication, it would get merged into the python3 branch, i.e. the default branch, and from there get published to PyPI.

Also if you're not hugely comfortable with Git, FYI the GitHub Desktop app simplifies a lot of the procedures specific to collaborating on GitHub, though unfortunately I don't think it's available for Linux, just Windows and macOS. Working in VS Code also helps things somewhat, but it's not quite as streamlined as GitHub Desktop. (VS Code also helps with mypy warnings and whatnot, though if you're more comfortable with another IDE, that's fine.)

[elsiehupp]

Regarding where you might start, prepare-for-publication should let you run the existing unit tests, and that should show you what the unit tests think is working and what they think is not. IIRC my initial purpose with the branch was to get all of the unit tests to pass, but I kind of got carried away with mypy and proper object-oriented design patterns. (Basically I hate anonymous JSON-style dictionaries in Python and instead prefer fully defined object classes.)

I would also say you can largely ignore the as-yet nonfunctional GUI code, but if you're changing symbol names in the dumpgenerator, please try and make sure any references to those symbol names get changed in the GUI code as well.

[elsiehupp]

Again, the prepare-for-publication branch is drastically different from the python3 branch, and I would prefer you work with the prepare-for-publication so that the effort I've put into it doesn't get wasted.

[t-karcher]

Also, regardless of which of those two branches you use: Both have been tested and used without issues in Python 3, so if it doesn't work for you, you might still be in a wrong branch or using a configuration not yet tested.

[elsiehupp]

I haven't tested either prepare-for-publication or python3 particularly thoroughly, but prepare-for-publication comes quite close to passing the unit tests, and none of the other various respondents who've tried python3 have said that it doesn't work. Regardless, I wouldn't say I'm intimately familiar with how the program works, and part of the purpose with the prepare-for-publication branch is to make the program easier to understand.

That said if I remember correctly prepare-for-publication also mostly passes mypy, the main exception being the GUI code where I started replacing Tk with Qt but never finished.