this is doing my head in, in the map structure x is row and y is column

map = [
  "TMT", # x
  "...", # |
  "..T"  # v
  # y ->
]

and I have to wonder if the purpose of it is to write arr[x][y] - but when actually displaying that arr it is quite weird, as the elements of arr are then rows.

I do recognize that it's a matter of perspective and that directions and axis names are arbitrary. Those particular names do come with expectations though x)

I forked it rather than attempting to explain where I want to go

Iterates the outermost list and the LoS-pairs, thus ignores anything else about the type. The coordinates have to be tuple. Order is ignored.

Obviously adjust/edit further to your liking. I think that error output is nice, maybe you don't.

I also fixed the type signature for the initial code which was incorrect (it was describing a size-1 tuple), and changed the default return value from None to [] to match the signature.

I did mention that the signature is a bit lengthy xD
I also added an error output to show expected structure when the answer is ill formed because I suspect most people will gloss over the signature so seeing the correct structure there, even though the description already does that, might help someone.

It might be overengineered. But uhm. If I want it to behave a certain way.. >_>

Apparently, the order of pairing still does matter, contrary to the instructions:
[((0, 0), (1, 0)), ((0, 0), (0, 1))] should equal [((0, 0), (0, 1)), ((0, 0), (1, 0))]

Thanks for the follow up. My first solution was to enclose all of the tuple pairs in a List of Tuples as is documented in the instructions. Although my code generated all of the correct tuple pairs, every test failed, showing that the desired output was to enclose the tuple pairs in a List of Lists. So I changed my code to output the tuple pairs in a List of Lists. This time, all test cases passed with the exception of that one test. That is what prompted me to submit my original post describing these problems. After the author changed the code to accept either a List of Lists or a List of Tuples, my code still failed that one test. I then just hardcoded around that one test so I could pass all of the tests. What I still don't understand is that after reviewing the other solutions, they are all generating a List of Tuples. When I generate a List of Tuples however, none of the tests passed. My code only passes the tests if I generate a List of Lists (with that one exception). Very strange!!!!

Accessing an old, cached version is not something what could happen, and it's not somethign what happens.

If I can read tests correctly, the problem is in how tests handle tuples vs. lists in a quirky way. The sort function tries to normalize actual to always use tuples, but there is one fixed test case when sort is not called.

If you know what test case makes you fail and you want to work around the faulty assertion, you can just hardcode this particular input in your solution.

This is a very strange problem. After seeing that 10 people had successfully solved your kata, I decided to "reset" the kata and start over. For whatever reason however, I am still encountering the exact same problem. It appears that I am trying to solve an older version of your kata. Since other Codewars users don't seem to be having this problem, I put a special, one off, check in my code to handle the one test differently than the others. My version of your kata is still looking for the resulting tuple pairs to be enclosed in a List of Lists instead of a List of Tuples with the exception of that one test. Thanks for trying to fix this but I somehow must be accessing an older cached version of your kata.

Okay I believe I've fixed this, technically it supports either pairs being [tuple, tuple] or (tuple, tuple) but I'm not sure I care anymore. I could add a typecheck but I'd rather just allow both I guess.

I keep having partial updates while writing this, super frustrating, let me see if I can fix.

Problem 1:
Your kata states "You must return a list of tuples containing all coordinates pairings. (Order of pairing doesn't matter e.g. ((0, 0), (1, 1)) or ((1, 1), (0, 0))". Your tests however appear to be looking for a List, containing "Lists" of tuple pairs. For example, [[(0, 0), (0, 2)], [(0, 0), (1, 0)], [(0, 2), (0, 4)], [(0, 2), (2, 2)], [(0, 4), (1, 4)]] passes one of your tests.

Problem 2: My code passes all but one of your 108 tests when the tuple pairs are enclosed in a "List". Given ['TT', 'T.'] as input to your "oops all towers but one should be valid" test, my code produced [[(0, 0), (0, 1)], [(0, 0), (1, 0)]] but you were looking for [((0, 0), (0, 1)), ((0, 0), (1, 0))]. In this case, you are looking for the tuple pairs to be enclosed in a tuple instead of a List. In all other tests however, the tuple pairs are enclosed in Lists

I just checked that, and I'm still getting this message on a failed test: [((0, 0), (1, 0)), ((0, 0), (0, 1))] should equal [((0, 0), (0, 1)), ((0, 0), (1, 0))]

I've fixed the ordered nature of coordinate pairs I believe. It should now be truly unordered (meaning it shouldn't care if you return, [[0, 0], [1, 1]] or [[1, 1,], [0, 0]]).

I've fixed this in my update that I want to publish so I think I need to mark this as resolved before I publish it? Really weird if that's what I have to do.

Will update. Thank you. Edit: Updated.

1. `map' is shadowing a builtin

2. typo : both valid coordaintes

3. Use formatting conventions -> Each character can be one of three letters: T | M | .

The function should return a set of tuples.