Over the last several years I've been switching languages a lot and tend google very basic coding syntax, so I often see questions on Stack Overflow asking for the idiomatic way to do a task in a language. I think it's a pretty typical attitude that you could say a programmer hasn't truly "learned a language" without learning its idiomatic usage and performance characteristics but you'd still say you learned a language after using it for a year or so even if you haven't "truly" learned it.
I find talking about languages with other programmers can be challenging, because there's a class of coders who seem to have a belief that all programming languages are similar to mainstream imperative languages and therefore their strong opinion about all of them is valid and it's as if there's no point in learning more. Paul Graham mentions this in his Blub Paradox essay (http://www.paulgraham.com/avg.html): "You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.". In discussions with other devs in 30+ years as a professional coder, I've seen that over and over and it's kinda shocking to someone like me who partitions knowledge into the ol' known-knowns, known-unknowns, and unknown-unknowns.
Your question mentions carrying over a coding style from Python to C. True, you can do that and not really learn the new language. But for some languages, the compiler can force you to use a certain kind of programming style.
For example, in a lot of languages (say, Python, Ruby, Typescript) you can use higher order functions (like map, filter, reduce, zip, etc) but you can also write large codebases without ever using them. They're like an optional language feature that you can adopt depending on your preferred coding style. In Swift I noticed that there's no real difference in conciseness when comparing the syntax for map() or forEach against an equivalent loop, so that's not even a compelling reason to switch styles. But in a language that prohibits loops and early returns (e.g. ML-based langs like Ocaml, Elixir) then you're forced use those higher order functions to avoid having to write loops as custom recursive functions. It wasn't until the compiler forced me to code this way that I truly learned it.
Likewise, if your language enforces Option/Optional/Maybe (e.g. Swift, Scala, Rust) then you're forced to write code to deal with nulls. (Typescript is also like this, but you can bypass it by setting the type to `any` or using the `as` operator.) I worked through some chapters in an old tech interview book (Leetcode-style problems) in Swift and compared the functions to their equivalent in C, and was a little surprised at how many lines of code were dedicated to optionals. However, it was just a line or two more than the equivalent in C if it checked for null pointers. (Swift has a lot of nice syntax sugar for dealing with it; I wasn't as pleased with how Rust does it.)
You've probably heard of people talking about "fighting the borrow checker" in Rust. But the borrow checker struck me just like the above language features. You had to give up a style of coding and adopt a new one.