Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
Yes, I concur, I just added the edit for [_, *middle, _], which is unnecessary in every sense. At least the *rest part would be useful if I needed to use the rest (which I don't at the moment).
I don't like hardcoded variables either, however in my case (i.e. my actual program to which the above is an MRE), hardcoded vars is the reasonable way, as it is guaranteed there's a limited set of vars. About the [_, *middle, _] part, I could directly count over inner_list, or could have avoided count altogether saving me iterating the list twice, but here I wanted it to be kind of suggestive that, I am looking for something that would match the pattern as is, without having to do count or if. It seems like there isn't a way to match such a pattern.
Yes, mutation would be fine here. About the potential solution being more elaborate, I was looking for something like this: in order to match key b in a dictionary d = {'a': 'foo', 'b': 'bar', 'c': 'baz'} it is sufficient to do case {'b': 'bar', **rest}:. Of course, it is easy for dicts as the keys are unique, and was historically thought of as unordered. But I was just checking if there were some new ways introduced in the new syntax that would make matching middle elements possible.
I kind of agree. And this is how my code was originally written, but thought I'd give the new thing a go, to see if I can use it to replace if else completely. btw isn't adding two lists O(n) as opposed to insert which is O(1)?