require python 3.10, start to test on 3.14 and 3.14-free-threaded

[Carreau]

No description provided.

[Carreau]

@minrk I see you recently removed and readded Python 3.8, would you be or to drop 3.8, and bump version number of 6.0 ?

[Carreau]

And I don't know what to do with the fialures, asyncio.set_event_loop_policy is anyway deprecated and will be removed in 3.16.

[minrk]

That was to get a security fix out without changing supported Python versions, fine to drop 3.8 and 3.9 now.

[Carreau]

Am I crazy? Mypy complains about (simplified):

import sys

def unreach() -> str:
    if sys.platform == "darwin":
        return "OSX"
    elif sys.platform == "win32":
        return "windows"
    # ok if in an else black
    return "other" # foo.py:10: error: Statement is unreachable  [unreachable]

But if I put an else, ruff complains for unnecessary else...

[minrk]

Blarg, yeah, mypy's obviously wrong. I don't have a lot of patience for incorrect type checkers, so liberally ignoring their failures is okay with me.

For ruff, I think it's because there's a return you don't need elif you can use plain if:

if a:
    return a
if b: # don't need elif because of return a
    return b

ruff check --fix

would resolve that, I think

[minrk]

For the event loop policy, we could consider just removing it. pyzmq now works with proactor if tornado is available (via an additional thread), so if we require tornado 6.1, all should be okay (if less efficient than selector).

We could also just ignore the deprecation warning. The code will still work (i.e. it will do nothing) after policies are removed, because they are protected by a check for an ImportError.

I'm still incredibly frustrated that asyncio folks decided proactor was ready to be the default when it still lacks basic functionality of all other loops that needs to be worked around with threads.

[Carreau]

Rhaa mypy bug seem to be known.

[minrk]

my inclination: suppress the deprecation warning for now, then we can propose a new way to do it without policies (I think an init_ioloop that instantiates a loop directly will work) in its own PR.

[Carreau]

I think I'll be in favor of ignoring the warnings only python 3.14, and revisit for 3.15

[Carreau]

All passing, and please don't squash I properly cleaned-up each commit.

[Carreau]

Current version is 5.8.1, once this is merged, I suggest we bump version, and release soon. I'll suggest 2 new possible version numbers in two separate comments. Please upvote your peference.

[Carreau]

5.9, nothing specific but did drop 3.10 (and 3.9) and there was no release since 3.9 drops.

[Carreau]

6.0, this will let us do some cleanups in particular this deprecation warning:

else:
    deprecation(
        "Jupyter is migrating its paths to use standard platformdirs\n"
        "given by the platformdirs library.  To remove this warning and\n"
        "see the appropriate new directories, set the environment variable\n"
        "`JUPYTER_PLATFORM_DIRS=1` and then run `jupyter --paths`.\n"
        "The use of platformdirs will be the default in `jupyter_core` v6"
    )

EDIT: version published Nov 9 2022

[Carreau]

We can also do 5.9, and do 6.0 in a month or so with all the cleanup we want.

[minrk]

I think we can do 5.9 with these changes, I don't have a problem with dropping Python versions on minor releases, the tooling handles that well enough.

I haven't pulled the trigger on completing the platformdirs change because I think it's not complete enough - #309 I don't think we should start the deprecation clock until we have had migration in place for quite some time, which we still don't. At this point, I agree with @ivanov that we should remove the deprecation warning and stop telling people the default is going to change.

[minrk]

#447 removes the deprecation warning

[Carreau]

Thanks !

[minrk]

draft release: https://github.com/jupyter/jupyter_core/releases/tag/untagged-9833f440530aecf4ad1b ready to go?

[Darshan808]

Suggested change

	DeprecationWarning,
	category=DeprecationWarning,

This is causing TypeError in downstream package jupyterlab_server when testing on Python 3.14 on Windows.
CC: @Carreau

[Darshan808]

Opened #449

[Carreau]

5.9 is already out.