The generators feature looks very interesting, but the context in which it's discussed is a little vague on its full applicability. Are these true lightweight coroutines?

Quote: Original post by Pxtl
Well, the Python developers frequently break backwards compatibility on features, so yes, they could add new lexical features that would require the slight modification of old code to accomodate it.

I don't see any large breakages of backwards compatibility, only very small ones. I'm also given the impression that Ruby-style blocks couldn't be introduced without more serious breakages. This sort of thing has been discussed at length on comp.lang.python by people more knowledgeable than I.

Quote: My point is that the language has become obsessed with practicality above theory so far that it has crossed the line into becoming impractically practical.

Is that really true though? I know the urge is to feel that all the additions are bloat, but I can't find one example in my own code where generator expressions or function decorators would break anything, or make my code any less practical.

Quote: Original post by Sneftel
The generators feature looks very interesting, but the context in which it's discussed is a little vague on its full applicability. Are these true lightweight coroutines?

Generators are indeed Python's coroutine implementation, yeah.


I think some of the confusion comes about because Python mainly expects you to use a generator as an iteration implementation, hence the next()/StopIteration details. But they are certainly suitable for most coroutine applications.

Yeah, if I have two beefs with Lua coroutines, it's that (a) they're too expensive to create, and (b) for-loops don't expect them. Nice to see Python taking this route; I hope the Lua authors consider their example.

IIRC, yield was in 2.3, and does change the nature of the function object to have some increased overhead. So they're not quite as lightweight as you'd think, but still a very nice implementation of coroutines.

Quote: Original post by Sneftel

Yeah, if I have two beefs with Lua coroutines, it's that (a) they're too expensive to create, and (b) for-loops don't expect them. Nice to see Python taking this route; I hope the Lua authors consider their example.

Regarding point b, the for loops will directly accept coroutines created with the coroutine.wrap function. That being said, it should be easy enough to write a Lua function that takes a coroutine created with the coroutine.create function and return a closure that is usable in a for loop. [edit] Actually that may be what coroutine.wrap does too.

What do you mean by "expensive"? I have just got familiar with Lua coroutines and it would be nice to know before I start using them everywhere.