drop py35 and py36

[trim21]

drop python 35 and python 36 will make is possible to add inline typing, then we can commpile it with cython or mypyc.

[Delgan]

Thanks @trim21 for your hard work here. I haven't tested how well type Mypyc and Cython leverage type hints. If it could indeed lead to faster execution, it would be a very compelling reason to add inline typing to the codebase.

However, I'm still in favor of maintaining support for Python 3.5. Even though it reached "End-of-life" status, these versions are still in-use and I'd like to continue releasing bug fixes and enhancements for them.

Is this a major obstacle to adding type hints, despite the existence of backporting libraries like typing_extensions?

[trim21]

Is this a major obstacle to adding type hints, despite the existence of backporting libraries like typing_extensions?

Normally I wouldn't recommand to drop old python support for typing because we already have typing_extensions, but py35 and py36 are special.

Inline type annotation are new syntax, not new stdlib function/variable can be backported by library.

Mypyc and Cython

they doesn't work will without typing message....

[Delgan]

Inline type annotation are new syntax, not new stdlib function/variable can be backported by library.

It the "inline type annotation" you're referring to that of PEP 484?
Except if I'm missing something, it is compatible with Python 3.5

The following code is valid syntax:

def foo(a: int, b: int) -> int:
  d: int = 4
  return a + b + d
  
print(foo(3, 2))

[trim21]

Inline type annotation are new syntax, not new stdlib function/variable can be backported by library.

It the "inline type annotation" you're referring to that of PEP 484? Except if I'm missing something, it is compatible with Python 3.5

The following code is valid syntax:

def foo(a: int, b: int) -> int:
  d: int = 4
  return a + b + d
  
print(foo(3, 2))

~/.pyenv/versions/3.5.10/bin/python a.py
  File "a.py", line 2
    d: int = 4
     ^
SyntaxError: invalid syntax

I think it need at least py36

[Delgan]

Apologies. I used an online interpreter that claims to be on version 3.5.2 but visibly is not.

[trim21]

sorry, I didn't rember it correctly. Maybe we do not need to drop python36

[Tsafaras]

This is still valid, even in Python 3.13

May I ask what the scope of your PR is?
Are you simply trying to drop support for Python 3.5 and 3.6, or are you also resolving deprecated code and taking advantage of new syntax?

[trim21]

This diff is generated by pyupgrade

I'm tring to resolving deprecated code and taking advantage of new syntax. and try add mypyc or cython on it to make it faster. but py35 is just too old to do that.

[trim21]

This PR now have conflicts, I'll resolve it when we decide to drop there 2 versions.

[TurtleOrangina]

Just to add my two cents here: I had my first ever contact with the loguru code base yesterday (I posted a PR), and I was astounded to see that there is effort put into python-3.5 support! In 3 weeks time, python 3.9 will reach end-of-life, so python-3.5 is really very far out there.

Not being allowed to add type-hints to my code (and hence mypy being mostly useless) was really a throw-back to the past when I wrote my PR. In theory, being as backwards compatible and flexible as possible is a good thing for a library, but allowing for a higher code quality within the library is also a good thing for all users - not to mention makes maintenance and contributions easier.

You can even see that assisting tools and dependencies do not support such old python versions anymore, e.g.

# from pyproject.toml:
# Actually, we should target Python 3.5, but Ruff does not support it.
target-version = "py37"

# from contributing.rst
Prefer using a relatively recent Python version as some dependencies required for development may have dropped support for oldest Python versions.

Also keep in mind, that even if loguru drops support for older python versions, everybody can still use loguru on python-3.5 just fine - you will just not be able to update to the newest version anymore. The last python-3.5 bugfix release was over 5 years ago, so if you run this version you are flirting with the devil in many more significant ways than not having the latest loguru version ;).

[Delgan]

Thanks for your input, @TurtleOrangina.

I understand and regret that this complicates contributing to Loguru. In my view, it was a necessary trade-off to maximize accessibility for users.

Now, at this point, it is true that Python 3.5 is far outdated and most certainly no longer needed by Loguru users. For the sake of correctness and peace of mind, I would still prefer to first fix a few remaining bugs and stabilize the Loguru API before considering the removal of Python 3.5 and aligning with the EOLs of subsequent versions. This will unlock the possibility of drastically modernizing the codebase far beyond simply removing 3.5 support. The underlying problem is that I still haven't managed to complete the full implementation of the Loguru API.

[TurtleOrangina]

No problem @Delgan - i can understand that other things are more important - but it doesn't necessarily have to be too much work for you to do this - as long as I know that it is something worth doing, I can post a PR that drops older python versions for the current state of loguru ;). Just tell me what versions you want me to drop and I will create the PR. It might make sense with the next loguru version (0.8) containing breaking changes anyhow?

[Delgan]

Thanks for the offer, @TurtleOrangina, but again I prefer to wait a bit longer before dropping these versions. I am certainly being over-cautious, but I want the changes planned for version 0.8 to also be present in older versions of Python as well, ensuring API consistency and carrying over the relevant bug fixes. In particular, I am presently working on a major refactoring that promises better multiprocessing compatibility, and I don't want it to be exclusive to the most recent versions of Python.