I know it has functions that are lazy, but it's not lazy as in a sense that Haskell is right? I never use it as I find it a ghastly horror show (my taste, other people like it, that's fine), but I had to use it a few times and found that (also from the article) some parts are lazy, but not python as a language. Is that not correct?
> it does limit the sorts of problems the language is suited for,
Interpreted (...) is the implementation, there is no reason why it should be interpreted.
You are right, the article is wrong. It is most certainly not lazy. f(g(), h()) will always call both h and g regardless of whether f uses their results.
Iteration in a sense can be "lazy", but that laziness is via data structures built on top of a strict core language. Python is not alone in having lazy iteratable data structures, but it leans into them relatively hard in its standard library.
Many of us love this, as it lets for loops work elegantly over all sorts of abstractions, but I could see some folks disliking it. Still, the author does not explain this nuance, which makes me think he does not quite know what he is talking about.
Almost every mainstream language has a way to "lazily" (in the sense you mean) iterate over lists, so this can't be what the author was singling out. I think he's just confused.
Agreed. It's so evidently wrong my guess is that the author thinks "lazy" means "dynamic", searched Wikipedia and pasted a link to the article without reading it (in which case he would have found it didn't match his understanding).
It's the less insane explanation. The alternative, that the author read and understood what lazy evaluation is, but somehow still thinks Python does it this way, is too crazy to consider.
Not Haskell style lazy but more of declarations are just another statement that aren't evaluated until those lines are executed. This means you can have function definitions inside of ifs which can be very useful for conditional programming / meta programming. Similarly, all variable accesses happen at runtime. This makes it so you can't truly statically verify the program but that the only way to know for sure how it will behave is to run it.
In an odd twist, function argument defaults are evaluated at function definition execution time rather than call-time (so half-way in laziness) so a `[]` as a default is shared between all users of that function and if you modify it you are changing a global. I heard that this led to a vulnerability within some security software.
What you describe is not lazy evaluation in any accepted sense of the term. I bet you it's also not what the author meant; he was probably thinking of dynamic typing.
Alternatively, maybe the author (and you) meant "interpreted language"? Lazy/strict evaluation is an orthogonal aspect.
I know it has functions that are lazy, but it's not lazy as in a sense that Haskell is right? I never use it as I find it a ghastly horror show (my taste, other people like it, that's fine), but I had to use it a few times and found that (also from the article) some parts are lazy, but not python as a language. Is that not correct?
> it does limit the sorts of problems the language is suited for,
Interpreted (...) is the implementation, there is no reason why it should be interpreted.