No. In this case that part of the analogy is actually not apt at all. To use another bad analogy I think my point is that the feeling awkwardness actually comes from the fact that I was doing the equivalent of holding the hammer by the head and trying to pound nails, only to later realize that I should have been holding the handle, and that there actually was a handle. In python it is like having a sledge hammer that you can't possibly hold by the head, but that no matter how hard you try you keep putting holes in the wall when you try to hang a picture.

Someone will say 'but why not use the tack hammer?' and, at that point I argue, I am no longer using python the language, but a whole new language that happens to look like python but that has a different runtime and a different set of assumptions. This even happens inside of the core language where `[d(a) for a in b if a == c]` can be valid in some scopes but not in others. The other language does the opposite, it says "you can't do that" and so I try to hold the hammer by its head and think that it is the language that is awkward because I don't know how to use it and that there is an fact a nail gun that is configurable along every dimension from nail diameter, to nail length, to insertion speed and pressure profile over the whole insertion timecourse, it is just not there in plain sight and I the first few times I used it I accidentally nailed my feet to the ground with railroad spikes.

I guess it is more that every time I learn more about python it is about what I have to NOT do in order to be safe. In the other case I learn what TO do in order to solve the problem the way I want to. Maybe the clearest example I can think of is lambda, where you have something that looks like a lambda, but that doesn't doesn't even work like the def (): that it copies due to the biases of the language designer. Honestly it would be better if Python just removed all the syntactic features that don't have generalized runtime support because that way you don't have to know which features you can use where. Sure, there is a use case for lambda in certain contexts, but if Python refuses to support lambda as a general abstraction that I can use everywhere, then it should be removed from the language, because including it leads to those hidden inconsistencies which require an enormous memory burden on the developer just to know what is not allowed. That is dead knowledge that in no way empowers and enriches the programming experience.

In essence the push for pythonic code is not just about maintainable code, it is about keeping people on the happy path without removing delimited abstractions, which is fine, except that the explicit solution to this problem would be to have `from __i_know_what_im_doing__ import lambda, comprehensions` so that the core language didn't misleadingly offer these delimited abstractions. Of course this means that many of my favourite features would be thrown out until some core technical challenges were resolved.