#Locomotive Engineer
18 messages ยท Page 1 of 1 (latest)
I would recommend against a map() call ๐
List comprehensions work just fine
[list(i) for i in zip(*rows)]
that still doesn't use the last hint given which I thought was sort of expected by the exercise. I'm surprised it even allows hardcoded answers to pass looking at other community solutions
and idek what map() does so not like I could use it ๐ฅด
That uses zip(*var)
ah guess it does say 'also'... how would I format it with that notation?
map(x, iterable) does the same as [x(i) for i in iterable] ... and list comprehensions were introduced into Python to eliminate the need of functional-style functions like map() and filter(). Comprehensions are considered more Pythonic and prefered.
list(i) can be written *i but that's not how it is usually done.
how does the x(i) part work? I get the normal for loop part but I didn't know you could put stuff before the for like that
does it modify the iterable value with x()?
@gilded jetty -- I've always found this article really helpful for comprehensions: https://treyhunner.com/2015/12/python-list-comprehensions-now-in-color/
and this one is good with explanations for * and **: https://treyhunner.com/2018/10/asterisks-in-python-what-they-are-and-how-to-use-them/
..and here is the final function for Locomotive Engineer not using map:
def fix_wagon_depot(wagons_rows):
"""Fix the list of rows of wagons.
:param wagons_rows: list[tuple] - the list of rows of wagons.
:return: list[tuple] - list of rows of wagons.
"""
[*row_one], [*row_two], [*row_three] = zip(*wagons_rows)
return [row_one, row_two, row_three]
Which is a version of what the hint points you toward. ๐
As for enforcing this using tests (as one of the authors of this exercise) ... well, if folx want to use map() or any other python feature, I am not going to stop them. If the result is correct, the test passes.
But using map() was absolutely not the point of the exercise. Nor was using comprehensions. Unpacking and multiple assignment was.
thank you, that list comprehension article helped me understand list comprehensions a bit better but I'm still struggling to wrap my head around using the * and ** operators 
I know if it works it works, but I expected I'd get like a 'hey you're not intended to do it like this' in the code review or something (of any exercise) so I know I'm learning what the lesson intended ๐
I struggle with this quite often as an exercise author and track maintainer. On one hand, you are correct -- it would be nice if we had tailored messages when a student didn't implement something the way we hoped they would.
On the other? Even using * and ** has enough variance that checking for the solution noted earlier is a tad unfair. There are a bunch of other ways to use * there that would get you the same results (including the comprehension Isaac pointed out earlier, and the multiple uses of map() that you've encountered). So enforcing one solution would lead to a bunch of questions and (likely) a bunch of arguments.
Our overall philosophy is that we test for results and not implementation (with a few โ but not many exceptions). Implementation is the student and mentor's business, which is why we encourage students to get mentoring and to iterate on their solutions.
The code above is from the exemplar solution to this exercise. We encourage mentors to be familiar with the exemplar solutions to concept (learning) exercises โ and to guide students towards that solution as a goal. But every mentor/student is different, and so are mentoring sessions.
We do have some analyzer rules on the track that look for specific things, but adding more rules is fairly labor-intensive and (since this is a volunteer operation) slow-going. At this time, we don't have anything specific in place for Locomotive Engineer- just general linting rules. So apologies for that.