One of the key attractions of most of Python is it's potential for clarity.
As worthy as they are, it is worrying to me that the sexy/cool features that are being added in 2.4 (applies to some of 2.2/2.3 as well) are hard for even the gurus to describe in clear Joe-public terms. By all means study and use them but this is a bit of a plea to avoid them in examples posted here unless you know your audience's knowledge level can cope.
It is for that reasons I generally don't use list comprehensions as I believe they are the exact opposite when it comes to my own code reviews or helping others understand a principle.
Perhaps this is trivial but here is an example of what I mean:
lines = file("myfile").readlines()
This is a very convenient short hand tha we all use, that relies on defaults and the writers (hopefully) full understanding of the file IO process. Unfortunately, it is used too often in examples posted here and elsewhere (I'm guilty too) where the audience is often a complete beginner.
As useful as it is - if it doesn't work as expected for the person who uses the code where do they start debugging?
1. It uses a hidden read access mode 'r'.
2. The file must exist
3. We must have the correct permissions
4. We must be able to read the whole file in one go.
6. The file is opened and closed automatically.
IMO For example code then this line should would only be used is two case:
1. Where you are explicitly comparing the methods (implicit versus explicit)
2. Where it is not relevent to the problem except as a means of supplying data.
As long-winded (old fashioned?) as it may seem:
myfile = file("mytext","r")
lines = myfile.readlines()
myfile.close()
tells the newbie much more about objects,methods and process and the error reports are likely to be more helpful too.
In real production code - it's still good practice - you can control the process with exceptions and error checking to a much finer degree.
Any counter thoughts?![]()