Simple and Short creative solution for Can You Pass? by StefanPochmann - python coding challenges

Enable Javascript in your browser and then refresh this page, for a much enhanced experience.

Simple and Short solution in Creative category for Can You Pass? by StefanPochmann

def can_pass(matrix, first, second):
    reach = [first]
    for i,j in reach:
        reach += [(I,J) for I,row in enumerate(matrix) for J,a in enumerate(row)
                  if abs(i-I)+abs(j-J)<2 and a==matrix[i][j] and (I,J) not in reach]
    return second in reach

April 28, 2015

Comments:

veky on May 4, 2015, 11:19 p.m.
Aargh - appending while iterating. Aargh! :-D

StefanPochmann on May 5, 2015, 12:15 a.m.
The way I do it should be safe, though, no?

veky on May 5, 2015, 4:54 p.m.
Yes - in CPython. Currently. :-] Ok, <a href="https://hg.python.org/cpython/rev/e0a407d41af5">wording has been softened</a> in the meantime, but still I don't think it's standardized. This should probably be solved with streams, once Python supports them.

StefanPochmann on May 5, 2015, 7:53 p.m.
Looks like general advice and their example involves <pre class='brush: python'>insert</pre>, whereas I've only used this with extend/append. But yes, I'd prefer seeing a guarantee rather than relying on what happens to work. I'll reconsider. The way I think of it is that <pre class='brush: python'>for a in mylist</pre> is the Python version of <pre class='brush: python'>for(i=0; i<len(mylist); i++) a=mylist[i]</pre> and it feels quite natural for me that the loop keeps going when the list is extended. I wouldn't do this if I inserted/removed elements before my current position, but I think appending elements to the end really should behave like it apparently does and I can't imagine them breaking this.

veky on May 6, 2015, 6:49 a.m.
I too cannot imagine them breaking this, but for a different reason: too many people already rely on it. [Probably because Python never had true native streams (of arbitrary objects - it has them for characters and bytes), it's logical people just tried to use list as a stand-in (it has closest API), saw it works (at least in usual cases, such as append/extend), and called it done.] <blockquote> The way I think of it is that <pre class='brush: python'>for a in mylist</pre> is the Python version of <pre class='brush: python'>for(i=0; i<len(mylist); i++) a=mylist[i]</pre> </blockquote> Many people think that, but it's not. :-) For example, <pre class='brush: python'>x = [[1,2], [3], [4,5]] for x in x: print(x) </pre> will print all three elements of (former) x, it will not stop at 2. It truly is: <pre class='brush: python'>_iterator, a = iter(mylist), None def _advance(iterator): nonlocal a try: a = next(iterator) except StopIteration: return False else: return True while _advance(_iterator): </pre> (except a doesn't exist if next(iter(mylist)) raises StopIteration). But that doesn't really answer your question, because the main question is what exactly <pre class='brush: python'>iter(mylist)</pre> holds (what kind of structure <pre class='brush: python'>list.__iter__</pre> returns), and how exactly <pre class='brush: python'>next</pre> advances it (what changes to that structure its method <pre class='brush: python'>__next__</pre> does). Of course, the most straightforward way to do it would be just to hold the index (and the list, maybe by closure), and increment that index by 1 in <pre class='brush: python'>__next__</pre>, returning element by <pre class='brush: python'>__getitem__</pre> and converting its <pre class='brush: python'>IndexError</pre> to <pre class='brush: python'>StopIteration</pre>. And current implementation does something comparable to that (just in C). And with that implementation, your use case works as you expect. But I completely understand that they don't want to commit to it. :-)

StefanPochmann on May 6, 2015, 10:43 p.m.
<blockquote> but for a different reason: too many people already rely on it. </blockquote> Nah, that's also the main reason I had in mind. I'm aware that they're trying to not break things and that I can't be the only one (ab)using this. <blockquote> Many people think that, but it’s not. :-) </blockquote> Well, I didn't mean literally like that. My point is that I think of it as "the loop" internally having some kind of index which starts at zero and keeps going until it hits the length of the list. I guess that's equivalent to your error to stop conversion in the case of lists, but that one is of course more general. Learned something again, thanks.

veky on May 7, 2015, 4:52 a.m.
About comparing index to len: of course it's still compared at some point. But now it is compared at the right point, as deep internally as it can, where the communication between the right point and the deciding point is ensured via exception chain. EAFP vs LBYL, you probably heard of that already. :-)

H0r4c3 on May 28, 2024, 8:41 p.m.
Good solution!

Mine

0 %

PyCharm The Python IDE for Professional Developers. Enjoy productive Python, web and scientific development with PyCharm. Download it now!