Add typing and drop support for EOL versions

[GideonBear]

Closes #21
Todo (in no particular order):

• Run mypy, tests and coverage (fail below 100%) automatically (GitHub actions, maybe pre-commit?)
• Move tests to pytest
• Increment version (2.0)
  • Remove deprecated aliases and functions (Database, ListDatabase, DictDatabase, set_data)
• Release to PyPI
• Add types
• Add py.typed file
  • Add py.typed to distribution (package_data)
• Check types on own usage
• Run pyupgrade
• Add from __future__ import annotations
• Add/drop versions to/from classifiers and requires-python
• Resolve # TODOs
• Use pathlib and Path.open
• Use pyproject.toml/setup.cfg
• PEP8
  • Naming (camelCase -> snake_case)
  • Check for PEP8 (flake8?) (also with GitHub Actions)
  • Docstring style
• Convert staticmethods into classmethods where possible
• Remove python 2 from README.md
• Remove sudo from README.md
• Replace deprecated aliases and functions in README.md (livejson.Database -> livejson.File)
• Wiki:
  • Fix image
  • Remove mentions of python 2
  • Remove uses of deprecated livejson.Database (replace with livejson.File)

@controversial, could you give your opinion on every "?"?

[controversial]

My thoughts on the items with question marks:

• Running mypy, tests, and coverage in GitHub actions is a great idea; pre-commit is more trouble than it’s worth though imo
• If you want to move tests from unittest to pytest that’s fine with me!
• Incrementing a new major version is necessary if we drop support for previously supported Python versions. I think it does make sense to remove deprecated features as part of this.
• I’m not personally a huge fan of autoformatters like Black; I’d rather just run a tool to check PEP8 compliance in a GitHub action than run Black

[controversial]

I went ahead and made the README updates you called out!

[GideonBear]

pre-commit is more trouble than it’s worth though imo

I personally love pre-commit(-ci), as it does both automatic and non-automatic things, requires no setup and also runs in CI. Simply adding something to the config file is enough to make it run; with GitHub Actions, you need to add specific things for each tool you want to run. GitHub actions is fine by me, just sharing my opinion as well. Lmk what you want, I'll try to set it up.

Do you want to port the setup.py file to setup.cfg or pyproject.toml? setup.py is officially deprecated AFAIK, pyproject.toml is the new "standard".

[controversial]

Moving from setup.py to pyproject.toml sounds like a good idea!

[GideonBear]

@controversial What development status would you consider livejson to be?
Development Status :: 1 - Planning
Development Status :: 2 - Pre-Alpha
Development Status :: 3 - Alpha
Development Status :: 4 - Beta
Development Status :: 5 - Production/Stable
Development Status :: 6 - Mature
Development Status :: 7 - Inactive

[GideonBear]

Seeing https://martin-thoma.com/software-development-stages/, I would say either production/stable or mature, maybe mature because it's pretty old, but it could also be production/stable as there are still a few (almost basic for this size) features missing (#13, #12 (or is that already implemented with the cache and context manager?) and #7) and it's really small.

[controversial]

I think production/stable sounds right.

[GideonBear]

Pip/setuptools is somehow adding both a livejson package and a livejson.py module...

[GideonBear]

Ah, seems like the build cache just needed to be cleared

[GideonBear]

Hi @controversial, I'm revisiting this, and I'm wondering why _initfile returns booleans, even though they're never used and not always returned? Can those be removed?