On Wed, Dec 14, 2011 at 3:08 PM, Laura Creighton <lac@openend.se> wrote:
In a message of Wed, 14 Dec 2011 14:36:43 PST, kirby urner writes:
Isn't this at least as readable, and conceptually simpler?
if ext in res_dict: res_dict[ext] += 1 else: res_dict[ext] = 1
I get that a lot too and often propose my one-liner. This is not a matter of flagging a mistake, just showing another way.
It's a chance to learn dict methods better and hey, they're paying to have a pro coach.
Kirby
This looks suspiciously like 'I am a superior being I know more obscure methods that you do, and obscure knowledge defines the professional'. Bleah.
I'll take the opposite view for the sake of argument. dict is like the core data structure in Python and if you don't know about dict.get( ) then good thing you came to the right place where professionals are not afraid to use the well-thought-out features of this language. To treat dict.get(k, d) as obscure and it make it one's professional business avoid it is misguided.
By my standards, this is _unprofessional_. Whenever you have the urge to write code to show off how smart or how knowledgable you are, kick yourself. Professional code is meant to be read. If you make the general reader go off to the manuals to find out why something is done, then you ought to have a darn good reason for doing it that way than the way that everybody can read and understand.
I always explain with the syntax is doing. It's not about going off to the manuals. I'm shrinking four of five lines of code to one. Many of my students use dict get( ) naturally, without my prompting.
Personally, I think that Python would be a much better language if it had fewer of these sorts of methods, thus forcing people to use syntax like Bert Freudenberg posted above, because the more obscure ways aren't available. Now we have to rely on personal self-discipline to not use them, even when we know them, and a deep, unshakeable faith that code is meant, first and foremost to be _read_, and read by _everybody, not just the other 'experts' -- an expert being one who is defined here as 'one who is well-steeped in Python obscurity as you are'.
I think returning a default if a key is not found is one of those workaday methods we thank Python for having, so we don't have to code up little mini-functions. If you saw try /except over and over and each time it was the same thing: some dict not having a key, so needing to initialize a tally versus incrementing, then pretty soon people'd be griping about why Guido didn't have the smarts to put something so basic in the dict toolkit. Hey here's an idea: Lets all be patronizing and use baby talk, so our students don't learn the basics in ways we were too lazy to.
If we loose the ability to read Python, because all the new graduates are writing code that is hard to read as a matter of principle -- because they think it is superior, or a matter of ego -- because it shows off their knowledge and maybe their cleverness, then I might as well be reading any other language. We'll have lost the primary thing that I think makes Python valuable, via the 'boil-the-frog' principle. http://en.wikipedia.org/wiki/Boiling_frog
I think it's definitely a pitfall to be "too clever" in Python but where do we draw the line. Using built in methods that are basic to dict? I say what's *not* where to draw the line. I think better is to give a choice, show the options. It's my job to show off some of these basics in Beginning Python. Any method of any primitive data type is fair game. This isn't metaclasses or anything.
I think as educators it is our job to make sure this does not happen by teaching the appropriate self-discipline. I'd like to send your top students back their code with the comment, 'Great that it works. Now can you make it more readable?' I'd be looking for code like the above to replace code like yours.
Laura
I think Python is called a very high level language for a reason, and if we think "readable Python" means pretending it's C or restricted PyPy type Python, then we're just ripping ourselves off and being proud for no good reason. Kirby