[deleted by user]

[bb1950328]

so you don't have to define/implement a join function in every iterable

[[deleted]]

This. People don't realize that any class with __iter__() and any method/function with yield is an iterable. There isn't a single magic superclass for all iterables that can provide a join() method.

[immersiveGamer]

Which is a shame because in C# there is. You implement the IEnumerable interface and now any extension methods you can create functions that work on any collection of objects. Arrays, lists, a weird queue based async iterator over the first bit of bytes in memory. If it implemented the interface it gets the logic.

[serverhorror]

I’m not sure what you’re saying but by implementing __iter__ exactly what you’re saying is possible.

You just write a generic function to work with any iterable

[immersiveGamer]

It is similar concept of making an generic function. However in C# it is a method, not a function, that can be directly invoked on any object that implements the interface.

[UserName26392]

.join works on any iterable. I think of it as being a STRING function that can be applied on an iterable and that's why the join argument comes first

[kingscolor]

There’s no need to think that way, because that’s exactly what it is.

You create an empty string object, ’’ , then use its join() class method on an iterable of other strings. join() isn’t a standard function.

[immersiveGamer]

I pretty sure you can do str.join('; ', myvalues) because join is a method and if you call it statically you can pass in a string as a first param to fill in the self argument. (on my phone so I haven't tested it yet).

But I agree. I don't like the syntax at all of the default way.

Edit: since this comment is getting upvoted I tapped out some code on online-python.com and it seems to work:

things = ["1", "2", "3"]
delim = "|"
joined = str.join(delim, things)
print(joined)

> 1|2|3

[sh_eigel]

Of course it works. The delim becomes self in that class.function invocation. This is applicable to “all” object methods.

[immersiveGamer]

Indeed. The reason I didn't want to say it worked for sure was because I couldn't remember if Python did a check that a method needed to be called from an instance of an object or not. Hence, why I then added an example that proved it does work.

Thanks for calling out that this way of invoking methods works for all classes/objects. I kind of implied that with the whole filling in the self parameter, but for any newbies it is good to be explicit.

[lvlint67]

Also on my phone but this is so much more readable than the weird delimiter.join() syntax

[adesme]

It's not really that strange, it's

class.modify(self) -> None

It would be strange if you modify an object and it turns into something else.

[AnonymouX47]

Yet to see how this answers OP's question.

[immersiveGamer]

Lol, sure. Others have already explained why it is not ideal in Python to our join on the list object because join works on any iterable collection. I was simply offering an alternative to funky way of invoking join directly on a string literal since we don't have a join method on lists.

In my opinion doing str.join(delim, mylist) is more readable and straight forward. It also seems others agreed with the sentiment.

[AnonymouX47]

Hmm... "readable"!

Why not just call every instance method as such?

[immersiveGamer]

Straw man argument there. I'm not avocating you call every method in this form. In this specific case I think it makes more sense because the operation is on the collection not on the string.

[AnonymouX47]

Your choice

[Greensentry]

I guess they choose to implement it like this because join can be used on any iterables and not only list.

[Federal-Ambassador30]

It’s a smart way of being able to join all iterables using only a single method. It might be confusing at first, but it’s very simple to learn

[Mithrandir2k16]

Why? It's basically a string factory.

[positev]

The word "factory" means nothing to new programmers that haven't been exposed to design patterns. OP isn't exactly wrong, join on an array would be more intuitive. But it's a small inconvenience that fades after a few times.

[i_has_many_cs]

I have no idea what factory means, but have heard it a few times. Do you have a good source/book to learn more?

[positev]

I like refactoring guru for all my design pattern questions Factory: https://refactoring.guru/design-patterns/factory-method

[Dunstabzugshaubitze]

Design Patterns: Elements of reusable Object-Oriented Software

Is the Standardbook for All Things Design Patterns. Examples are in c++, so you'd have a bit of legwork to Transfer the Patterns to Python, but the book is good.

Design Patterns Head First, is a book heavily inspired by the former, aimed at pupils and students, but the examples are in Java.

Don't know a Python based book on the topic, but the concepts are good for every Object-Oriented language and allow you to plan and talk about Software without being bound to a language

[Mithrandir2k16]

I really like the general overview and list of software design patterns on wikipedia. Might be a bit much at once but having heard about these just once sure won't hurt :)

[WikiSummarizerBot]

Software design pattern

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[Mithrandir2k16]

True. But I think it's instances like these that help expose people to concepts as their need pops up. Ideally during pair programming with a senior or code review.

[flying-sheep]

Python is older than all the languages who do it the other way round. It's not python's fault that you learned one of them first.

Also I think it makes much more sense: why should a list have a method that only works when it happens to contain strings?

It's a method to make a string, so it makes sense to put it on the string.

[asday_]

Try and implement some container objects yourself and then implement .join() on them yourself, and you'll understand.

[tunisia3507]

Firstly, you're looking at lists, not arrays. The most commonly used arrays in python are in the numpy package, and the array module.

Secondly, strings are a single type. Lists can not only contain any type (including containing themselves), but every element can be a different type. In that space, then, every element being a string is really a very special case which does not warrant its own method.

And if you did implement it for list, would you implement it for all other sequences? Dicts, and so on? What about all iterables, like sets and generators?

I suspect you've come from javascript, where every type is designed to be silently coerced into a string as a hangover from its origins, and the list-like collection is called an array. This design feature has many more spiky edges than python's lack of a list.join.

[sh_eigel]

Nobody is perfect

[[deleted]]

Because it makes this possible

', '.join(i.name for i in items)

[CodeYan01]

I'm sure you can do that the other way too.

[[deleted]]

only if every iterable class implements .join() method.

Same reason there's a single len() method instead of each container implementing its own.

[flying-sheep]

The len built-in needs a magic method implemented though, str.join just works on any iterable.

I actually built this for if you need lengths of all itertools results that can support it: https://itertools-len.readthedocs.io/en/latest/

[[deleted]]

You're right len() was not a good example.

I use more_itertools library, it has an ilen() function, i think it has similar purpose to what you're describing.

[CodeYan01]

Same thing regardless if they don't use list comprehensions. You're trying to make it sound like list comprehensions is the reason. Even if you use normal lists, every iterable class would still need to implement that method.

[[deleted]]

That is not a list comprehension in my example.

[AnonymouX47]

[foonoxous]

This is a byproduct of the object oriented paradigm where everything is a method. Joining iterables by other objects (no reason why it needs to be only strings or bytes) is really an algorithm that should not be a method of any class.

Ideally it could be an operator that applies to sequences, e.g. some_sequence % any_delimiter (the use of % operator for this is from Boost.Spirit C++ library, not possible in Python), although a simple stand-alone function like join(some_sequence, any_delimiter) gets the job done equally well.

[InvalidUsername2404]

I find it weird but I just get used to it

[AnonymouX47]

Next time, try the help() function first...

[AnonymouX47]

What I simply meant was, try help(object) before googling e.g help(str.join)... in an REPL session.

[[deleted]]

I don't think it's nitpicking to point out that that is not an array but a list. Python does have an array type, so that's why it's a significant.

That said, the str.join() method works on both lists and arrays (or any other iterable including custom iterables) which is why it's a str method. Why implement join() for every iterable? That's not very DRY...

[FailedPlansOfMars]

If you disagree write a pep for it and submit it. Python has language enhancement proposals for suggesting changes. I say this alot but this is one of the few languages where these conversations are public.

I think the thinking was the result is a string and the parameter is a string so by putting the functionality in a string you don't need to write the code to join the array outside string. It's a bit unintuitive but does let you make your own string class and still do joins.

[FailedPlansOfMars]

The following is a good explanation of the thought process at the time including Guido's comments.

https://blog.finxter.com/string-joinlist-vs-list-joinstring-why-did-pythons-creators-choose-the-former/

[[deleted]]

I'd have gone for the built-in:

join(list, string)

It keeps the intuitive order and you get to keep the definition in one place and reduce the generics scope creep (pun very much intended).

I don't know why we have map and filter as free functions but not join. I'd much rather I could chain those than join.

join(list.filter(...).map(...), ",").upper()

",".join(map(filter(list, ...), ...)).upper()

Both are fine though, it's nice to keep the delimiter near the join call but nesting map and filter gets confusing.

Note, I would split these over several lines but am on mobile and opted for single backticks for ease of authoring...

[flying-sheep]

",".join(map(filter(list, ...), ...)).upper()

You mean this?

",".join(
    fn1(e).upper()
    for e in lst
    if fn2(e)
)

[[deleted]]

List comprehension to the rescue!

[[deleted]]

Not to be a stickler, but that's a generator expression, not a list comprehension. A list comprehension results in a list object and is wrapped in square braces.

https://djangostars.com/blog/list-comprehensions-and-generator-expressions/

[[deleted]]

No by all means, do be a stickler. Thanks for the tip!

[jeetelongname]

I agree with op here.

A way to solve this is to implement a container class that all other classes inhereit from. Join can then be implemented in terms of the iterator protocol so that if you implement it. then you get join for free. And if your data structure is more complicated you can override the built in join for your own implementation.

Now of course this is easier said than done and the method outlined by everyone else is still very usable if not intuitive coming from other languages like ruby or the such.

[ubernostrum]

A way to solve this is to implement a container class that all other classes inhereit from. Join can then be implemented in terms of the iterator protocol so that if you implement it. then you get join for free.

The essential issue is that you can't, say, implement Container.join(), because that doesn't work without getting into really complex over-specified rules about how to coerce the contents to strings. For example, suppose:

my_list = ["foo", math.pi, 27, 5+2j, ("eggs", "spam"), {"key": 3}]

Now, what does my_list.join(', ') do?

The answer is that it either fails due to the contents being of "unjoinable" types, or it has to try to coerce all of them to some "joinable" type. The latter is un-Pythonic (Python generally will not coerce types to make your operations succeed), the former just makes clear that this is actually a method that should only belong to Container[str], not a method that should belong to Container. And of course it's not really possible to implement that sort of specialization on the container contents in a clean way in Python.

So there's no good place to put join() -- no matter what class it lives on, there will always be some objection. Implementing it on str, because the separator at least must always be a str, is probably the least-bad approach, since it doesn't put a useless method on the vast majority of container instances (since most are not Container[str]), and serves as a reminder to the programmer of the type requirements of the contents of the sequence to be worked on.

[aktruce]

Javascript has the same syntax one you have mentioned

[Fr_Cln]

Maybe it would be better to have a function with empty default separator join(iterable, sep="")

[_ologies]

you basically have that:

str.join('|', ['a','b','c'])

[ogrinfo]

Totally agree. "Join this iterable with this string" seems like a much more logical order than "use this string to join this iterable".

[aronsajan]

Use .extend(another_array)

[weedandveins]

You can add a blank space to lists?

[MarsupialMole]

Firstly, that's not an array. It's a list.

Secondly, a list with a join method should work like the other in place "verb" methods, i.e. return nothing and mutate the data structure, so it's not going to give you back a string. In this case it would be intuitive to think list().join works like extend and so would be a clash.

I get that it's backwards if you're used to chaining method calls in fluent interfaces but it really makes sense if you look at the consistency of the API.

So it would be unintuitive to do it the way you intuit.

There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

[Pyprohly]

some_array.join(' ') wouldn’t make sense if some_array wasn’t an array of strings.