Absolutely, but I'd also add that what works in one language/environment may not work in another. I wouldn't be surprised if writing Haskell-style code in Python didn't work out that well, for example!
I agree. I used to earn my bread in PHP and now I do it in Java, while after hours I mostly code in Common Lisp. I have some experience trying to port idioms from the latter one to the former two. Sometimes it turns into a good idea (God, how much my life in one PHP project was simplified by porting over #'mapcan), sometimes you quickly realize it's stupid and makes zero sense. But I think that's again a case of taste acquired by experimentation :). A big enemy here is simply sunk costs fallacy - no matter how emotionally invested you're in some idiom, sometimes it really doesn't fit the other language.
I have tried. Two things get in the way quickly, and that's even just expressing thing, not even looking at performance yet:
* Python standard library functions, especially the ones on dicts, mutate and don't return the new dictionary.
* Python's syntax for creating functions is awkward: lambdas are cumbersome, and so are the operator package and eg functools.partial; there's no really convenient way to compose functions.
Your first point is actually something I really like about Python's API design: in general, methods operating on collections either mutate the collection /or/ they return it. So it's clear at the point of use whether you're dealing with the same object or a new one.
This is something that bugs me about the fluent builder pattern in Java -- continuing to return `this` until suddenly you don't any more, and you can't re-use 'intermediate' values because they're actually all the same object.