No, we don’t — one is for assembling paths, one for generic strings. 

And in recent versions, there is a new totally different way to assemble paths.

Also: the primary use cases are diffferent — when I use os.path.join(), I usually have the components in variables or literals, so the *args convention is most natural. When I am assembling text with str.join() I usually have the parts in an iterable, so that is the most natural.

And besides, Python (necessarily) has some inconsistencies — we don’t need to correct them all. 

There have been multiple changes to str.join() discussed in this thread. Mostly orthogonal to each other. If anyone wants to move them forward, I suggest you be clear about which you are advocating for.

1) that there be a join() method on lusts ( or sequences) — frankly, I think that’s a non-starter, I wouldn’t waste any more time on it.

2) that str.join() take multiple positional arguments to join (similar to os.path.join) — This could probably be added without much disruption, so if you really want it, make your case. I personally don’t think it’s worth it — it would make the API more confusing, with little gain.

3) that str.join() (or some new method/function) “stringify” (probably by calling str() ) the items so that non strings could be joined in one call — we’ve had a fair bit of discussion on this one, and given Python’s strong typing and the many ways one might want to convert an arbitrary type to a string, this seems like a bad idea. Particularly bad to add to str.join()

(Or was “stringify” supposed to only do the string conversion, not the joining? If so, even more pointless)

Any others?

-CHB