My use case is if a given string can be created on the file system i.e. basically os.path.isreserved. And like I said the ability to never have to use os.path again in favor of pathlib.
Are you recommending here that a third party package is in order? If so I disagree because these are mutually exclusive concepts, otherwise the standard library would have no functions for dealing with Windows dev drives.
Which is actually a complicated request, that changes over time. Would you be satisfied by a function that is incorrect for some of your users (increasing amounts over time)?
I’m not sure which concepts are mutually exclusive? But the query for dev drives is a stable API provided by the OS that literally answers the question “is this a Dev Drive”. There is no such API for “is this a valid path” other than creating it, and certainly no API that works across platforms.
Can you please give an example of the failure case you’re imagining? I feel like I must be missing something fundamental here.
Prior to a particular Windows 10 update (I forget which), <anything>\aux was an invalid path. Since that update, it’s now valid. What would you like is_reserved(r"C:\Project\aux") to return?
I would like a function that represents the current state of Windows at the time of CPython release with a note/warning in the documentation as such. This is a broadly useful capability and a package on PyPI would have the same issue.
Then you can provide some examples of what it will be used for? That was my earlier question - we know what it did, but in order to understand how thoroughly we need to get the rules correct and how frequently/when they need to be updated, we need to understand what the function is going to be used for.
(Also bearing in mind that no function can substitute for safely handling “invalid path” errors when creating a file.)
This came about because I was trying to find a standard library example to offer this person PEP 639: Implement License-Expression and License-File by ewdurbin · Pull Request #828 · pypa/packaging · GitHub
The spiraling complexity then becomes the problem. LICENSE***FILE may be always invalid, but what about LICENSE:FILE (which is an invalid path, but a valid filename)? Or L:ICENSEFILE (valid path and filename, but probably unintended in both cases).
And strictly speaking, all path parsing is handled by the file system driver after the root elements, which means FAT32/NTFS/etc. rules don’t have to apply at all.
We can’t possibly capture all the rules in any authoritative way (let alone maintain them), and so using our function as an appeal to authority is going to be misleading and/or deceptive. We don’t want to be used for that purpose. So unfortunately, not a great example of how to use it.
Edit: This is your authority: Naming Files, Paths, and Namespaces - Win32 apps | Microsoft Learn Unfortunately, it’s much more a legal document than a specification, and there are escape clauses and ambiguities all over the place (plus it’s a little outdated).
I think we’ve veered slightly off of what I’m asking. As far as I understand (please correct me if I’m wrong) the os.path.isreserved function is not deprecated. If that is true, I want a method on pathlib.Path that simply redirects to that function so I don’t have to import os.path.
Or, are you actually advocating for that function being deprecated eventually as well?
As another concrete use case, consider the CI check PyTorch added: Update linter to validate file names are compatible across OSes (#78736) · pytorch/pytorch@d809310 · GitHub
I plan to introduce this at work (but tooling is in Python) because it’s not uncommon for folks to commit filenames which prevent Windows users from even cloning.
Yeah, it’s supposed to be going as well (or at least actively discouraged, and marked as legacy, so that it’s not confused for a good way to verify paths).
I’m just going to note here that I agree with @ofek - this function has been useful in many practical contexts for many years, and the arguments for deprecating it seem to revolve around the fact that it’s not perfect.
It may not be perfect, but it’s been good enough for plenty of people for a long time. What’s changed?
To be clear, this has always been my view, I kept out of the discussion mainly because I didn’t have the energy to fight over the “practicality vs purity” principle for a function which I, personally, don’t really care about (my personal projects are all Windows-only, and a quick source code search shows that pip doesn’t use isreserved anywhere…)
Perhaps it should lookup the Windows version at runtime and reflect whatever semantics that version implements, or it could return true if any Windows version supported by the given Python version treats the input as an invalid path.
Granted, the function semantics might be underdefined currently, but that’s an opportunity to make them more precise rather than deprecate the functionality altogether 
(this could also be governed by a new optional keyword parameter, though that’s more work of course)
There are a lot of ways such a function would be inaccurate, even with a version lookup. What happens if the path points to a network file server?
I’d rather this continue to live only in ntpath, then people can import it when they know their concerns relate to that. Placing it on pathlib.PurePath implies behavior that cannot be reasonably implemented, and as much as documentation can help, expectations about things intended to be cross platform being violated with a quick note in docs isn’t a good developer experience.
The standard library already offers functions that are effectively no-ops on certain systems or are best effort like symbolic links on Windows.
Steve even mentioned this before Discuss PEP 662: Editable installs via virtual wheels - #97 by steve.dower
Yeah, one of my other proposals was to deprecate the current behaviour so we can migrate it to some agreed upon representative behaviour that isn’t quite “will this be valid on the other platform” but is useful enough. It came up originally because people were complaining about it being incorrect, and then again when it was proposed to make it more accessible and more “official” (I was happy to leave it as an obscure wart).
If you’re on the platform where you want to check the path, it’s much easier to use realpath or some other way to call into the OS itself. The strongest use case we came up with was to validate paths on a different OS, but in this case there is no way to know what the rules are.
Sure, but they’re no-ops that don’t matter, whereas a validation function that always lies does matter. Our symlink function works fine on Windows, FWIW, and you’ll get exactly the behaviour that your OS configuration provides: a symlink, or an error. Making is_reserved raise an error is a breaking change, which we can do, but it needs the deprecation period first, and it needs a fully specified specification, not just a “whatever the OS would do” specification.
Are you open to improvements to the function and removal of the deprecation (or at least a rename)? If so, what would be the concrete next steps? I’m not a core developer so I don’t know the process or even who “owns” this decision honestly.
is_reserved() is a method of PurePath rather than Path, so we probably can’t interrogate the Windows version while the method exists - what would we do on POSIX?
However, if we follow the current plan, PurePath.is_reserved() will be removed in 3.15. At that point we’d be more free to adjust of os.path.isreserved(), and perhaps vary its behaviour by the Windows version.
Not undirected improvements. The first step is to fully specify what the behaviour should be, and if there’s agreement around that and a way to migrate without needing a deprecation then the deprecation could be removed. But I suspect it needs deprecation. (It certainly needs deprecation for a rename.)
Making a precise definition of what constitutes a “reserved” path, independent from any OS definitions (i.e. it should list any particular names, not say something like “and all the names forbidden by the OS”). And we would need it for both ntpath and posixpath.
Right now, I “own” the decision, but only because I’ve got the strongest opinion (and hopefully a little bit of respect) If there’s significant argument, then the process will become a PEP and the steering council will eventually own the decision. (Or maybe we take the two proposed plans to the SC and see if they’ll endorse one over the other, but most likely they’ll want two fleshed out plans i.e. two PEPs.)