I observe that when reading this code, there is nothing to show when the parameter is a list versus a generator. Modern programming is all about abstracting away detail to allow the programmer to concentrate on the structure and other stuff that matters, but it seems to me (and I may be wrong) that increasingly we find things that look the same, get used the same, generally behave the same, and then are different in a corner case.
It seems that allowing lists and generators to be used in identical ways generally makes things easier to create and easier to use, but the differences in the corner cases suddenly mean you have to know about the detail. Then it becomes hard.
The problem isn't that it's easy to fix. We all know how to fix these sorts of things. The problem is that details you need to know are being hidden, because you shouldn't need to know about them.
When I write a routine should I always "assert" that its parameter is a list and not a generator? Do I have to write the code to use a slower technique just in case the parameter is a generator? Do I "ungenerate" the generator out into a list?
When I write a routine should I always "assert" that its parameter is a list and not a generator? Do I have to write the code to use a slower technique just in case the parameter is a generator? Do I "ungenerate" the generator out into a list?
That the caller can be trusted to use the proper type in arguments to a function a basic assumption in Python. The decision about how to handle type mismatch errors is up to you. You can handle generators any way you'd like, depending on your needs. There are other modern languages that don't make the same assumptions Python does.
Modern programming is all about abstracting away detail to allow the programmer to concentrate on the structure and other stuff that matters, but it seems to me (and I may be wrong) that increasingly we find things that look the same, get used the same, generally behave the same, and then are different in a corner case.
I agree. I would paraphrase this as: Leaky abstractions cause bugs, and unfortunately all abstractions turn out to leak at some point (I think someone else said it this way before, but I can't remember who right now). EDIT: Found it - http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
This doesn't mean we shouldn't use abstractions of course - it just means each abstraction comes with a cost.
It seems that allowing lists and generators to be used in identical ways generally makes things easier to create and easier to use, but the differences in the corner cases suddenly mean you have to know about the detail. Then it becomes hard.
The problem isn't that it's easy to fix. We all know how to fix these sorts of things. The problem is that details you need to know are being hidden, because you shouldn't need to know about them.
When I write a routine should I always "assert" that its parameter is a list and not a generator? Do I have to write the code to use a slower technique just in case the parameter is a generator? Do I "ungenerate" the generator out into a list?
That can't be right ...