> I'm just saying assembling strings is
a common programing task and that we have two different methods with
the same name and inconsistent signatures

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?

Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython