1

Is there any faster approach to split elements in a list and also include the split element. If an element is a word, there is no need to add the split elements again. My current working solution is below and just want an improvement if any

final_list = []
lists = ["the", "I am there", "call me"]
for l in lists:
    splitted_l = l.split()
    if len(splitted_l) == 1:
        final_list.append(splitted_l)
    else:
        splitted_l.append(l)
        final_list.append(splitted_l)
        
print(final_list)

---------
output = [['the'], ['I', 'am', 'there', 'I am there'], ['call', 'me', 'call me']]
research comp5800
  • 15
  • 5
  • I’m voting to close this question because it is better suited for https://codereview.stackexchange.com/ – Abhijit Sarkar Mar 24 '23 at 17:58
  • 1
    @AbhijitSarkar While this may be on-topic on CR, in the future, please don't use the existence of the Code Review site as a reason to close a question. Evaluate the request and use a reason like *Needs more focus*, *primarily opinion-based*, etc. Then you can mention to the OP that it can be posted on Code Review if it is [on-topic](https://codereview.stackexchange.com/help/on-topic). Please see [_Does being on-topic at another Stack Exchange site automatically make a question off-topic for Stack Overflow?_](https://meta.stackoverflow.com/q/287400/1575353) – Sᴀᴍ Onᴇᴌᴀ Mar 24 '23 at 18:05

1 Answers1

-1

This may be faster, though I didn't benchmark it:

final_list = []
lists = ["the", "I am there", "call me"]

final_list = [x.split() + [x] if len(x.split()) > 1 else [x] for x in lists]

It uses a list comprehension, which would be a potential source of speed boost. On the other hand, it splits twice which is not ideal but it gives a way to differentiate single words from multiple words.

Following this post it is clear that in many cases a list comprehension would be slightly slower than a loop. It is more concise though and I personally would choose it over a loop. I recommend you test both approaches with your actual problem and see if one outperforms another. If neither does, I would keep the list comprehension.

atru
  • 4,699
  • 2
  • 18
  • 19
  • 1
    I'm a big skeptic of unsubstantiated claims like "_This should be faster_". Is it, really? If yes, by how much? – Abhijit Sarkar Mar 24 '23 at 17:56
  • I cannot give this person a proper benchmark without knowing more details on what are they planning to do. However, I have recently answered a question where the OP clearly shown that LC was much faster than a regular loop (which can be explained by its mechanics). – atru Mar 24 '23 at 17:58
  • That's why this question is not a good fit for Stackoverflow. OP has a working solution and wants to make it faster. – Abhijit Sarkar Mar 24 '23 at 17:59
  • Well, I disagree so I will just keep it here. – atru Mar 24 '23 at 17:59
  • What's that other question where LC was "much" faster? In this case I doubt it, especially due to the double splits. – Kelly Bundy Mar 24 '23 at 20:21
  • I scratch that, it was a different problem (not an LC). Following a bunch of posts, LCs seem to be generally the same or even slower than for loops. There are however exceptions, one documented [here](https://stackoverflow.com/a/57158292/2763915). I will relax my statment but I still think that this is a more concise alternative that deserves its place here. It also may be faster - something the OP will verify on their own when they get to their actual problem. – atru Mar 24 '23 at 22:01
  • LCs are generally a bit faster than loops if they do the same stuff and just differ by how they append to the list. I have never seen or been able to construct an equivalent LC that was *slower*, and I'd be very interested to see that. I suspect it wasn't equivalent but did do more... – Kelly Bundy Mar 24 '23 at 22:11
  • Good to know. I use LC for clarity and convenience. In my case when I actually need speed that usually means that switching from an LC to a loop won't save me. Or the other way around. So I never asked myself if LCs are really faster. I agree with many operations that are the same, that is much real. The post, and a couple others, as well as one blog I found made me wonder if there really is any substantial difference between the two. – atru Mar 24 '23 at 22:15
  • My point is the the OP should benchmark it for their own needs. If its the same, I would still go with LC - many less lines of code and still clear. – atru Mar 24 '23 at 22:16
  • I see no evidence in that referenced post that LCs are ever slower than equivalent loop solutions. Are you talking about those ridiculous examples where the loop thing didn't even build a list? – Kelly Bundy Mar 24 '23 at 22:29
  • Yeah :D which is in line with [this](https://towardsdatascience.com/list-comprehensions-vs-for-loops-it-is-not-what-you-think-34071d4d8207). The authors shows that creating the lists is faster with a comprehension but manipulating them is actually slower - though not dramatically slower. And I would still wonder if it would always be slower. Then again, if I wanted to manipulate and cared about timing, I would check out other options too - like a map. – atru Mar 24 '23 at 23:22
  • It also seems like something that is changing with time. I feel like I should add those few bits to the answer. – atru Mar 24 '23 at 23:27
  • I think I've seen that garbage article before. Ridiculous. As I've come to expect from that website. Not sure what you mean with "manipulating them". – Kelly Bundy Mar 24 '23 at 23:49
  • Change the values without adding anything to the list. Like convert from strings to ints. Most of the points seem like something possible but I'm always careful with those random web articles..that's why I didn't list it in the post :D – atru Mar 25 '23 at 01:58