Thanks for the review!

I'm worried about the covariant returns that are lacking but I don't remember if it's allowed to have a method withdef f(self: T_co) -> T_co: ...

Could you explain what you mean specifically?_JoinablePath is not generic so I don't see how the covariant typevars would play a role here.

Could you explain what you mean specifically

I should avoid reviewing while doing C++. Invariance is sufficient here, my bad.

BTW@ap--, this is awesome! Thanks so much!! And thanks also@picnixz! I appreciate your scrutiny :)

@barneygale@picnixz I made all changes as suggested☺️

I am now wondering if it wouldn't be better to just usetyping.Self and rely on typing_extensions inpathlib-abc. I think it would make this module a lot easier to parse visually.

That's a much better plan - please feel free.

What do you chaps think aboutWritablePath.write_text() andwrite_bytes() returning anint? It might be a pain to implement for users who override those methods. We could make that apathlib.Path-exclusive feature perhaps?

What do you chaps think aboutWritablePath.write_text() andwrite_bytes() returning anint? It might be a pain to implement for users who override those methods.

Given that__open_wb__ is abstract, and write_text and write_bytes ship default implementations, I don't think they need to be simplified.

Let's keep theint return values forwrite_text() andwrite_bytes() - thanks both.

Just noticed the discussion in#130798: I'm happy to recreate this PR in typeshed if needed.

No-one onthe forum has objected yet, so I suspect we're fine to proceed with type hints here. But let's wait a few more days before we merge, just in case someone replies on the forum with an objection.

Sounds good! Three things were brought up on DPO that I think we should address before merging:

1. "Annotations that are not checked by CI should not be added to any project, [...]"

I fully agree with that one. In universal-pathlib I've been usinghttps://github.com/typeddjango/pytest-mypy-plugins to run tests against the type annotations of the UPath interface(seehere, with an example runhere), to make sure I don't accidentally change the return type of some method to Any (which happened before I had the CI tests in place). The problem is of course that this is enabled through a third party pytest plugin. My guess is for cpython we'd have to roll our own relying on unittest and mypy only.

2. "Type checkers themselves don’t use stdlib source annotations, they use typeshed"

We need to investigate if there's an issue with actually checking the stdlibpathlib.types annotations with mypy because it might just rely on typeshed? If that's the case, and we'd need to duplicate annotations in typeshed, there's not really a benefit in having the annotations here, because either way we'd have to carry the maintenance burden of keeping the two places in sync.

3. "I think we should only use simple annotations (some of the mindblowing generic type stuff obfuscates code rather than clarifying it)."

I also agree with this one, and I wonder if we should add a comment to.copy and.copy_into that type annotations for kwargs will be added once it is possible to write these in an intuitive and concise way. (== once intersection types are available and ParamSpec supports binding only kwargs)

Hi@barneygale

I have time this week to continue with this. Before I start with working on a solution for testing I wanted to run the following idea by you: Currentlypathlib-abc pulls frompathlib.types to sync development. I think if this would be inverted, most of the issues with "type annotations in the stdlib" and testing would go away:

• pathlib-abc would be fully type annotated and the types could be tested with whatever method is convenient
• every timepathlib-abc code is synced to the stdlib, the type annotations would be stripped frompathlib.types and synced as stubs totypeshed

But this will probably introduce some friction with feature development and refactoring for pathlib, because things live in two different locations now... Anyways, let me know what you think☺️(Also let me know if this discussion should be moved somewhere else)

For now, I'll ask in typeshed how testing would best be established in the current scenario.

Have a great week,
Andreas 😃

Hi Andreas!

So far I've avoided making pathlib-abc anupstream project of CPython, because I worry I'd be bypassing the usual CPython development process. I'd end up making cpython PRs like "Backport changes from pathlib-abc 0.9.8" where core devs might feel less able to request changes, given things have already landed upstream. Maybe it's not a big deal...

I don't think it's necessary to runmypy in the CPython CI if we run it in the pathlib-abc CI. There will be a delay between things landing in CPython and it flagging in the pathlib-abc backport CI, but I suspect that's OK for the time being.

pathlib.types isn't the only stdlib module with type annotations -wsgiref.types is another example. In that case typeshed appears to copy the type annotations from the stdlib. Would that work forpathlib.types too?

Hope you're having an excellent week also :D

All commit authors signed the Contributor License Agreement.

removing runtime dependency on typing

I started to remove the runtime typing imports frompathlib.types but there is a blocking issue, that I ran into. There are two runtime_checkable protocols inpathlib.types:_PathParser andPathInfo. It is possible to remove the dependency ontyping.Protocol andtyping.runtime_checkable forPathInfo (like forio.Reader) as shown here:

classPathInfo(metaclass=ABCMeta):"""Protocol for path info objects, which support querying the file type.    Methods may return cached results.    """@abstractmethoddefexists(self,*,follow_symlinks:bool=True)->bool: ...@abstractmethoddefis_dir(self,*,follow_symlinks:bool=True)->bool: ...@abstractmethoddefis_file(self,*,follow_symlinks:bool=True)->bool: ...@abstractmethoddefis_symlink(self)->bool: ...@classmethoddef__subclasshook__(cls,C):ifclsisPathInfo:return_check_methods(C,"exists","is_dir","is_file","is_symlink")returnNotImplemented

The trick above does not work for_PathParser though. The reason is (1) that_PathParser has an Optionalaltsep attribute and_collections_abc._check_methods interprets attributes that are None as missing. And (2) the_PathParser Protocol should succeed for anisinstance(posixpath, _PathParser) check, which the__subclasshook__ trick does not cover for modules.

Maybe it's ultimately not necessary forisinstance(posixpath, _PathParser) andisinstance(ntpath, _PathParser) to evaluate to True, since users would implement their custom parsers as classes anyways?

type checking inMisc/mypy

So I now added pathlib toMisc/mypy to start type checking the pathlib code in CPython similar to_pyrepl (thanks core.py for the pointer☺️ ) There are a few issues with that though, for which it would be great to get feedback.

(1) I followed the same pattern as_pyrepl did with including a custommypy.ini in pathlib and symlinking, but it seems that theglob imports bleed through to the_pyrepl checks, unless I explicitlytype: ignore[attr-defined]e596130 the import inpathlib/__init__.py. Is there a way to prevent this?

(2) One mypy error showed upLib/pathlib/__init__.py:57: error: Missing type parameters for generic type "Sequence" [type-arg] which I tried fixing with

class_PathParents[T:PurePath](Sequence[T]):    ...

But it crashes mypy. So I added the (wrong) workaround in7cd07f1
I think this is a bug in mypy, and I'll report this there asap. I am wondering if I should wait for this to be fixed instead in mypy instead of the workaround commit I applied here.