Mailman 3 December 2011 - Edu-sig

Re: [Edu-sig] Edu-sig Digest, Vol 101, Issue 10
by Marianne McKenna Dec. 24, 2011

Dec. 24, 2011

I will be out of the office today. If you need immediate help please contact the computer center. Thanks.

1 0

a Python title I'd like to see.... (idle fantasy)
by kirby urner Dec. 24, 2011

Dec. 24, 2011

My idea of good Python lore would be an almost book length discussion, at least, of the implementation of the "list" data structure. Go through the C in great detail, using this as an excuse to teach C in the context of it's supporting a higher language, looking ahead for your readers, knowing some of them will be heading off into C#, Java and PyPy implementations, at least. Or have come from there. Talk about what testing looks like, when working on Python, and where can I get the tests, how might I set up shop as a developer (of Python and other things). One way is to read / compile / test the source code for Python itself. That's a curriculum I've proposed several times and I'm sure many have thought of besides me: cut your teeth learning Python and then descend a level to a system language and begin studying the implementation of Python in that language. You'll start to appreciate Python in ways you never have, and you'll start learning what nitty gritty memory allocation looks like, and "declarative languages" (not the technical term -- compile-time checked, type audited, the whole nine yards). The thing is, you want your readers to be optionally following along, doing their thing at the command line (fire up that gcc), meaning what was "a book" is now this constellation of artifacts including different versions of lessons depending on what kind of platform you have. Compiling Python on Windows is not only doable, it's highly successful, but exactly how is it done? Some readers would avidly branch into that discussion, while others staying on a Mac (the original Python was developed on a Lisa). You've been studying the list type, as a data structure, have delved into the history, of linked lists, bubble sorts, clever algorithms, a kinds of class computer science. Lots of names fly by, opportunities to tell stories, fill us in. Obviously it'd take a talented writer, far beyond my ken, to tie this into LISP and the whole theory of S-expressions and like that, a heavy dose of formality, somewhere in the middle of the book. Make the list concept shine, but then come back to earth and have it be one data structure among many. Python celebrates diversity, heterogeneity, cosmopolitan values. The allure of crystalline purity is thankfully muted in Pythonia. We don't need it to be "seamless". Because Python plays well with others, this is hardly just about recruiting to Python. We want to demystify computers more generally and find a not-dumbed-down dissection of the list type, in terms of C, and even lower level languages (how does C work), is just what a certain segment of the public was craving. A wild bestseller. New York Times Review of Books is all agush. "How to think like a computer scientist on steroids...". Dunno who could write it. Might need to have interviews. Maybe not a book at all. Direct to DVD? Kirby

1 0

Re: [Edu-sig] Using try / except: any stipulations against routine use?
by Vernon Cole Dec. 19, 2011

Dec. 19, 2011

Sorry, Kirby, I'm afraid I disagree. try: res_dict[ext] += 1 except KeyError: res_dict[ext] = 1 is clear in intent and operation. It is a self-initializing occurrence counter. On the other hand, res_dict[ext] = res_dict.get(ext, 0) + 1 is obscure. Unless I go dig up the documentation of what the .get() operation does on a dictionary, I have no idea what the intention of the code is -- and I am (humbly) a very experienced programmer and Python programmer. Also I doubt whether the one-line version is faster. Without looking at the code, I would bet that .get() is implemented using a try / except structure. There is nothing wrong with that. Remember the Zen of Python: >>>import this ... Readability counts. ... -- Vernon

8 13

Re: [Edu-sig] Using try / except: any stipulations against routine use?
by Laura Creighton Dec. 15, 2011

Dec. 15, 2011

In a message of Wed, 14 Dec 2011 23:01:54 PST, kirby urner writes: >I happen to agree with your sentiments. > >I still think mytally [ mykey ] =3D 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. We're going to have to disagree about this one being 'just right' then. >> The problem is that, after a certain stage in language development, you >> get beyond the point where every new feature you add is completely positi >ve. >> 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 ahe >ad? > >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? Yes, this is pretty much my position. I don't think, in general, we can improve Python by making any more changes to the core language, and each change adds to the cognitive load we need to take on to learn the language. It used to take good employees 6 months to go from 'this is my first Python program' to being good Python programmers, and now it takes them longer. I'm not sure how much longer, or how we could go about measuring this, but I'd like to. But, again, I'm in favour of putting Software Transactional Memory into PyPy, and this will demand a syntax change. If the benefits of using STM happen -- we get to use our multi-cores for free -- then I think this would be a good candidate for a core language change. I hope that we will end up with the construct: with atomic: <these operations are executed atomically> see: http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.… for more details. This is what I consider a new, very high level construct that would make Python a more high-level language than it is today. I'm vastly more sympathetic towards language changes like this, as oppsed to language changes of the 'grow a few more methods here and there'. I think that large new syntactical changes have to face much harder scrutiny, as to whether or not they are beneficial. But it's hard to argue against adding this method, and that one in particular. Each of them adds only a tiny bit of cognitive load. Thus I worry about the boiled frog effect. The other thing I worry about is that many people, for whatever reason, like making syntactic changes to programming languages. I'm guilty of this vice myself. I think that everybody should design computer languages, for fun, because there is a real joy in this. (Just don't inflict the rest of the world with your shiny new languages unless you really think that you have something new to offer.) What is worse, from this perspective, is that good number of people are only interested in programming in languages where a good number of syntax changes are happening all the time. If the changes stop happening, they abandon ship and move to another, more rapidly evolving place. Thus, even if we could reach consensus that Python was more or less finished, there will still be pressure to keep making changes (which some people would persist in calling evolving) out of fear that we will loose these people. I think that the nicest thing about the moratorium was how few people left because of it, and that, when it was over there wasn't a huge surge in pent up demand as people began agitating for hundreds of changes, those they had been sitting on since the ban began. This says to me that a good number of changes are things that people really could and did live without. Or maybe those who only want to be using cutting edge languages have jumped ship a long time ago, and are programming in Clojure or something, and we just didn't notice. >Wouldn't it be refreshing to have Python not evolve just so a lot more >people could say they'd contributed a PEP? I don't follow this. I'm opposed to making changes in the language so that more people can say that their PEPs were accepted, but I don't think that this is what you were proposing either. >If you really can't live with the limitation of Python being how it >is, start a new language. Yes. This is what Dennis Ritchie used to say when people proposed changes to C after a certain amount of time. I think this was very good for C. >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 "co >re" >such that these would be self-labeling as "dialects" or "mutant forms". The architectural problem that looms here is 'when should XXX be part of the core language' vs 'XXX should be part of a library'. And our past says 'for reasons of performance, we need to grow the core library, even if for other reasons we would prefer not to do so'. I think that this assumption is now being undermined by the new multi-core architectures we have, but only time will tell. >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). Oh, I deeply sympathise with this problem. Suggestions of ways to automate this process are _also_ very welcome here. I'm getting seriously involved in automated testing of students these days, ways that students from remote locations can submit work online to be evaluated. (There are no grades here.). I had hoped that the ability to cut and paste would reduce my workload. It hasn't worked out that way. Possibly this is because I end up using every minute I save to say something that I would otherwise have skipped, regretfully, with the notion that it was too bad that I didn't have time to mention ... >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. Well, that's really all I wanted to hear. :-) If you can stand up to your own self-scrutiny, which I know is competant, then you probably aren't promoting shallow cleverness. But we are going to have to disagree about the readability of the get method. Laura > >Kirby

3 3

Re: [Edu-sig] Using try / except: any stipulations against routine use?
by Laura Creighton Dec. 15, 2011

Dec. 15, 2011

In a message of Wed, 14 Dec 2011 18:12:57 PST, kirby urner writes: >I'll take the opposite view for the sake of argument. >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. 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. 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? 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. 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. 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

2 1

Re: [Edu-sig] Using try / except: any stipulations against routine use?
by Laura Creighton Dec. 15, 2011

Dec. 15, 2011

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 because I know more obscure methods that you do, and obscure knowledge defines the professional'. Bleah. 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. 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'. 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 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

3 2

Re: [Edu-sig] Using try / except: any stipulations against routine use?
by Vernon Cole Dec. 15, 2011

Dec. 15, 2011

> Isn't this at least as readable, and conceptually simpler? > > if ext in res_dict: > res_dict[ext] += 1 > else: > res_dict[ext] = 1 > > Not arguing against exceptions in general, but in this case? > > - Bert - Yes, it is readable -- but more resource intensive -- since I have to access the dictionary twice, once to see if the key is there, and another to adjust or define the value. If I use try / except, then I will usually only have to access the dictionary a single time, with a second dip only if the key did not exist. A clear win for using exceptions. Incidentally, the .get() one liner also does two dictionary accesses, rather than one (since it can't use the += operator, the get() and the update/define are separate operations.) "Less lines" does not necessarily mean "runs faster." Dictionary lookups are a somewhat expensive operations. -- Vernon

1 0

Re: [Edu-sig] Using try / except: any stipulations against routine use?
by Laura Creighton Dec. 14, 2011

Dec. 14, 2011

I'm encouraging the use of try: except around here. I think the distinction between 'routine' and 'non-routine' only makes sense if exceptions are so terribly slower than the routine that using them for routine use will have a terrible effect in slowness on your program. It's like using: string1 = string1 + newstring inside a loop. The reason you don't do this is not because there is something conceptually wrong with this idea, but because it's horribly slow. And if smarter pythons recognise this, and emit fast code for it anyway, then that objection goes away, and then, well, it is a more straight forward way to code it. So, if performance is not an issue, then I would recommend using try: except: wherever it feels natural, and not let '20 years of knowing that in java exceptions are horrible big and slow things to be used sparingly' influence what feels natural. Laura

1 0

Using try / except: any stipulations against routine use?
by Kirby Urner Dec. 13, 2011

Dec. 13, 2011

Below is typical feedback to a student. What do others think regarding my discussion of using try /except in routine dict manipulation? Kirby === Yes perfect. Good work. try: res_dict[ext] += 1 except KeyError: res_dict[ext] = 1 This code is not atypical and you'll find some polarization among Pythonistas about whether this is good style. Another construct: res_dict[ext] = res_dict.get(ext, 0) + 1 is the one I favor. I think of a "key not found" event in a dict as "routine, to be expected" whereas I think of try: / except: as for "crying wolf" (not for everyday contingencies). The opposite bias is: why make that distinction, try: / except: is a perfectly reasonable construct for trapping a new key to a dict. In any case, good Python. -Kirby

3 2

mac python graphics
by Andrew Harrington Dec. 8, 2011

Dec. 8, 2011

I just got my first Mac. I know issues with Mac graphics have been discussed before, but I'm not sure what is relevant with OSX Lion. With the active state Tcl and the standard python.org python and idle appears fine. Still if I try running a Zelle graphic program inside or outside idle I get a freeze. The massive installation through MacPorts, that uses X11 for graphics makes my Zelle graphics library Tk based programs work fine, but the X11 version of Idle has many of the common keyboard shortcuts not working, and is (intensionally) not the standard Apple menu setup. What am I missing? Thanks, -- Dr. Andrew N. Harrington Computer Science Department Loyola University Chicago Lakeshore office in the Math Department: 205 Loyola Hall http://www.cs.luc.edu/~anh Phone: 773-915-7999 Fax: 312-915-7998 aharrin(a)luc.edu

5 6