Add os.path.splitanchor()

Sometimes you need just the anchor of a path (the concatenation of drive & root). But currently, this is a bit clunky:

drive, root, _ = splitroot(path)
anchor = drive + root

This would be easier if we had a built-in function (like os.path.splitdrive()):

# ntpath.py
def splitanchor(p):
    drive, root, tail = splitroot(p)
    return drive + root, tail
# posixpath.py
def splitanchor(p):
    _, root, tail = splitroot(p)
    return root, tail  # Optimisation: The drive is always empty

Or even:

# posixpath.py
def splitanchor(p):
    p = os.fspath(p)
    sep = _get_sep(p)
    if p[:1] != sep:
        return p[:0], p
    elif p[1:2] != sep or p[2:3] == sep:
        return sep, p[1:]
    else:
        return p[:2], p[2:]

I have never needed this enough that writing this out explicitly wasn’t sufficient. (To be honest, I don’t recall ever needing this). Not every 3-line function needs to be a builtin.

3 Likes

This is a non-starter without evidence of a need for such a function. Please publish a PyPI package with your ideas for os.path; if it matures and becomes popular then you’ll have such evidence.

1 Like

OK, but what do you suggest I do here?

I modified _path_splitroot to return (drive, root, tail) instead of (anchor, tail).
But to avoid confusing variable naming, the diff here is larger than desired.

@Nineteendo will you look to publish a PyPI package rather than creating these forum threads, please?

2 Likes

For what kind of ideas is this category meant? Just such that they don’t get immediately rejected?

For viable proposals to be added to the stdlib, builtins and/or core language.

Viable is ofcourse subjective, but a few general guidelines for the kind of proposals you have been making:

  • The feature has real world, provable usecases, preferably in stdlib and a few major third party projects [1]
  • Not just a 3-line function that is trivial to implement in each project that needs it. Or show that C-level performance is really beneficial here.
  • A package on pypl that demonstrates a stable interface+behavior and that there are people out there who want to use this. This is somewhat optional if you can demonstrate an overwhelming amount of people reimplemeting this functionality themselves in their own code already.

  1. Features designed for small scripts might be hard to find there ↩︎

1 Like

Have a look at the linked thread. platformdirs is a PyPI package that is being considered for inclusion in the standard library. It’s only being considered because its popularity and maturity provide good evidence of a clear user need.

2 Likes

You now have at least 9 idea topics, none of which have strong support from core devs. You keep opening more instead of listening to this feedback. Stop doing that. It sounds like you’re writing a file browser. A “file-browser-utils” package would be a great place to start collecting all the behaviors you think are important enough for others to use.

6 Likes

OK, so it must have real world usecases and a stable interface.

11 (2 were moved to Python help). Though I think I should further investigate tuple support for string functions.

Yeah, I am writing a file manager in pure Python as you can’t have a file chooser on Android in a CLI application.

I am sympathetic to the idea of trying to get an idea added to CPython–as a longtime fan of the language, it would be a major personal achievement and point of pride. But the way to accomplish this is not “throw out a million ideas and see if any of them stick”. That is a recipe for burning people out because you are taking up a lot of their time.

It takes a long time and a lot of experience to understand what will actually be useful to other people, and the requirements for adding anything to such a popular language are very high. If you believe you have a good idea, make a package that implements it and see if others agree. Writing and maintaining a popular package is a lot of work, but it’s a lot more attainable than making an addition to the stdlib.

4 Likes

Unless I’m mistaken, isn’t pathlib.Path.anchor exactly what you need?

Yeah, but let’s just focus on making better suggestions. (I updated the topic to reflect that).

Please don;t. Let a topic be what it is; don’t rip out the top of a thread and try to replace it with something else, leaving everyone else’s posts orphanned.

OK, reverted.

I’m baffled by what you mean by this statement. Do you mean you’re withdrawing the proposal? The fact that you added “scrapped” to the title suggests so…

I shouldn’t have tried to give a brief statement.
pathlib.PurePath.anchor already achieves this goal. So there probably isn’t a need for a function in os.path.
This proposal wasn’t going anywhere, so it’s better to drop it.