From aharrin at luc.edu Wed Dec 7 18:45:50 2011 From: aharrin at luc.edu (Andrew Harrington) Date: Wed, 7 Dec 2011 11:45:50 -0600 Subject: [Edu-sig] mac python graphics Message-ID: 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 at luc.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.zelle at wartburg.edu Wed Dec 7 19:19:38 2011 From: john.zelle at wartburg.edu (John Zelle) Date: Wed, 7 Dec 2011 18:19:38 +0000 Subject: [Edu-sig] mac python graphics In-Reply-To: References: Message-ID: <5C3D88F9CF7A4B428F5A166760F5547F3005A48B@MSEXCHMB01.wartburg.edu> Andrew, We have numerous students and faculty here who are successfully using graphics.py with OSX Lion. The main problem for them was getting the ActiveState Tcl/Tk fix, but it sounds like you have already done that. If IDLE is running, there is no reason that the graphics package should give you difficulties. I have two quick suggestions. First make sure you have the latest version of the graphics library available from my python page: http://mcsp.wartburg.edu/zelle/python. You probably do have it, as it has not been updated in quite a while. The important thing is that you need the unthreaded iteration of the library. Second, make sure that every graphics program shuts down properly by executing window.close(). If your processes are hanging up on program termination, this could be the issue. It is not sufficient to simply have the Python program quit. If neither of these addresses your issue, then I would appreciate it if you would send me a slightly more detailed report letting me know exactly what version of python and Tcl/Tk you are running and providing a simple example program that causes freeze up along with a description of exactly how it locks up. Cheers, --John John Zelle, PhD Professor of Computer Science Wartburg College ________________________________ From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of Andrew Harrington [aharrin at luc.edu] Sent: Wednesday, December 07, 2011 11:45 AM To: edu-sig at python.org Subject: [Edu-sig] mac python graphics 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 at luc.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jasonrbriggs at gmail.com Wed Dec 7 19:50:27 2011 From: jasonrbriggs at gmail.com (Jason R Briggs) Date: Wed, 7 Dec 2011 18:50:27 +0000 Subject: [Edu-sig] mac python graphics In-Reply-To: References: Message-ID: Argh. iPhone big finger button clumsiness. Don't know if my reply sent or not. So trying again... Try running idle in no sub process mode. Add -n to the cmd line args. On 12/7/11, Andrew Harrington wrote: > 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 at luc.edu > From davelist at mac.com Wed Dec 7 18:55:42 2011 From: davelist at mac.com (davelist at mac.com) Date: Wed, 07 Dec 2011 12:55:42 -0500 Subject: [Edu-sig] mac python graphics In-Reply-To: References: Message-ID: <988F6B47-FFDB-490D-B28B-5E53912AA631@mac.com> On Dec 7, 2011, at 12:45 PM, Andrew Harrington wrote: > 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 at luc.edu Are you closing the GraphWin window before exiting your program? from graphics import * win = GraphWin() # do other stuff win.close() # this is the important line (without it, I think it does freeze) I keep forgetting to ask John about this to see if there's something we could do to modify graphics.py so this isn't necessary. I don't think I've done anything else to the standard python.org (i.e., I installed Python 3.2.2 on Lion, but didn't download anything extra such as Tcl). You do need a newer Tcl than comes with Snow Leopard (Idle tells you this in the shell window when you open it), but I think it works fine with Leopard as long as you close the window. HTH, Dave From aharrin at luc.edu Wed Dec 7 21:27:50 2011 From: aharrin at luc.edu (Andrew Harrington) Date: Wed, 7 Dec 2011 14:27:50 -0600 Subject: [Edu-sig] mac python graphics In-Reply-To: <5C3D88F9CF7A4B428F5A166760F5547F3005A48B@MSEXCHMB01.wartburg.edu> References: <5C3D88F9CF7A4B428F5A166760F5547F3005A48B@MSEXCHMB01.wartburg.edu> Message-ID: Thanks, Juhn. I had somehow missed the latest version. What complications does the single threading bring? On Wed, Dec 7, 2011 at 12:19 PM, John Zelle wrote: > Andrew, > > We have numerous students and faculty here who are successfully using > graphics.py with OSX Lion. The main problem for them was getting the > ActiveState Tcl/Tk fix, but it sounds like you have already done that. If > IDLE is running, there is no reason that the graphics package should give > you difficulties. > > I have two quick suggestions. First make sure you have the latest version > of the graphics library available from my python page: > http://mcsp.wartburg.edu/zelle/python. You probably do have it, as it has > not been updated in quite a while. The important thing is that you need the > unthreaded iteration of the library. > > Second, make sure that every graphics program shuts down properly by > executing window.close(). If your processes are hanging up on program > termination, this could be the issue. It is not sufficient to simply have > the Python program quit. > > If neither of these addresses your issue, then I would appreciate it if > you would send me a slightly more detailed report letting me know exactly > what version of python and Tcl/Tk you are running and providing a simple > example program that causes freeze up along with a description of exactly > how it locks up. > > Cheers, > > --John > > John Zelle, PhD > Professor of Computer Science > Wartburg College > > ------------------------------ > *From:* edu-sig-bounces+john.zelle=wartburg.edu at python.org[edu-sig-bounces+john.zelle= > wartburg.edu at python.org] on behalf of Andrew Harrington [aharrin at luc.edu] > *Sent:* Wednesday, December 07, 2011 11:45 AM > *To:* edu-sig at python.org > *Subject:* [Edu-sig] mac python graphics > > 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 at luc.edu > > > -- 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 at luc.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.zelle at wartburg.edu Wed Dec 7 23:00:42 2011 From: john.zelle at wartburg.edu (John Zelle) Date: Wed, 7 Dec 2011 22:00:42 +0000 Subject: [Edu-sig] mac python graphics In-Reply-To: References: <5C3D88F9CF7A4B428F5A166760F5547F3005A48B@MSEXCHMB01.wartburg.edu>, Message-ID: <5C3D88F9CF7A4B428F5A166760F5547F3005A521@MSEXCHMB01.wartburg.edu> Andrew, The only real disadvantage of the non-threaded (current) version is that it does not play as well with the IDLE shell when demonstrating graphics interactively. But there are numerous advantages of the non-threaded version including that it works on OSX :-). I also like that I can have my students use Tkinter dialogs for opening files or getting simple inputs in graphics programs. As far as documenting the complete GraphWin API, I've always been a bit lazy about moving things into the official API, just because I want to keep the API really small so that it doesn't overwhelm first-time users of graphics. There have always been a few undocumented "goodies" lurking in the module. When I decide that I _have_ to have them for certain class projects, then they make their way into the official API. I'm very conservative, because I don't want to remove things (for backward compatibility), and I consider the API now to be at the limit of what I can expect my CS1 students to reasonably master. John Zelle, PhD Professor of Computer Science Wartburg College ________________________________ From: anharrington at gmail.com [anharrington at gmail.com] on behalf of Andrew Harrington [aharrin at luc.edu] Sent: Wednesday, December 07, 2011 2:27 PM To: John Zelle Cc: edu-sig at python.org Subject: Re: [Edu-sig] mac python graphics Thanks, Juhn. I had somehow missed the latest version. What complications does the single threading bring? On Wed, Dec 7, 2011 at 12:19 PM, John Zelle > wrote: Andrew, We have numerous students and faculty here who are successfully using graphics.py with OSX Lion. The main problem for them was getting the ActiveState Tcl/Tk fix, but it sounds like you have already done that. If IDLE is running, there is no reason that the graphics package should give you difficulties. I have two quick suggestions. First make sure you have the latest version of the graphics library available from my python page: http://mcsp.wartburg.edu/zelle/python. You probably do have it, as it has not been updated in quite a while. The important thing is that you need the unthreaded iteration of the library. Second, make sure that every graphics program shuts down properly by executing window.close(). If your processes are hanging up on program termination, this could be the issue. It is not sufficient to simply have the Python program quit. If neither of these addresses your issue, then I would appreciate it if you would send me a slightly more detailed report letting me know exactly what version of python and Tcl/Tk you are running and providing a simple example program that causes freeze up along with a description of exactly how it locks up. Cheers, --John John Zelle, PhD Professor of Computer Science Wartburg College ________________________________ From: edu-sig-bounces+john.zelle=wartburg.edu at python.org [edu-sig-bounces+john.zelle=wartburg.edu at python.org] on behalf of Andrew Harrington [aharrin at luc.edu] Sent: Wednesday, December 07, 2011 11:45 AM To: edu-sig at python.org Subject: [Edu-sig] mac python graphics 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 at luc.edu -- 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 at luc.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurner at oreillyschool.com Thu Dec 8 03:25:02 2011 From: kurner at oreillyschool.com (Kirby Urner) Date: Wed, 7 Dec 2011 18:25:02 -0800 Subject: [Edu-sig] mac python graphics In-Reply-To: <5C3D88F9CF7A4B428F5A166760F5547F3005A521@MSEXCHMB01.wartburg.edu> References: <5C3D88F9CF7A4B428F5A166760F5547F3005A48B@MSEXCHMB01.wartburg.edu> <5C3D88F9CF7A4B428F5A166760F5547F3005A521@MSEXCHMB01.wartburg.edu> Message-ID: Somewhat tangentially bouncing around in this vicinity, I offer these remarks re our situation at work, where we want students connecting over the wire to have good first experience using Python. Retention is an issue. The school's guiding philosophy requires providing real hands-on programming experiences and real interactivity with a full Python console, which until recently has meant booting a remote desktop into a server, running a session of Eclipse on a Windows server in Illinois (front end client could be anything). Here's a picture of the rig: http://controlroom.blogspot.com/2011/06/back-office.html Part of what keeps us in Eclipse is Tkinter. Our students can do widgets programming. We do not have the Zelle package installed, but would like to add it. We already work with Wolfram and have new kind of science exhibits working in the wings (I've posted about that here already), but so far only in ASCII (console i/o). Getting Game of Life type CA stuff running with graphics.py has already been done right here in this very archive, in earlier versions of Python. Anyway, a lot of students feel overwhelmed by Eclipse and have a hard time distinguishing between Python-the-language and the surrounding IDE. Many are brand new to programming, having heard Python is a friendlier-than-most language, winning the "best language ever" award a 3rd time in a row, didn't I just read? http://www.linuxjournal.com/slideshow/readers-choice-2011?page=27 However just recently, management has decided to swap out Eclipse in the first unit and go with a Javascript and Java enabled front end in a browser, already used to teach Perl. We can get away with this in the first unit only because Tk / Widget programming doesn't happen until the second unit. We'll ease them over to Eclipse having won their loyalty on the basis of Python (plus Coderunner, the name for the teaching tool). In the new configuration, no need for remote desktop, a less shaky connection. So even if you loved Eclipse, your situation may improve. The ability to learn widget programming interactively, writing your own programs, without having to install anything locally, not even Python itself, is a marketable feature. Then we have highly trained mentors to back it up, so there's no sense of "just a machine" on the back end. Works well so far (a relatively new gig for me, but this team has been at it for quite awhile). Kirby From kurner at oreillyschool.com Tue Dec 13 22:30:46 2011 From: kurner at oreillyschool.com (Kirby Urner) Date: Tue, 13 Dec 2011 13:30:46 -0800 Subject: [Edu-sig] Using try / except: any stipulations against routine use? Message-ID: 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 From sarina at MIT.EDU Tue Dec 13 22:39:52 2011 From: sarina at MIT.EDU (Sarina Canelake) Date: Tue, 13 Dec 2011 16:39:52 -0500 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: Message-ID: I enjoy your explanation. I have recently written something very similar to one of my students. We teach dictionaries about three weeks before exception handling, though, so I rarely see this code. On Tue, Dec 13, 2011 at 4:30 PM, Kirby Urner wrote: > 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 > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -- Sarina Canelake MIT EECS -------------- next part -------------- An HTML attachment was scrubbed... URL: From kb1pkl at aim.com Tue Dec 13 22:39:25 2011 From: kb1pkl at aim.com (Corey Richardson) Date: Tue, 13 Dec 2011 16:39:25 -0500 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: Message-ID: <4EE7C60D.5030000@aim.com> On 12/13/2011 04:30 PM, Kirby Urner wrote: > 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. > More evidence for the "perfectly reasonable": Iterators are implemented with the StopIteration exception. You can find a few other examples in the language for things like that. I think it's perfectly reasonable myself. -- Corey Richardson From lac at openend.se Wed Dec 14 20:43:54 2011 From: lac at openend.se (Laura Creighton) Date: Wed, 14 Dec 2011 20:43:54 +0100 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: Message from Corey Richardson of "Tue, 13 Dec 2011 16:39:25 EST." <4EE7C60D.5030000@aim.com> References: <4EE7C60D.5030000@aim.com> Message-ID: <201112141943.pBEJhske019750@theraft.openend.se> 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 From vernondcole at gmail.com Wed Dec 14 22:42:18 2011 From: vernondcole at gmail.com (Vernon Cole) Date: Wed, 14 Dec 2011 14:42:18 -0700 Subject: [Edu-sig] Using try / except: any stipulations against routine use? Message-ID: 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 From vceder at gmail.com Wed Dec 14 23:06:10 2011 From: vceder at gmail.com (Vern Ceder) Date: Wed, 14 Dec 2011 16:06:10 -0600 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: Message-ID: I think I'd go along with Laura and Vernon as long as it's made clear that one should specify the exception, as Vernon does in his sample. Bare excepts should NOT be encouraged, particularly since I've seen some students find them way too seductive - "Look, I can handle EVERY error!" ;) OTOH the .get() method has always struck me as imposing a bit of a cognitive load that I could live without. Vern On Wed, Dec 14, 2011 at 3:42 PM, Vernon Cole wrote: > 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 > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -- Vern Ceder vceder at gmail.com, vceder at dogsinmotion.com The Quick Python Book, 2nd Ed - http://bit.ly/bRsWDW -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Wed Dec 14 23:14:04 2011 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 14 Dec 2011 14:14:04 -0800 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: Message-ID: Interesting responses. I harp on that somedict [ key ] = somedict.get( key, 0 ) + 1 option quite a bit, as shorter and easier than all that try / except stuff. That's just the bias I've been applying, to an invisible army of... what? Hundreds? Hard to keep track. Anyway, good to see the other side of things. I tend to bust out in try / except syntax when I have to, but if I can keep it more button-down, I do. Kirby From bert at freudenbergs.de Wed Dec 14 23:15:17 2011 From: bert at freudenbergs.de (Bert Freudenberg) Date: Wed, 14 Dec 2011 23:15:17 +0100 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: Message-ID: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> On 14.12.2011, at 22:42, Vernon Cole wrote: > 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 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 - From kirby.urner at gmail.com Wed Dec 14 23:36:43 2011 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 14 Dec 2011 14:36:43 -0800 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> Message-ID: > 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 From lac at openend.se Thu Dec 15 00:08:48 2011 From: lac at openend.se (Laura Creighton) Date: Thu, 15 Dec 2011 00:08:48 +0100 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: Message from kirby urner of "Wed, 14 Dec 2011 14:36:43 PST." References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> Message-ID: <201112142308.pBEN8nOZ015677@theraft.openend.se> 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 From david at handysoftware.com Thu Dec 15 00:36:44 2011 From: david at handysoftware.com (David Handy) Date: Wed, 14 Dec 2011 18:36:44 -0500 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: <201112142308.pBEN8nOZ015677@theraft.openend.se> References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <201112142308.pBEN8nOZ015677@theraft.openend.se> Message-ID: <20111214233642.GA23766@blackbeauty> On Thu, Dec 15, 2011 at 12:08:48AM +0100, Laura Creighton 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 because I know more > obscure methods that you do, and obscure knowledge defines the professional'. > Bleah. Kirby thinks the one-liner is more readable than the 4-liner. So do I. Apparently this is something upon which reasonable people can disagree. :) David H From vernondcole at gmail.com Thu Dec 15 01:24:12 2011 From: vernondcole at gmail.com (Vernon Cole) Date: Wed, 14 Dec 2011 17:24:12 -0700 Subject: [Edu-sig] Using try / except: any stipulations against routine use? Message-ID: > 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 From andre.roberge at gmail.com Thu Dec 15 01:59:58 2011 From: andre.roberge at gmail.com (Andre Roberge) Date: Wed, 14 Dec 2011 20:59:58 -0400 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> Message-ID: On Wed, Dec 14, 2011 at 6:15 PM, Bert Freudenberg wrote: > On 14.12.2011, at 22:42, Vernon Cole wrote: > > > 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. > SNIP > 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? > > Personally, I find both the if/else and the try/except much easier to remember, and slightly easier to read than the one-liner. Furthermore, if one is interested in performance, it appears that the if/else approach is *always* faster than the one-liner. When exceptions are rarely raised, then the try/except approach is the fastest. Below are the results from a quick test to compare the efficiency of the three cases, followed by the code. This is using Python 2.7 on a fairly old computer. Andr? =============================== 100% new keys setdefault: 0.532404899597 try/except: 2.029556036 if/else: 0.241212844849 -------------------------------------------------- 10% new keys setdefault: 0.621008872986 try/except: 0.585212945938 if/else: 0.32776093483 -------------------------------------------------- 1% new keys setdefault: 0.615134000778 try/except: 0.388912916183 if/else: 0.321834087372 -------------------------------------------------- 0.1% new keys setdefault: 0.527935028076 try/except: 0.28360915184 if/else: 0.334416866302 ================ from timeit import Timer print "100% new keys\n" print 'setdefault:\t', t = Timer(""" d = {} for i in range(1000): d[i] = d.get(i, 0) + 1 """) print t.timeit(number=1000) print 'try/except:\t', t = Timer(""" d = {} for i in range(1000): try: d[i] += 1 except KeyError: d[i] = 1 """) print t.timeit(number=1000) print 'if/else:\t', t = Timer(""" d = {} for i in range(1000): if i in d: d[i] += 1 else: d[i] = 1 """) print t.timeit(number=1000) print "-"*50 print "10% new keys" print 'setdefault:\t', t = Timer(""" d = {} for i in range(1000): k = i % 100 d[k] = d.get(k, 0) + 1 """) print t.timeit(number=1000) print 'try/except:\t', t = Timer(""" d = {} for i in range(1000): k = i % 100 try: d[k] += 1 except KeyError: d[k] = 1 """) print t.timeit(number=1000) print 'if/else:\t', t = Timer(""" d = {} for i in range(1000): k = i % 100 if i in d: d[k] += 1 else: d[k] = 1 """) print t.timeit(number=1000) print "-"*50 print "1% new keys\n" print 'setdefault:\t', t = Timer(""" d = {} for i in range(1000): k = i % 10 d[k] = d.get(k, 0) + 1 """) print t.timeit(number=1000) print 'try/except:\t', t = Timer(""" d = {} for i in range(1000): k = i % 10 try: d[k] += 1 except KeyError: d[k] = 1 """) print t.timeit(number=1000) print 'if/else:\t', t = Timer(""" d = {} for i in range(1000): k = i % 10 if i in d: d[k] += 1 else: d[k] = 1 """) print t.timeit(number=1000) print "-"*50 print "0.1% new keys\n" print 'setdefault:\t', t = Timer(""" d = {} for i in range(1000): d[1] = d.get(1, 0) + 1 """) print t.timeit(number=1000) print 'try/except:\t', t = Timer(""" d = {} for i in range(1000): try: d[1] += 1 except KeyError: d[1] = 1 """) print t.timeit(number=1000) print 'if/else:\t', t = Timer(""" d = {} for i in range(1000): if 1 in d: d[1] += 1 else: d[1] = 1 """) print t.timeit(number=1000) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Thu Dec 15 03:12:57 2011 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 14 Dec 2011 18:12:57 -0800 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: <201112142308.pBEN8nOZ015677@theraft.openend.se> References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <201112142308.pBEN8nOZ015677@theraft.openend.se> Message-ID: On Wed, Dec 14, 2011 at 3:08 PM, Laura Creighton 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 From david at handysoftware.com Thu Dec 15 03:20:21 2011 From: david at handysoftware.com (David Handy) Date: Wed, 14 Dec 2011 21:20:21 -0500 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> Message-ID: <20111215022021.GA23991@blackbeauty> On Wed, Dec 14, 2011 at 08:59:58PM -0400, Andre Roberge wrote: > Personally, I find both the if/else and the try/except much easier to > remember, and slightly easier to read than the one-liner. > > Furthermore, if one is interested in performance, it appears that the > if/else approach is *always* faster than the one-liner. When exceptions > are rarely raised, then the try/except approach is the fastest. Below are > the results from a quick test to compare the efficiency of the three cases, > followed by the code. This is using Python 2.7 on a fairly old computer. > > Andr? (Snipped Andr?'s code and results.) Thanks for the benchmark! For readability, my very favorite is to use defaultdict, in Python since version 2.5: from collections import defaultdict d = defaultdict(int) d[k] += 1 I added a defaultdict case to Andr?'s benchmark. It definitely beats setdefault and is competitive with both try/except and if/else. This was also run using Python 2.7 on my very slow notebook PC. David H =============================== 100% new keys setdefault: 0.821501894794 defaultdict: 0.96327996994 try/except: 3.30088125725 if/else: 0.400257295271 -------------------------------------------------- 10% new keys setdefault: 1.07847561631 defaultdict: 0.656087296011 try/except: 0.980378791159 if/else: 0.600138006367 -------------------------------------------------- 1% new keys setdefault: 1.08054654991 defaultdict: 0.604530464067 try/except: 0.711149322051 if/else: 0.605315759405 -------------------------------------------------- 0.1% new keys setdefault: 0.848571815692 defaultdict: 0.395037078735 try/except: 0.482041712005 if/else: 0.570016859685 =============================== from timeit import Timer print "100% new keys\n" print 'setdefault:\t', t = Timer(""" d = {} for i in range(1000): d[i] = d.get(i, 0) + 1 """) print t.timeit(number=1000) print 'defaultdict:\t', t = Timer(""" d = defaultdict(int) for i in range(1000): d[i] += 1 """, setup='from collections import defaultdict') print t.timeit(number=1000) print 'try/except:\t', t = Timer(""" d = {} for i in range(1000): try: d[i] += 1 except KeyError: d[i] = 1 """) print t.timeit(number=1000) print 'if/else:\t', t = Timer(""" d = {} for i in range(1000): if i in d: d[i] += 1 else: d[i] = 1 """) print t.timeit(number=1000) print "-"*50 print "10% new keys" print 'setdefault:\t', t = Timer(""" d = {} for i in range(1000): k = i % 100 d[k] = d.get(k, 0) + 1 """) print t.timeit(number=1000) print 'defaultdict:\t', t = Timer(""" d = defaultdict(int) for i in range(1000): k = i % 100 d[k] += 1 """, setup='from collections import defaultdict') print t.timeit(number=1000) print 'try/except:\t', t = Timer(""" d = {} for i in range(1000): k = i % 100 try: d[k] += 1 except KeyError: d[k] = 1 """) print t.timeit(number=1000) print 'if/else:\t', t = Timer(""" d = {} for i in range(1000): k = i % 100 if i in d: d[k] += 1 else: d[k] = 1 """) print t.timeit(number=1000) print "-"*50 print "1% new keys\n" print 'setdefault:\t', t = Timer(""" d = {} for i in range(1000): k = i % 10 d[k] = d.get(k, 0) + 1 """) print t.timeit(number=1000) print 'defaultdict:\t', t = Timer(""" d = defaultdict(int) for i in range(1000): k = i % 10 d[k] += 1 """, setup='from collections import defaultdict') print t.timeit(number=1000) print 'try/except:\t', t = Timer(""" d = {} for i in range(1000): k = i % 10 try: d[k] += 1 except KeyError: d[k] = 1 """) print t.timeit(number=1000) print 'if/else:\t', t = Timer(""" d = {} for i in range(1000): k = i % 10 if i in d: d[k] += 1 else: d[k] = 1 """) print t.timeit(number=1000) print "-"*50 print "0.1% new keys\n" print 'setdefault:\t', t = Timer(""" d = {} for i in range(1000): d[1] = d.get(1, 0) + 1 """) print t.timeit(number=1000) print 'defaultdict:\t', t = Timer(""" d = defaultdict(int) for i in range(1000): d[1] += 1 """, setup='from collections import defaultdict') print t.timeit(number=1000) print 'try/except:\t', t = Timer(""" d = {} for i in range(1000): try: d[1] += 1 except KeyError: d[1] = 1 """) print t.timeit(number=1000) print 'if/else:\t', t = Timer(""" d = {} for i in range(1000): if 1 in d: d[1] += 1 else: d[1] = 1 """) print t.timeit(number=1000) From lac at openend.se Thu Dec 15 04:38:14 2011 From: lac at openend.se (Laura Creighton) Date: Thu, 15 Dec 2011 04:38:14 +0100 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: Message from kirby urner of "Wed, 14 Dec 2011 18:12:57 PST." References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <201112142308.pBEN8nOZ015677@theraft.openend.se> Message-ID: <201112150338.pBF3cEwY010265@theraft.openend.se> 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 From kirby.urner at gmail.com Thu Dec 15 08:01:54 2011 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 14 Dec 2011 23:01:54 -0800 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: <201112150338.pBF3cEwY010265@theraft.openend.se> References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <201112142308.pBEN8nOZ015677@theraft.openend.se> <201112150338.pBF3cEwY010265@theraft.openend.se> Message-ID: On Wed, Dec 14, 2011 at 7:38 PM, Laura Creighton 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 From lac at openend.se Thu Dec 15 14:05:11 2011 From: lac at openend.se (Laura Creighton) Date: Thu, 15 Dec 2011 14:05:11 +0100 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: Message from kirby urner of "Wed, 14 Dec 2011 23:01:54 PST." References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <201112142308.pBEN8nOZ015677@theraft.openend.se> <201112150338.pBF3cEwY010265@theraft.openend.se> Message-ID: <201112151305.pBFD5BkA017525@theraft.openend.se> 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: see: http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.html 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 From aharrin at luc.edu Thu Dec 15 17:00:21 2011 From: aharrin at luc.edu (Andrew Harrington) Date: Thu, 15 Dec 2011 10:00:21 -0600 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: <201112151305.pBFD5BkA017525@theraft.openend.se> References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <201112142308.pBEN8nOZ015677@theraft.openend.se> <201112150338.pBF3cEwY010265@theraft.openend.se> <201112151305.pBFD5BkA017525@theraft.openend.se> Message-ID: I'm not sure we are clear on the audience here. I use Python in teaching in different situations. For the newbie course with my Hands-on Python Tutorial, the main idea is an intro to creative programming, where many students will not get to anything more advanced. Python is a great vehicle, but my emphasis is not on how much of the language an advanced programmer is going to use. The dict get method is not high on my list in the newbie class. In that situation I would be drawn to the if key in ... syntax. Thanks to Andre for his practical data. Getting real data like that fits in two situations: 1. In a production situation where you need speed now, and you know your environment. 2. Teaching about the *idea* of timing and optimization (knowing that what is optimal now, may not be in the future) Neither of these apply if you are just doing an intro to basic logical concepts in programming. When I use Python for my upper level cryptography course, I push way more advanced approaches. Andy On Thu, Dec 15, 2011 at 7:05 AM, Laura Creighton wrote: > 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: > > > see: > http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.html > 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 > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -- 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 at luc.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Thu Dec 15 17:25:08 2011 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 15 Dec 2011 08:25:08 -0800 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: <201112151305.pBFD5BkA017525@theraft.openend.se> References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <201112142308.pBEN8nOZ015677@theraft.openend.se> <201112150338.pBF3cEwY010265@theraft.openend.se> <201112151305.pBFD5BkA017525@theraft.openend.se> Message-ID: On Thu, Dec 15, 2011 at 5:05 AM, Laura Creighton wrote: << snip >> > We're going to have to disagree about this one being 'just right' then. > That's OK. Another attitude / realization I tried to get across in the top thread of my post is: schools of thought exist within the Python community. "you'll find some polarization among Pythonistas about whether this is good style" I said. "Polarization" is a good word because we know you can't have left without right, up without down -- they define one another. To take another probably less controversial example, I believe PEP8 or one of those encourages always triple quoting docstrings. If I notice students making assertions like "doctstrings must be triple quoted" I go: """no, you *may* consistently always triple quote even single-lined strings, but unless you have those embedded linebreaks, "single quoted docstrings" are not an impossibility -- not a syntax error, not an oxymoron""" (that's a paraphrase; sounding more literal given I'm not plowing through at high speed here). I'm guessing few of us here always triple quote our docstrings. > > with atomic: > ? ? > > see: http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.html > for more details. > This whole discussion was enlightening / educational, re additions to core Python. I'm tempted to change the subject line and do a branch on this. A proposal consistent with a permanent moratorium would be: yes, many dialects of Python, variants of Core, include the "with atomic" syntax, and you'll want one of those if doing multi-core programming -- unless of course you want to try PythonX by the team at Y, still experimental but.... etc. In other words, just because Core Python is innocent of the multi-core environment, doesn't mean we can't have five Not-Core Pythons that deal with it intelligently. Core Python becomes frozen, a kind of fossil, but there's just the one of them, the superclass. Then you have subclasses of Python-the-language that inherit and hearken back, but don't claim themselves to be Core anymore. No more fights. Just Diversity. You might see where I'm going with this: a version of Python with all keywords in Farsi for example. It's actually Core but with this one change. Rather than say we're running it through a translator, we're saying we have at least 300 new Pythons by the end of 2015, each in a different unicode language (when it comes to keywords). Of course many would decry this availability of multi- language Pythons and say it detracts from the universal readability of the One ASCII / English Core Version. But that's jumping the gun. Maybe only a tiny ethnic subculture of Farsi speakers use the Farsi one and so on, which the super-vast majority continue with the English core. So what? I'm just saying: it'd be useful to have the idea of "dialects" or "versions" well developed on many axes, not just one-core / multi-core. Kirby From kirby.urner at gmail.com Thu Dec 15 18:09:07 2011 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 15 Dec 2011 09:09:07 -0800 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <201112142308.pBEN8nOZ015677@theraft.openend.se> <201112150338.pBF3cEwY010265@theraft.openend.se> <201112151305.pBFD5BkA017525@theraft.openend.se> Message-ID: On Thu, Dec 15, 2011 at 8:00 AM, Andrew Harrington wrote: > I'm not sure we are clear on the audience here. ?I use Python in teaching in > different situations. ? For the newbie course with my Hands-on Python > Tutorial, the main idea is an intro to creative programming, where many > students will not get to anything more advanced. ?Python is a great vehicle, > but my emphasis is not on how much of the language an advanced programmer is > going to use. ?The dict get method is not high on my list in the newbie > class. ?In that situation I would be drawn to the ? ?if key in ... syntax. > This is along a really steep climb, almost vertical in some sections. After 16 lessons ending in an ASCII histogram, plotting word lengths from the Declaration of Independence, they're in the world of unittest and GUI programming with Tk, SQL. By the 3rd module (batch of lessons) they're through regular expressions, command line parsing. Multi-threading and multi-process spawning come later, towards the end. The first Dog class with dog instances in Lesson 14, first module. @properties in 3rd module, decorators more generally in last. > Thanks to Andre for his practical data. ?Getting real data like that fits in > two situations: > > In a production situation where you need speed now, and you know your > environment. > Teaching about the *idea* of timing and optimization (knowing that what is > optimal now, may not be in the future) > timeit module and profile module introduced in fourth batch of lessons. I'm working the first three batches only at the moment, on alternate days. Been doing it about a year now. > Neither of these apply if you are just doing an intro to basic logical > concepts in programming. > > When I use Python for my upper level cryptography course, I push way more > advanced approaches. > > Andy > We could do a lot more with cryptography and I have lots of code in the wings that does more with a Tractor class. That's the topic of my Standard Lightning Talk for social occasions and meetups in Pythonia (Python World). For example the CropCircle subclass of Tractor does a Mandelbrot. Complex numbers have to do with some of these large number multiplication algorithms used in RSA. But I do more with RSA in my Portland pilots. There's no automated grading at all and you just keep doing the assignments until you pass them -- can take double digit numbers of tries in some cases, especially with programs. What few multiple choice questions there are (very few) are hand graded. Our boss went to Russia and realized the students there were getting a wholly different education that was non-mechanized and required more thinking on your feet. This crystallized the "active learning" or "make math" approach. He thinks Americans don't know dick for the most part, are basically faking it 24/7 (I would have to agree, especially when it comes to Washington DC people and at Harvard). It's funny to watch students tuck little comments and remarks in their quizzes at first, wondering if "the machine" will notice. Yet there is no machine, just a dedicated staff spread out in different cities, using a shared hub in Illinois (the management is in Sebastopol, the hardware in Illinois). Kirby Erratum >>> print('''\ If I notice students making assertions like "doctstrings must be triple quoted" I go: """no, you *may* consistently always triple quote even single-lined strings, but unless you have those embedded linebreaks, "single quoted docstrings" are not an impossibility -- not a syntax error, not an oxymoron""" (that's a paraphrase; sounding more literal given I'm not plowing through at high speed here).'''.replace("literal", "literary")) If I notice students making assertions like "doctstrings must be triple quoted" I go: """no, you *may* consistently always triple quote even single-lined strings, but unless you have those embedded linebreaks, "single quoted docstrings" are not an impossibility -- not a syntax error, not an oxymoron""" (that's a paraphrase; sounding more literary given I'm not plowing through at high speed here). From christian.mascher at gmx.de Thu Dec 15 19:18:44 2011 From: christian.mascher at gmx.de (Christian Mascher) Date: Thu, 15 Dec 2011 19:18:44 +0100 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> Message-ID: <4EEA3A04.9010403@gmx.de> >> On the other hand, >> res_dict[ext] = res_dict.get(ext, 0) + 1 >> > 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 haven't done much coding in Python lately. And I found this much more readable than the .get method which I forgot about. I positively didn't understand the oneliner just by reading it over and over again. Of course I could easily have opened idle and looked up the .get method online (or looked in a manual). The really good thing about Python is that so much of the core language doesn't surprise you. One is able to write code which is understandable even to people with very little experience or to yourself after not coding in Python for years. Nobody has to write such clear-cut code all the time, but at least it is possible with very little effort. Christian From kirby.urner at gmail.com Thu Dec 15 19:41:42 2011 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 15 Dec 2011 10:41:42 -0800 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: <4EEA3A04.9010403@gmx.de> References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <4EEA3A04.9010403@gmx.de> Message-ID: On Thu, Dec 15, 2011 at 10:18 AM, Christian Mascher wrote: > >>> On the other hand, >>> ? ? res_dict[ext] = res_dict.get(ext, 0) + 1 >>> >> 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 haven't done much coding in Python lately. And I found this much more > readable than the .get method which I forgot about. I positively didn't > understand the oneliner just by reading it over and over again. > I might try something like this to make it clearer. I can cut and paste such code snippets from my Replies archive (another way to save time -- I edit from a pool and splice in what's custom). This goes off the common cartoon convention of a prisoner putting one stroke on a wall for each day in prison. Here we use a string of "bars" (apropos). >>> def strokes(prisoner, days=1): cells[prisoner] = cells.get( prisoner, "") + "|"*days >>> cells = {} >>> strokes("Mandela") >>> cells {'Mandela': '|'} >>> strokes("Aung San Suu Kyi",10) >>> cells {'Aung San Suu Kyi': '||||||||||', 'Mandela': '|'} >>> strokes("Mandela") >>> strokes("Mandela") >>> cells {'Aung San Suu Kyi': '||||||||||', 'Mandela': '|||'} What's also important is cells is global and need not be declared global in strokes for this to work. That's a stumbling block in Lesson 12 or one of those, I forget which exactly, and is a subtle aspect of Python: you can poke items into a global dict from a more local scope, just not rebind the name to some other object. > Of course I could easily have opened idle and looked up the .get method > online (or looked in a manual). > Our you could wake up in the morning and have a bunch of fresh feedback from a faithful mentor, who points stuff out that passes for "accepted holes" out there, but you could use to your advantage in a job interview. You know about dict.get, wow. Hey, it's a competitive market out there. I think we should have a whole thread on defaultdict though. I think we should also expose students to importing django not to run a web service at first, but to gain access to some low-level goodies like the ordered dict. Treat zope the same way -- just something to import and "make math" with (interactive console in CR or Eclipse in the current working versions). > The really good thing about Python is that so much of the core language > doesn't surprise you. One is able to write code which is understandable even > to people with very little experience or to yourself after not coding in > Python for years. Nobody has to write such clear-cut code all the time, but > at least it is possible with very little effort. > Yes, which is why Python is favored by the scientific community. It's powerful, thanks to libraries like numpy and visual, comes with pyMol and sciPy and like that, and you don't have to turn yourself into some compsci geek to use it, just hack away and it makes sense, does what you expect, fits your brain. Python is great because now the physics team doesn't have to sit around waiting for some back office "programming team" to do some slow-poking away off camera. "No, we can do it ourselves!" -- the sense Python inspires. I'm all for this. As a long time math reformer, I've taken the line that forcing Texas Instruments calculators down the throats of K-12ers while denying them access to free open source options such as Python, is malpractice in the first degree and all student loans should be forgiven, based on what was done to you people, and how you're unemployable now, living in a tent someplace. Dang. Wouldn't it have been nice if the teachers had listened. Kirby > Christian > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig From carl at free.org.nz Mon Dec 19 23:19:49 2011 From: carl at free.org.nz (Carl Cerecke) Date: Tue, 20 Dec 2011 11:19:49 +1300 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: <4EEA3A04.9010403@gmx.de> References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <4EEA3A04.9010403@gmx.de> Message-ID: I know I'm late to this discussion, but I tend to use something like: if ext not in res_dict: res_dict[ext] = 0 res_dict[ext] += 1 Cheers, Carl. On 16 December 2011 07:18, Christian Mascher wrote: > > On the other hand, >>> res_dict[ext] = res_dict.get(ext, 0) + 1 >>> >>> 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 haven't done much coding in Python lately. And I found this much more > readable than the .get method which I forgot about. I positively didn't > understand the oneliner just by reading it over and over again. > > Of course I could easily have opened idle and looked up the .get method > online (or looked in a manual). > > The really good thing about Python is that so much of the core language > doesn't surprise you. One is able to write code which is understandable > even to people with very little experience or to yourself after not coding > in Python for years. Nobody has to write such clear-cut code all the time, > but at least it is possible with very little effort. > > Christian > > ______________________________**_________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/**mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vceder at gmail.com Mon Dec 19 23:27:13 2011 From: vceder at gmail.com (Vern Ceder) Date: Mon, 19 Dec 2011 16:27:13 -0600 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <4EEA3A04.9010403@gmx.de> Message-ID: On Mon, Dec 19, 2011 at 4:19 PM, Carl Cerecke wrote: > I know I'm late to this discussion, but I tend to use something like: > > if ext not in res_dict: > res_dict[ext] = 0 > > res_dict[ext] += 1 > > Cheers, > Carl. > > Hi Carl, Actually, I often do that as well. I'm not sure it's the most efficient, but it does make quite clear what you are doing. Cheers, Vern > On 16 December 2011 07:18, Christian Mascher wrote: > >> >> On the other hand, >>>> res_dict[ext] = res_dict.get(ext, 0) + 1 >>>> >>>> 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 haven't done much coding in Python lately. And I found this much more >> readable than the .get method which I forgot about. I positively didn't >> understand the oneliner just by reading it over and over again. >> >> Of course I could easily have opened idle and looked up the .get method >> online (or looked in a manual). >> >> The really good thing about Python is that so much of the core language >> doesn't surprise you. One is able to write code which is understandable >> even to people with very little experience or to yourself after not coding >> in Python for years. Nobody has to write such clear-cut code all the time, >> but at least it is possible with very little effort. >> >> Christian >> >> ______________________________**_________________ >> Edu-sig mailing list >> Edu-sig at python.org >> http://mail.python.org/**mailman/listinfo/edu-sig >> > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > -- Vern Ceder vceder at gmail.com, vceder at dogsinmotion.com The Quick Python Book, 2nd Ed - http://bit.ly/bRsWDW -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Mon Dec 19 23:36:20 2011 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 19 Dec 2011 14:36:20 -0800 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <4EEA3A04.9010403@gmx.de> Message-ID: > > if ext not in res_dict: > res_dict[ext] = 0 > > res_dict[ext] += 1 > > Cheers, > Carl. Truth be told, I do that too a lot. After being shown all the options, let the programmer choose. However, in a learning situation, it's about showing these options, including with the dict.get method. These patterns need not be visited in a vaccuum, i.e. it's quite often that one needs a default returned (and not an error message) if such and such is the case, a pre-existing value otherwise. This pattern is not confined to dicts of course. What I will correct though, as an example of what I consider a mistake, is like: for word in wordlist: if word == "fox": result = True else: result = False in place of result = "fox" in wordlist Note every alternative weighs equally. Laura things thedict [thekey] = thedict.get( thekey, 0) + 1 is starting to get too fancy / clever / tricky and detracts from readability (a shared value). I would agree there are honest disagreements about what's "too clever" (I think using a builtin method for what it's for should be shown, but then possibly avoided). However, coding a loop to go through a list looking for a match, rather than letting the keyword "in" do the work, strikes me as "poor Python" that should be tightened up to pass muster. I don't think an "anything goes" attitude works. Like in sports, some moves win more points and when you hire a coach, it's to develop best practices, not to prove how you're free of all idioms. Kirby From vceder at gmail.com Mon Dec 19 23:39:25 2011 From: vceder at gmail.com (Vern Ceder) Date: Mon, 19 Dec 2011 16:39:25 -0600 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <4EEA3A04.9010403@gmx.de> Message-ID: On Mon, Dec 19, 2011 at 4:36 PM, kirby urner wrote: > However, coding a loop to go through a list looking for a match, > rather than letting the keyword "in" do the work, strikes me as "poor > Python" that should be tightened up to pass muster. > > I absolutely agree on this one... > I don't think an "anything goes" attitude works. Like in sports, some > moves win more points and when you hire a coach, it's to develop best > practices, not to prove how you're free of all idioms. +1 > > Kirby > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -- Vern Ceder vceder at gmail.com, vceder at dogsinmotion.com The Quick Python Book, 2nd Ed - http://bit.ly/bRsWDW -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirby.urner at gmail.com Mon Dec 19 23:39:33 2011 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 19 Dec 2011 14:39:33 -0800 Subject: [Edu-sig] Using try / except: any stipulations against routine use? In-Reply-To: References: <1C792499-4884-459B-8A52-FE59495B859C@freudenbergs.de> <4EEA3A04.9010403@gmx.de> Message-ID: > Note every alternative weighs equally. ?Laura things ?thedict [thekey] > = thedict.get( thekey, 0) + 1 is starting to get too fancy / clever / > tricky and detracts from readability (a shared value). > "Not every alternative weighs equally. Laura thinks..." (fixing errors)... Quoting from Python scripture, I'm not saying much more than (or much different from): """ There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. """ -- from import this Kirby From kirby.urner at gmail.com Sat Dec 24 07:27:19 2011 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 23 Dec 2011 22:27:19 -0800 Subject: [Edu-sig] a Python title I'd like to see.... (idle fantasy) Message-ID: 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 From mamckenna at sch.ci.lexington.ma.us Sat Dec 24 12:00:25 2011 From: mamckenna at sch.ci.lexington.ma.us (Marianne McKenna) Date: Sat, 24 Dec 2011 06:00:25 -0500 Subject: [Edu-sig] Edu-sig Digest, Vol 101, Issue 10 Message-ID: I will be out of the office today. If you need immediate help please contact the computer center. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charras at me.com Sat Dec 24 19:55:09 2011 From: charras at me.com (Guido Carballo-Guerrero) Date: Sat, 24 Dec 2011 16:55:09 -0200 Subject: [Edu-sig] Edu-sig Digest, Vol 101, Issue 10 In-Reply-To: References: Message-ID: Kirby; I'll be waiting for this book. Sounds very interesting. Guido On Dec 24, 2011, at 9:00 AM, edu-sig-request at python.org wrote: > Send Edu-sig mailing list submissions to > edu-sig at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/edu-sig > or, via email, send a message with subject or body 'help' to > edu-sig-request at python.org > > You can reach the person managing the list at > edu-sig-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Edu-sig digest..." > > > Today's Topics: > > 1. a Python title I'd like to see.... (idle fantasy) (kirby urner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 23 Dec 2011 22:27:19 -0800 > From: kirby urner > To: edu-sig at python.org > Subject: [Edu-sig] a Python title I'd like to see.... (idle fantasy) > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > 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 > > > ------------------------------ > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > > End of Edu-sig Digest, Vol 101, Issue 10 > **************************************** From mamckenna at sch.ci.lexington.ma.us Sun Dec 25 12:00:20 2011 From: mamckenna at sch.ci.lexington.ma.us (Marianne McKenna) Date: Sun, 25 Dec 2011 06:00:20 -0500 Subject: [Edu-sig] Edu-sig Digest, Vol 101, Issue 11 Message-ID: I will be out of the office today. If you need immediate help please contact the computer center. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mamckenna at sch.ci.lexington.ma.us Mon Dec 26 12:00:20 2011 From: mamckenna at sch.ci.lexington.ma.us (Marianne McKenna) Date: Mon, 26 Dec 2011 06:00:20 -0500 Subject: [Edu-sig] Edu-sig Digest, Vol 101, Issue 12 Message-ID: I will be out of the office today. If you need immediate help please contact the computer center. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mamckenna at sch.ci.lexington.ma.us Tue Dec 27 12:00:23 2011 From: mamckenna at sch.ci.lexington.ma.us (Marianne McKenna) Date: Tue, 27 Dec 2011 06:00:23 -0500 Subject: [Edu-sig] Edu-sig Digest, Vol 101, Issue 13 Message-ID: I will be out of the office today. If you need immediate help please contact the computer center. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mamckenna at sch.ci.lexington.ma.us Wed Dec 28 12:00:18 2011 From: mamckenna at sch.ci.lexington.ma.us (Marianne McKenna) Date: Wed, 28 Dec 2011 06:00:18 -0500 Subject: [Edu-sig] Edu-sig Digest, Vol 101, Issue 14 Message-ID: I will be out of the office today. If you need immediate help please contact the computer center. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mamckenna at sch.ci.lexington.ma.us Thu Dec 29 12:00:24 2011 From: mamckenna at sch.ci.lexington.ma.us (Marianne McKenna) Date: Thu, 29 Dec 2011 06:00:24 -0500 Subject: [Edu-sig] Edu-sig Digest, Vol 101, Issue 15 Message-ID: I will be out of the office today. If you need immediate help please contact the computer center. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpaul213 at gmail.com Thu Dec 29 16:40:14 2011 From: mpaul213 at gmail.com (michel paul) Date: Thu, 29 Dec 2011 07:40:14 -0800 Subject: [Edu-sig] Edu-sig Digest, Vol 101, Issue 15 In-Reply-To: References: Message-ID: Hi Marianne, We need your help. We can't do this alone. Could you please contact your computer center and ask them to show you how to change your email preferences? Thanks from all Python edu-siggers. On Thu, Dec 29, 2011 at 3:00 AM, Marianne McKenna < mamckenna at sch.ci.lexington.ma.us> wrote: > ** ** > I will be out of the office today. If you need immediate help please > contact the computer center. Thanks. > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > -- ================================== "What I cannot create, I do not understand." - Richard Feynman ================================== "Computer science is the new mathematics." - Dr. Christos Papadimitriou ================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From mamckenna at sch.ci.lexington.ma.us Fri Dec 30 12:00:22 2011 From: mamckenna at sch.ci.lexington.ma.us (Marianne McKenna) Date: Fri, 30 Dec 2011 06:00:22 -0500 Subject: [Edu-sig] Edu-sig Digest, Vol 101, Issue 16 Message-ID: I will be out of the office today. If you need immediate help please contact the computer center. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mamckenna at sch.ci.lexington.ma.us Sat Dec 31 12:00:36 2011 From: mamckenna at sch.ci.lexington.ma.us (Marianne McKenna) Date: Sat, 31 Dec 2011 06:00:36 -0500 Subject: [Edu-sig] Edu-sig Digest, Vol 101, Issue 17 Message-ID: I will be out of the office today. If you need immediate help please contact the computer center. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: