Consider dropping Python 4 upper bound

[hauntsaninja]

Version capping makes it the case that isort definitely won't work with an eventual Python 4. If not for the cap, since Python 4 is unlikely to be extremely disruptive (especially to pure Python applications), isort would likely continue to work.

My interest here is that any poetry projects that use isort (even just as a dev dependency) also end up needing to cap Python versions, causing these pessimistic assumptions to proliferate.

This section of https://iscinumpy.dev/post/bound-version-constraints/#pinning-the-python-version-is-special contains more details.

Would you be willing to entertain a PR that drops the upper bound here?

isort/pyproject.toml

Line 43 in 12cc5fb

python = ">=3.6.2,<4.0"

[juhannc]

Python 4 unlikely to happen according to Guido van Rossum himself so I don't think it will be a problem.
It's probably better to watch out for new releases and see if and how they break isort.

[hauntsaninja]

Yes, dropping the upper bound is very much in line with the philosophy "watch out for new releases and see if and how they break isort", treating 4 like any other release instead of pessimistically assuming that it will break isort :-)

[staticdev]

@timothycrosley could you please create a new release of isort (and example plugins) with the changes we merged here #1878? This will enable me to create a new PR to solve this.

[sisp]

Duplicate of #1945.

[staticdev]

@hauntsaninja fixed on 5.11.0.