On Wed, Dec 14, 2011 at 7:38 PM, Laura Creighton <l...@openend.se> wrote:
> If you are seeing this over and over, then it is time to reach for > defaultdict, no? I've found that that often does produce what is for me > more readable code, and has the advantage of being very fast, too. > I'm happy to see defaultdict enter the picture. That adds new grist for the mill. It's not covered in the lessons I teach from, so it wouldn't be as apropos, whereas students are much encouraged to explore the dict object using dir({}) etc. dict itself is an interesting builtin, being a type name and a callable, but not a function. dict( ) is not a function being called, likewise list( ), str( ), float( ), set( )... int( ). I'm getting off topic slightly. Also, I don't think fussing about a few microseconds is very Pythonic. If that's really your concern, then C might be better. VHLL means we're not anal about micoseconds. It's an interpreted language for crying out loud. "Readability" is the value I think we both agree on. It's more just a matter of where to draw the line. I'm thinking the dict's get( ) method, like itemsI( ), is too important to bleep over, especially when you see students using try: / except: syntax. Likewise, when introducing print( ), one must look at the optional keyword arguments, sep=, end= and file=. When you see a student laboriously trying to get around that default space between strings, let them know they have control. Here's what I come down to: at least make sure they know they have a choice. If they learn about .get and still go back to something else, fine. And that's indeed how I grade. I never send it back as "incorrect" if they didn't use .get (if it comes back, it's for other reasons) and I don't get bent out of shape if they decide to not incorporate it into their vocabulary, even after it's been introduced. At least I did my job in letting them know about it. > But your last sentence here bothers me too. I think that 'smarts' and > 'cleverness' are terribly overrated in society today. It's not that > being stupid is an attractive option. But often the alternative to > being _clever_ about something is being _wise_ about something. So > the question, in that case, might not be 'why did Guido not have the > smarts' but 'Was Guido being wise here?'. Is there a reason why this > sort of thing does not exist? > I happen to agree with your sentiments. I still think mytally [ mykey ] = mytally.get ( mykey, 0 ) + 1 is not "too clever". I think it's rather "just right". But sure, use defaultdict instead if you prefer. Or try / except, even though it's more verbose. What'd be a good lesson plan on defaultdict that lets it strut its stuff. I think we should incorporate that in one of our lessons. Who wants to do unpaid volunteer work. ;-) > And, quite often, with questions of this sort you get the answer 'because > there really isn't a need to clutter up the language with XXX' -- and > you can look up past discussions about features that aren't in Python > and see Guido saying exactly that all the time. > Which means he thinks dict.get is not clutter. I feel it's being there is evidence for my case in this debate. [ re this being "a debate" and me looking for a shared "value" -- readability -- is likely influenced by my immersing myself in the teen debate world in Washington / Oregon, and being suitably and happily impressed much of the time: http://worldgame.blogspot.com/2011/12/foray-to-washington.html ] > The problem is that, after a certain stage in language development, you > get beyond the point where every new feature you add is completely positive. > Instead, you are stuck with haveing to decide for or against a feature > that makes expressing 'this sort of problem' easier, and makes for clearer > and more readable code, but at the expense of making it possible to use > these constructs when dealing with 'that sort of problem', where the > result is poorly constructed, harder to read code. And that is the tradeoff > that is always there. > Maybe core Python should stop advancing. Seriously. Why keep going? It's a great language, 3 x best in show per LinuxJournal. Quit while ahead? Lets have cool libraries but call it quits on adding to core Python. Is anyone taking that position, just for kicks? I know about the moratorium that happened for awhile. Why not make it permanent? Wouldn't it be refreshing to have Python not evolve just so a lot more people could say they'd contributed a PEP? If you really can't live with the limitation of Python being how it is, start a new language. Note: I am mindful that PyPy provides many more freedoms and think halting the evolution of core Python would NOT inhibit people from forking off in all different directions with *specialized* Pythons that would be for particular lines of work, i.e. we could still have many many more Pythons. Just we're done defining "core" such that these would be self-labeling as "dialects" or "mutant forms". > Blindly trusting that a feature that is in a language should be used whenever > it can be used, is not wise. But if we have a language for grown-ups, which > relies on self-discipline, and indeed assumes that programmers have the > wisdom to use Python well, then, well, there is nothing for it but as > educators to try to promote wisdom. > > Suggestions on better ways to do this are most welcome. So far, being > somewhat disapproving of cleverness, and downright hostile towards > gratuitous cleverness is about the best I can do. As well as sending > assignments back with the note -- refactor for redability -- which at > least gets people thinking beyond 'how to solve this'. > > Laura > If someone used: mytally [ mykey ] = mytally.get ( mykey, 0 ) + 1 instead of one of the two other options presented, I would never suggest sending it back for readability. On the contrary, I'd say it's my job as a Python reader to know this idiom. This is a core method of a basic data type. However, I am persuaded by this thread, and it was also my position to begin with, that the two alternative ways of doing this same thing should not be sent back for refactoring either. I don't do this. I just present the above idiom and say things like "many programmers would abbreviate that to this". I usually quote their code and show the same .get( ) syntax with the exact same names, which means custom typing on my part, extra work (I graded 183 items today, many of them programs, so it's not like I have lots of time to spare). I don't think I'm going over the line in over-promoting superficial cleverness, which I agree is not to be encouraged except in contests / contexts where that's a pre-specified good / goal. Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig