On Sun, Oct 4, 2009 at 2:44 PM, horos11 <horo...@gmail.com> wrote: > >> >> > Thanks for the info, but a couple of points: >> >> > 1. it wasn't meant to be production code, simply a way to teach >> > python. >> >> Speaking as someone who does teach Python, "Ew, no!" If you start by >> teaching people bad habits, every educator who comes along afterwards >> will curse your name. That includes teaching yourself. >> >> -- >> Rhodri James *-* Wildebeest Herder to the Masses > > No offense, but I disagree. By programming without regards to pre- > existing style or convention I learned far more than I otherwise would > have if I had simply mimicked someone else.
Don't teach newbies bad idiom. > And I still think that unbridled assignment - especially assignment > that can change the operational semantics of surrounding terms, at a > distance no less - is a horrid thing. That's opinion. Python allows you to shoot yourself in the foot. It's on us as programmers to be able to grok our code well enough to prevent nasty errors. "With great power comes great responsibility." and all that. > It gets even worse because the way python handles assignment. To go > back to my original program: why isn't the state variable that I > defined local to that 'if' loop? There's no such thing as an "if loop". The only answer to your question is "that's the way it is"... or, equivalently, "that's the way Guido made it." Check out "Python Scopes and Name Spaces" http://www.python.org/doc/2.2/tut/node11.html#SECTION0011200000000000000000 > while len(dq): > > ... > if curstate.is_answer(): > ... > else: > for state in ... > > > The answer? Because you can't explicitly declare it. It therefore > looks globally, finds the 'class state:' statement, and runs with it. > I should be able to say: > > for my state in curstate.next_states(): > > to show explicitly what I'm doing. You can, you just have to be careful not to "shadow" some other name in your namespace(s). Again, python makes a trade off between "babysitting" the programmer on the one hand vs. raw flexibility on the other. > Anyways, maybe I got off to a bad start, but I'm a bit leery of the > language. In my estimation it's trying to be 'too clever by half', and > this coming from a veteran bash/perl programmer. I mean, free form is > one thing, but too much of a good thing can be harmful to your > programming health. Maybe PyChecker or PyLint will help, I don't know. I think if you let python seep into your thinking you'll eventually come to love it. It /IS/ very (too) clever, but the cleverness is (IMHO) spent on getting out of your way, rather than trying to insure you're doing things right. Eric Raymond has a great article where he talks about learning python: http://www.linuxjournal.com/article/3882 "My second [surprise] came a couple of hours into the project, when I noticed (allowing for pauses needed to look up new features in Programming Python) I was generating working code nearly as fast as I could type. When I realized this, I was quite startled. An important measure of effort in coding is the frequency with which you write something that doesn't actually match your mental representation of the problem, and have to backtrack on realizing that what you just typed won't actually tell the language to do what you're thinking. An important measure of good language design is how rapidly the percentage of missteps of this kind falls as you gain experience with the language." I can vouch for this: I can routinely write 200~300 lines of python code and have it run flawlessly the first time. This doesn't happen every time, but it's the norm rather than the exception. Give it a chance. It's (IMHO) /beautiful/. Happy hacking, ~Simon > Ed > > ( > ps - an aside, but what was the rationale behind only displaying one > error at a time on trying to run a script? I typically like to run a > compilation phase inside my editor (vim), get a list of errors, and > then go to each one and fix them. I dunno the rationale, but the mechanism is uncaught exceptions propagate up and halt the interpreter. Since nothing keeps going after an uncaught exception, there's nothing there to report the next error. > And how do you just check a script's syntax without running it > anyways? Just run it. ;] FWIW, use the interactive interpreter (or IPython variant) to play with the language until you learn the syntax well enough not to write bad syntax. For me anyway, that was the best/fastest way to learn it. -- http://mail.python.org/mailman/listinfo/python-list
