Alexander Zatvornitskiy wrote:
> ÐÑÐÐÐÑ Peter!
>
> 31 ÑÐÐÐÑÑ 2005 Ð 09:09, Peter Otten Ð ÑÐÐÐÐ ÐÐÑÑÐÐ Ð All
> ÐÐÑÐÐ:
> PO> pychecker may help you find misspelled variable names. You have to
> PO> move the code into a function, though:
>
> PO> $ cat epsilon.py
> ...skipped...
> PO> $ pychecker epsilon.py
> PO> epsilon.py:6: Local variable (epselon) not used
>
> Well, I can change it a little to pass this check. Just add "print
> epselon" line.
You are now on a slippery slope. I'd rather think of ways to write my code
in a way for it to succeed or at least fail in an obvious way. I don't
consider a scenario likely where you both misspell a name nearly as often
as you write it correctly, and do that in a situation where the program
enters an infinite loop instead of just complaining with an exception,
which is by far the most likely reaction to a misspelt name.
> I think if as soon as I will make such error, I will write special
> checker. It will take code like this:
>
> def loop():
> #var S,epsilon
> epsilon=0
> S=0
> while epsilon<10:
> S=S+epsilon
> epselon=epsilon+1
> print S
Code not written is always errorfree, and in that spirit I'd rather strive
to write the function more concisely as
def loop2():
s = 0
for delta in range(10):
s += delta
print s
This illustrates another problem with your approach: would you have to
declare globals/builtins like range(), too?
> Such checker will say "error:epselon is not declared!" if I will use
> something not declared. If everything is ok, it will call pychecker.
> Simple and tasty, isn't it?
That your program compiles in a somewhat stricter environment doesn't mean
that it works correctly.
> Of cource, it may be difficult to handle fields of classes:
> MyClass.epsElon=MyClass.epsilon+1
MyClass.epsilon += 1
reduces the risk of a spelling error by 50 percent. I doubt that variable
declarations reduce the likelihood of erroneous infinite loops by even 5
percent.
> but it is solvable, I think. What do you think, is it a good idea?
I suggested pychecker more as a psychological bridge while you gain trust in
the Python way of ensuring reliable programs, i. e. writing small and
readable functions/classes that do one thing well and can easily be tested.
Administrative overhead -- as well as excessive comments -- only serve to
bury what is actually going on.
I guess that means no, not a good idea.
On the other hand, taking all names used in a function and looking for
similar ones, e. g. by calculating the Levenshtein distance, might be
worthwhile...
Peter
--
http://mail.python.org/mailman/listinfo/python-list
