Modernize the codebase

[bswck]

Feature description

Some general thoughts after flicking through the codebase, gathered in a "to-do":

• [ ] Drop legacy habits (stop using OrderedDict which was superseded by dict in 3.7 (technically 3.6) unless for popitem/move_to_end, stop using deprecated typing aliases)
• [ ] Improve logging (remove the entire untested logging boilerplate, probably could replace with a few lines of structlog/loguru, use deferred percent-style formatting instead of f-string based)
• [ ] Use typing.TYPE_CHECKING for types-only importing
• [ ] General quality (remove unnecessary casts, unnecessary parentheses)
• [ ] Definitely do not use regex for counting words in posts https://github.com/mkusz/mkdocs-publisher/blob/915913988311db9c94e92d18a094aab61ab9c59e/mkdocs_publisher/blog/parsers.py#L41-L61
• [ ] We really shouldn't be using importlib.resources in so many places

I can contribute to some of these when I find time, as well as find other rooms for improvement. Thanks for extending the capabilities of MkDocs!

Link

No response

Contact details

bartoszpiotrslawecki@gmail.com

[mkusz]

Hi @bswck and thanks for all the insights. Please take a look at my answers to yours comments:

1. OrderedDict will be removed in a near future when I will rewrite a whole blog plugin. The code base there is from a very early days of this entire repo when I was more learning how MkDocs works internally and it needs to be changed to allow for some other things to be added.OrderedDict will be removed in a near future when I will rewrite a whole blog plugin. The code base there is from a very early days of this entire repo when I was more learning how MkDocs works internally and it needs to be changed to allow for some other things to be added.
2. I have done some brief overview of proposed libs and I need to play with it a little bit. It seems like structlog can replace my code but I'm not fully sure if it will works like I wanted.
3. typing.TYPE_CHECKING wasn't aware of that trick, but it seems like this is only use full when you try to avoid circular references. In other cases id don't see benefits especially in context of using isort for imports sorting. What are other drawback of importing something just for type hinting?
4. In some cases some unnecessary parenthesise were added just to better "see" what is from where and group some things together. Without specific files/code lines is hard to guess what and why was added. Probably some of them where just not cleaned before push to the repo. As for cast, in most cases it's needed and used in config.py files when using option.SubConfig, so the proper type is preserved and pyright doesn't complain. I agree that in those files it can be removed. In other places, depends on the code context.
5. Entire function with regexp word counting is never used (it was left there for further use). I'm not sure why it shouldn't been used and you didn't proposed any better solution. In the future please put some additional explanation why this specific code is bad and what is proposed solution (like you did with logging).
6. I have checked and it seems like "importlib.resources" is used in resources.py and in some old blog files that will be rewritten (see point 1). Is there any other places? Files in dev that are more or less concepts and are never used by the plugin code?

Any way, thanks for all suggestions and I will definitely use most of them. If you can also elaborate a little bit more about point 5 and 6, it will helps a lot for me to better understand what and why is wrong.