14
Last seen 4 years ago
Member for 11 years, 6 months, 4 days
Difficulty Normal
any([ch.isupper() for ch in data]) and
Using the any builtin is nice, but why stop there and code the rest using list comprehensions?
for method_name in ('isupper', 'isdigit', 'islower'):
if not any(map(methodcaller(method_name), data)):
return False
note thhat i
More
I like the use of sets, I chose very similar approach, just started with a full set and kept subtracting invalid guesses. This is probably more optimized but I prefer the clarity of not having to have the special condition (if numbers else new_numbers).
More
next = (end[0], end[1], None, 0, 0, dist(end, start))
This is very confusing and hard to read, consider using named tuples instead for clarity - it's super hard to keep track of what next[4] is etc. Also try to avoid using builtin names ('next') for your variable names.
More
def path(grid, passable, dist, start, end):
What does these variables mean?
More
possible = {}
There is no need for the done flag, just return when you find a solution.
More
consider storing the steps along with their names, that way you can
generate all neighbors and know the name of the direction. You can then
keep track of the sequence in the next tuple and thus avoid having to
translate it at the end with complicated code.
More
super long line super unreadable, it's usually good to follow PEP 8 for
readability
More
instead of constantly iterating over the possible values it might be btter
to look into some other data structure. queue.PriorityQueue would be ideal.
More
direction name in the tuple it would be just a simple matter of retrieving
the step names and concatenating them, avoiding the complicated
comparisons.
More
I don't feel there is any need to inject the dist and passable functions
into the path function - just define those as top-level functions or within
path and be done with it. Alternatively consider just hard-coding the logic
and commenting it.
More
This is very confusing and hard to read, consider using named tuples
instead for clarity - it's super hard to keep track of what next[4] is etc.
Also try to avoid using builtin names ('next') for your variable names.
# x, y, next, priority, distance_travelled, distance_to_end
More
