469,352 Members | 1,721 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,352 developers. It's quick & easy.

Spelling mistakes!

I've spent hours trying to find a bug that was a simple spelling
mistake.

in an init method I declare a variable self.someLongName

later in a different method of the class I use
self.sumLongName
Now I really meant self.someLongName.
In fact I don't want a variable called sumLongName.
Frankly how are you ever to know if this type of error is occuring?

Jan 6 '06 #1
53 3499
KraftDiner wrote:
Frankly how are you ever to know if this type of error is occuring?


By the traceback:

modelnine@phoenix ~ $ python
Python 2.4.2 (#1, Dec 22 2005, 17:27:39)
[GCC 4.0.2 (Gentoo 4.0.2-r2, pie-8.7.8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
class x(object): .... def __init__(self):
.... self.somename = "hello"
.... def somemethod(self):
.... print self.sumname
.... a = x()
a.somemethod() Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 5, in somemethod
AttributeError: 'x' object has no attribute 'sumname'


AttributeError describes just this. And please don't start the war on how
much better compiled languages are because they catch this kind of error at
compile time. They simply are not.

--- Heiko.
Jan 6 '06 #2
VBScript allows you to specify that variable names be declared. I used
to think this was good - until I realised that Python allows you to
dynamically assign attributes in namespaces using all sorts of tricks.

(Setattr, using __dict__ etc).

It's just not possible with Python. Rarely happens to me in practise
and is easy to fix.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Jan 6 '06 #3
try this:

class x(object):
def __init__(self):
self.someName = "hello"
def someMethod(self):
self.sumName = "bye"

find that bug.

Jan 6 '06 #4
KraftDiner wrote:
I've spent hours trying to find a bug that was a simple spelling
mistake.

in an init method I declare a variable self.someLongName

later in a different method of the class I use
self.sumLongName
Now I really meant self.someLongName.
In fact I don't want a variable called sumLongName.
Frankly how are you ever to know if this type of error is occuring?


PyChecker and PyLint sound like the perfect remedy to this issue (I know
one of them is able to warn you if you *create* an attribute outside of
__init__, maybe both are but at least one of them is)

I just run them when I save my files, they don't take long and even
though the default configuration is *extremely* annoying (especially
PyLint's, it generates heaps of warnings) once configured to one's need,
they're extremely valuable for both personal and team development.
Jan 6 '06 #5
KraftDiner wrote:
try this:

class x(object):
def __init__(self):
self.someName = "hello"
def someMethod(self):
self.sumName = "bye"

find that bug.


Write a test for each method before writing the method.

Write the code once; read it critically (at least) twice.

If you find that too difficult, use a different programming language
(one in which you have to declare every variable) and become less
productive.

A.

Jan 6 '06 #6
KraftDiner wrote:
try this:

class x(object):
def __init__(self):
self.someName = "hello"
def someMethod(self):
self.sumName = "bye"

find that bug.


You forgot to include unit tests for someMethod(). Those would have
caught the bug.

The reality is that if you aren't doing unit testing, you aren't
catching other bugs either, bugs which aren't caught by the compile-time
tests in other languages and which aren't caught by PyChecker or PyLint
either. Bugs which are probably much more common than typos like the
above, too.

Still, if you are really bothered by these things frequently, I believe
recipes have been posted in the past which *do* allow you to avoid many
such problems, by declaring the acceptable attribute names somewhere and
using one of Python's many hooks to intercept and check attribute
setting. Check the archives or the CookBook.

-Peter

Jan 6 '06 #7
try this:
class x(object):
def __init__(self):
self.someName = "hello"
def someMethod(self):
self.sumName = "bye" find that bug.


Aside from the other responses (unittests, pychecker/pylint), you might also
consider using __slots__ for new-style classes:

class x(object):
__slots__ = ('someName',)
def __init__(self):
self.someName = "hello"
def someMethod(self):
self.sumName = "bye"

my_x = x()
my_x.someMethod()

When run you will get this output:

Traceback (most recent call last):
File "slot.py", line 9, in <module>
my_x.someMethod()
File "slot.py", line 6, in someMethod
self.sumName = "bye"
AttributeError: 'x' object has no attribute 'sumName'

Skip
Jan 6 '06 #8
On 6 Jan 2006 07:30:41 -0800
"KraftDiner" <bo*******@yahoo.com> wrote:
I've spent hours trying to find a bug that was a simple
spelling mistake.
You're not the first. ;-)
in an init method I declare a variable self.someLongName

later in a different method of the class I use
self.sumLongName
Now I really meant self.someLongName.
In fact I don't want a variable called sumLongName.
Frankly how are you ever to know if this type of error is
occuring?


Both "unit tests" and "interfaces" are useful for catching
simple errors like this one. There is a 'unittest' module
in the Python standard library, and 'interface' modules are
available from the Zope 3 project and PyProtocols, both are
good.

Once you know you have a problem like this (or you've
decided to change a spelling), you can track down the
problem using grep, fix it with sed or use Python itself to
do the job if you really want to.

I once misspelled a name in a set of API methods, which was
very embarrassing (I spelled "fovea" as "fovia"). So then I
had to go through and change it, and report it in as an API
change so that a "patch" became a "minor version upgrade".
Duh. Next time I use a dictionary before freezing an API!

Cheers,
Terry

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Jan 6 '06 #9
On Fri, 06 Jan 2006 17:23:27 -0600, Terry Hancock wrote:
I once misspelled a name in a set of API methods, which was
very embarrassing (I spelled "fovea" as "fovia"). So then I
had to go through and change it, and report it in as an API
change so that a "patch" became a "minor version upgrade".
Duh. Next time I use a dictionary before freezing an API!

Can you please explain what you mean by that? Use a dictionary how?

--
Steven.

Jan 7 '06 #10
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
Duh. Next time I use a dictionary before freezing an API!

Can you please explain what you mean by that? Use a dictionary how?


Use a dictionary by looking up words in it to check the spelling.
Jan 7 '06 #11
> Duh. Next time I use a dictionary before freezing an API!
Can you please explain what you mean by that? Use a dictionary how?


Paul> Use a dictionary by looking up words in it to check the spelling.

I think the most widely spread API misspelling must be "referer", as in the
HTTP_REFERER header in the HTTP spec:

http://en.wikipedia.org/wiki/Referer

In fact, googling for "referer" and "referrer" reports a similar number of
hits, unlike most misspellings.

Skip
Jan 7 '06 #12
On Fri, 06 Jan 2006 17:29:32 -0800, Paul Rubin wrote:
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
> Duh. Next time I use a dictionary before freezing an API!

Can you please explain what you mean by that? Use a dictionary how?


Use a dictionary by looking up words in it to check the spelling.


D'oh! I was thinking a dictionary like {}.
--
Steven.

Jan 7 '06 #13
On Sat, 07 Jan 2006 14:03:10 +1100
"Steven D'Aprano" <st***@REMOVETHIScyber.com.au> wrote:
On Fri, 06 Jan 2006 17:29:32 -0800, Paul Rubin wrote:
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
> Duh. Next time I use a dictionary before freezing an

API! > Can you please explain what you mean by that? Use
a dictionary how?

Use a dictionary by looking up words in it to check the
spelling.


D'oh! I was thinking a dictionary like {}.


Yeah, I meant like Websters', should've been clearer, I
guess, given the venue of this discussion. ;-)

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Jan 7 '06 #14
On Fri, 6 Jan 2006 19:51:22 -0600
sk**@pobox.com wrote:
>> > Duh. Next time I use a dictionary before freezing

>an API!

>> Can you please explain what you mean by that? Use a

>dictionary how?


Paul> Use a dictionary by looking up words in it to
check the spelling.

I think the most widely spread API misspelling must be
"referer", as in the HTTP_REFERER header in the HTTP spec:

http://en.wikipedia.org/wiki/Referer

In fact, googling for "referer" and "referrer" reports a
similar number of hits, unlike most misspellings.


You know, I almost mentioned that myself. Drives me crazy.

One thing I've figured out is that using the full spelling
of a word instead of groovy programmer abbreviations makes
it a lot easier to remember the names of things. Of course,
like everything, that can be taken too far, so I still use
things like "bkg_clr" too. Old habits are hard to break.

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Jan 7 '06 #15
In fact, googling for "referer" and "referrer" reports a similar
number of hits, unlike most misspellings.


Terry> You know, I almost mentioned that myself. Drives me crazy.

Me too. I'm one of those people who, for better or worse, is a good
speller. Words just look right or wrong to me and it bothers me when they
look wrong.

Terry> One thing I've figured out is that using the full spelling
Terry> of a word instead of groovy programmer abbreviations makes
Terry> it a lot easier to remember the names of things. Of course,
Terry> like everything, that can be taken too far, so I still use
Terry> things like "bkg_clr" too. Old habits are hard to break.

I do tend to be a bit brief with my names and recognizing an identifier as
an abbreviation don't bother me the way a misspelled word does. Maybe I've
been using Unix systems for too long with their brief command names like mv
and grep. I prefer not to write big_honkin_long_names any more than I have
to either.

Skip
Jan 7 '06 #16
KraftDiner <bo*******@yahoo.com> wrote:
...
Frankly how are you ever to know if this type of error is occuring?


<http://en.wikipedia.org/wiki/Unit_testing> .
Alex
Jan 7 '06 #17
sk**@pobox.com wrote:
In fact, googling for "referer" and "referrer" reports a similar
>> number of hits, unlike most misspellings.


Terry> You know, I almost mentioned that myself. Drives me crazy.

Me too. I'm one of those people who, for better or worse, is a good
speller. Words just look right or wrong to me and it bothers me when they
look wrong.


What's worse is the closely related problem of British/American
English, though you sort of get used to it after typing
s/colour/color/g or s/serialise/serialize/g for the thousandth time.
The words look wrong to me, but they're correct in the context.

Jan 7 '06 #18
Sam Pointon wrote:
What's worse is the closely related problem of British/American
English, though you sort of get used to it after typing
s/colour/color/g or s/serialise/serialize/g for the thousandth time.
The words look wrong to me, but they're correct in the context.


Hah! Canucks r00l! Most of those words look about equally good to us
most of the time. (And it's not because of the beer!) (But our beer
r00lz too.)

-Peter "Freezing-my-ass-off-in-Uxbridge" Hansen

Jan 7 '06 #19
[sk**@pobox.com]
Aside from the other responses (unittests, pychecker/pylint), you might also
consider using __slots__ for new-style classes:


I've been shouted at for suggesting exactly that! :-)

http://groups.google.com/group/comp....453d925b912917

how-come-aahz-didn't-shout-at-you-ly'yrs,

--
alan kennedy
------------------------------------------------------
email alan: http://xhaus.com/contact/alan
Jan 7 '06 #20
Aside from the other responses (unittests, pychecker/pylint), you
might also consider using __slots__ for new-style classes:


Alan> I've been shouted at for suggesting exactly that! :-)

Maybe Aahz didn't notice my post. The OP sort of seemed like he was pining
for attribute declarations. __slots__ is the closest thing Python has to
them. I don't use them myself (since I've basically avoided new-style
classes so far).

Skip
Jan 7 '06 #21
In article <wb*****************@news.indigo.ie>,
Alan Kennedy <al****@hotmail.com> wrote:
[sk**@pobox.com]

Aside from the other responses (unittests, pychecker/pylint), you might also
consider using __slots__ for new-style classes:


I've been shouted at for suggesting exactly that! :-)

http://groups.google.com/group/comp....453d925b912917

how-come-aahz-didn't-shout-at-you-ly'yrs,


Because I've been busy. I'd been saving Skip's post for when I had
enough time to do it justice, but your URL saves me the trouble. ;-)
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis
Jan 7 '06 #22
Terry Hancock wrote:
One thing I've figured out is that using the full spelling
of a word instead of groovy programmer abbreviations makes
it a lot easier to remember the names of things. Of course,
like everything, that can be taken too far, so I still use
things like "bkg_clr" too.


Yeah, it's a real pain to constantly type "breakage_clear" every time.
:-)

--Scott David Daniels
sc***********@acm.org
Jan 7 '06 #23
On Sat, 07 Jan 2006 08:57:24 -0500, Peter Hansen <pe***@engcorp.com> wrote:

[British/American English]
Hah! Canucks r00l! Most of those words look about equally good to us
most of the time. (And it's not because of the beer!) (But our beer
r00lz too.)


And so does "primairy", "secondairy" and similar "frenchifications" of
English words, to some of you ... I'll think twice before agreeing to
maintain software written by people from Montréal again.

(Fortunately, that software was written in a static programming language.)

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
Jan 8 '06 #24
On Fri, 6 Jan 2006 23:46:42 -0600, sk**@pobox.com <sk**@pobox.com> wrote:
I do tend to be a bit brief with my names and recognizing an identifier as
an abbreviation don't bother me the way a misspelled word does. Maybe I've
been using Unix systems for too long with their brief command names like mv
and grep.


I like to think of it as everybody else having spent too /little/ time with
Unix systems ;-)

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
Jan 8 '06 #25
sk**@pobox.com enlightened us with:
I'm one of those people who, for better or worse, is a good speller.
Words just look right or wrong to me and it bothers me when they
look wrong.


Same here. I have to use code that has "childs" instead of
"children"... I also can't stand "then" vs "than" mixups... And what's
up with using Google to check for spelling? I have a dictionary for
that, works a lot better!

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
Jan 8 '06 #26

Sybren> And what's up with using Google to check for spelling? I have a
Sybren> dictionary for that, works a lot better!

A couple things:

1. It's generally faster than reaching for the dictionary.

2. The hit count for a word and its misspelling gives me some measure of
how the rest of the online English-speaking world thinks that word is
spelled.

3. Some recent words like "podcast" aren't in the now ancient dictionary
on my shelf. Other words have gained new meanings since my
dictionary was published.

Okay, so that's a few things... <wink>

Skip
Jan 8 '06 #27
On Sun, 8 Jan 2006 08:58:48 -0600
sk**@pobox.com wrote:
Sybren> And what's up with using Google to check for spelling? I have a
Sybren> dictionary for that, works a lot better!

A couple things:

1. It's generally faster than reaching for the
dictionary.
But not faster than use a dict server!
Why not just use (e.g.) kdict? That's what I do. It's got to
be at least as accurate as Google, and much more likely to
give me the right answer.
2. The hit count for a word and its misspelling gives
me some measure of
how the rest of the online English-speaking world
thinks that word is spelled.
This is useful for words that don't really exist.
Or rather, that do exist, but are not documented. ;-)
3. Some recent words like "podcast" aren't in the now
ancient dictionary
on my shelf. Other words have gained new meanings
since my dictionary was published.


Same comment -- Google is good as a backup, but I'd much
rather use a dictionary to look up words than a search
engine. Wikipedia is another good resource for newer words,
brand names, jargon, and slang.

BTW, one of the most common programming spelling errors is
"deprecate" versus "depreciate" -- I wonder how many people
actually realize that both words exist, but have entirely
different meanings?

"deprecate" means "to be declared unworthy or no longer to
be used by an authority" and is pronounced de-pre-KATE,
while "depreciate" means "to go down in financial value" and
is pronounced "de-PRE-she-ATE".

An awful lot of people seem to think that "deprecate" is a
misspelling of "depreciate" and then correct the spelling.
But then, they must have a funny idea of what it means when
a software feature is "deprecated". Maybe they think it's
like the opposite of "appreciate" or something? ("We
don't appreciate your code anymore"). ;-)

I suppose some smart alec is going to argue that "it goes
down in value because an authority declared it unworthy".
Would be about par for the course. ;-)

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Jan 8 '06 #28
On 2006-01-08, Terry Hancock wrote:

BTW, one of the most common programming spelling errors is
"deprecate" versus "depreciate" -- I wonder how many people
actually realize that both words exist, but have entirely
different meanings?


The words overlap in meaning. Both can mean to disparage or
belittle.

Some dictionaries give 'depreciate' as a definition of 'deprecate'.
--
Chris F.A. Johnson, author | <http://cfaj.freeshell.org>
Shell Scripting Recipes: | My code in this post, if any,
A Problem-Solution Approach | is released under the
2005, Apress | GNU General Public Licence
Jan 8 '06 #29
Chris F.A. Johnson wrote:
On 2006-01-08, Terry Hancock wrote:
BTW, one of the most common programming spelling errors is
"deprecate" versus "depreciate" -- I wonder how many people
actually realize that both words exist, but have entirely
different meanings?

The words overlap in meaning. Both can mean to disparage or
belittle.

Some dictionaries give 'depreciate' as a definition of 'deprecate'.


Well if someone told me my investments were deprecated I'd take that
differently to them being depreciated.
--
Robin Becker
Jan 8 '06 #30
On 2006-01-08, Robin Becker wrote:
Chris F.A. Johnson wrote:
On 2006-01-08, Terry Hancock wrote:
BTW, one of the most common programming spelling errors is
"deprecate" versus "depreciate" -- I wonder how many people
actually realize that both words exist, but have entirely
different meanings?

The words overlap in meaning. Both can mean to disparage or
belittle.

Some dictionaries give 'depreciate' as a definition of 'deprecate'.


Well if someone told me my investments were deprecated I'd take that
differently to them being depreciated.


That's why I said "overlap", not that they are the same.

--
Chris F.A. Johnson, author | <http://cfaj.freeshell.org>
Shell Scripting Recipes: | My code in this post, if any,
A Problem-Solution Approach | is released under the
2005, Apress | GNU General Public Licence
Jan 8 '06 #31
1. It's generally faster than reaching for the dictionary.


Terry> But not faster than use a dict server! Why not just use (e.g.)
Terry> kdict?

Maybe because not everybody has it?

% kdict
-bash: kdict: command not found

Skip
Jan 8 '06 #32
sk**@pobox.com enlightened us with:
Terry> But not faster than use a dict server! Why not just use (e.g.)
Terry> kdict?

Maybe because not everybody has it?


Lame excuse. If you don't have something but you do want to use it,
you get it. If everybody just used what they had at one point in time,
and never acquired anything new, the world certainly would look
different.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
Jan 9 '06 #33
sk**@pobox.com wrote:
The OP sort of seemed like he was pining
for attribute declarations. __slots__ is the closest thing Python has to
them. I don't use them myself (since I've basically avoided new-style
classes so far).

Skip


No, slots are a memory optimization trick and should NOT be used as
declarations.
You can find a few posts of the Martellibot on the subject. I even
wrote a recipe
to tell people who want static declarations how to implement them
without slots:
http://aspn.activestate.com/ASPN/Coo.../Recipe/252158

Michele Simionato

Jan 9 '06 #34
I like to play devil's advocate here, so I will say that in this case
using automatic testing
will increase your probability of spelling mistakes: I do most of my
spelling mistakes
in the test cases! <0.5 wink>

Michele Simionato

Jan 9 '06 #35
Op 2006-01-06, Terry Hancock schreef <ha*****@anansispaceworks.com>:
On 6 Jan 2006 07:30:41 -0800
"KraftDiner" <bo*******@yahoo.com> wrote:
I've spent hours trying to find a bug that was a simple
spelling mistake.


You're not the first. ;-)
in an init method I declare a variable self.someLongName

later in a different method of the class I use
self.sumLongName
Now I really meant self.someLongName.
In fact I don't want a variable called sumLongName.
Frankly how are you ever to know if this type of error is
occuring?


Both "unit tests" and "interfaces" are useful for catching
simple errors like this one. There is a 'unittest' module
in the Python standard library, and 'interface' modules are
available from the Zope 3 project and PyProtocols, both are
good.


I don't think unit tests are that helpfull in this case.
Unit tests help you in finding out there is a bug, they
don't help that much in tracking down a bug.

I for some reason a person is reading over the difference
between sumLongName and someLongName and doesn't notice
the different spelling in his source a unit test won't
be of much help.

--
Antoon Pardon
Jan 9 '06 #36
Antoon Pardon wrote:
I don't think unit tests are that helpful in this case.
Unit tests help you in finding out there is a bug, they
don't help that much in tracking down a bug.

I for some reason a person is reading over the difference
between sumLongName and someLongName and doesn't notice
the different spelling in his source a unit test won't
be of much help.

Since
1- The unit test will obviously fail in this case, telling you in which
code unit the issue is
2- Unit Test favor extremely modular coding with very short increments
(as a somewhat extreme example, Robert Martin gets nervous if his test
suites don't validate the code every 5 minutes, you usually don't write
200 lines and their unit tests in 5 minutes)

We can deduce that unit testing will detect the typo extremely early and
that the field of research will span about 5 to 10 lines, making the
tracking quite easy to perform.
Jan 9 '06 #37

Terry> But not faster than use a dict server! Why not just use (e.g.)
Terry> kdict?
Maybe because not everybody has it?


Sybren> Lame excuse. If you don't have something but you do want to use
Sybren> it, you get it.

I don't think I want it badly enough to figure out how to get it to work on
my Mac. (I'm assuming the "k" prefix implies it's part of KDE.) I'm happy
to continue googling for words I want defined.

Sybren> If everybody just used what they had at one point in time, and
Sybren> never acquired anything new, the world certainly would look
Sybren> different.

I'm not sure what in my response suggested to you that I never install new
software on my computers.

Skip
Jan 9 '06 #38
Xavier Morel enlightened us with:
1- The unit test will obviously fail in this case, telling you in
which code unit the issue is


Given the assumption the same mistake hasn't been made in the test as
well.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
Jan 9 '06 #39
sk**@pobox.com writes:
Terry> But not faster than use a dict server! Why not just use (e.g.)
Terry> kdict?
>> Maybe because not everybody has it?


Sybren> Lame excuse. If you don't have something but you do want to use
Sybren> it, you get it.

I don't think I want it badly enough to figure out how to get it to work on
my Mac. (I'm assuming the "k" prefix implies it's part of KDE.) I'm happy
to continue googling for words I want defined.


On the Mac, use Butler. I *can't* say enough good things about Butler
on the Mac - it actually makes the UI bearable.

For this case, I can search any of Google, Wikipedia or Websters
online (both the dictionary and the thesarus) by typing the
appropriate hotkey, the word, and the enter key.

So not only does this make using google for spelling checking faster,
it makes it equally easy to check an online dictionary. Butler comes
preconfigured for either Webster or Dictionary.com, as well as
Wikipedia and some specialty dictionaries, and it's trivial to add a
search on any search engine that does a "GET" query.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 9 '06 #40
bb
sk**@pobox.com wrote:

Terry> But not faster than use a dict server! Why not just use (e.g.)
Terry> kdict?
>> Maybe because not everybody has it?


Sybren> Lame excuse. If you don't have something but you do want to
use Sybren> it, you get it.

I don't think I want it badly enough to figure out how to get it to work
on
my Mac. (I'm assuming the "k" prefix implies it's part of KDE.) I'm
happy to continue googling for words I want defined.


kdict is, as you correctly assume, part of KDE. But it's just an interface
to query a dict server. And there are command line clients for that as
well.

--
Listen to the wise old man:
http://nobelprize.org/literature/lau...r-lecture.html
Jan 10 '06 #41
KraftDiner wrote:
I've spent hours trying to find a bug that was a simple spelling
mistake.

in an init method I declare a variable self.someLongName

later in a different method of the class I use
self.sumLongName
Now I really meant self.someLongName.
In fact I don't want a variable called sumLongName.
Frankly how are you ever to know if this type of error is occuring?

pychecker
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Jan 10 '06 #42
Op 2006-01-09, Xavier Morel schreef <xa**********@masklinn.net>:
Antoon Pardon wrote:
I don't think unit tests are that helpful in this case.
Unit tests help you in finding out there is a bug, they
don't help that much in tracking down a bug.

I for some reason a person is reading over the difference
between sumLongName and someLongName and doesn't notice
the different spelling in his source a unit test won't
be of much help.
Since
1- The unit test will obviously fail in this case, telling you in which
code unit the issue is


Not in general. Several unit tests can fail. And if you have a variable
spelled differently, the code unit that fails is not dependant on which
occurence was spelled correct and which was spelled wrong. So it is very
well possible that the code unit with the issue is the one in which the
variable is spelled correctly.
2- Unit Test favor extremely modular coding with very short increments
(as a somewhat extreme example, Robert Martin gets nervous if his test
suites don't validate the code every 5 minutes, you usually don't write
200 lines and their unit tests in 5 minutes)
I have a unit test that takes at leas 2 minutes. If I would validate
each five minutes I wouldn't get any work done.
We can deduce that unit testing will detect the typo extremely early and
that the field of research will span about 5 to 10 lines, making the
tracking quite easy to perform.


Not necessary. You may have started with misspelling the variable and
spelled it correctly in your last edit session. Doing your research
in the 5 to 10 lines last edited will then reveal nothing.

--
Antoon Pardon
Jan 10 '06 #43
On 9 Jan 2006 11:21:10 GMT
Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2006-01-06, Terry Hancock schreef
<ha*****@anansispaceworks.com>:
On 6 Jan 2006 07:30:41 -0800
"KraftDiner" <bo*******@yahoo.com> wrote:
in an init method I declare a variable

self.someLongName >
later in a different method of the class I use
self.sumLongName
Now I really meant self.someLongName.
In fact I don't want a variable called sumLongName.
Frankly how are you ever to know if this type of error

is > occuring?

Both "unit tests" and "interfaces" are useful for
catching simple errors like this one. There is a
'unittest' module in the Python standard library, and
'interface' modules are available from the Zope 3
project and PyProtocols, both are good.


I don't think unit tests are that helpfull in this case.
Unit tests help you in finding out there is a bug, they
don't help that much in tracking down a bug.

I for some reason a person is reading over the difference
between sumLongName and someLongName and doesn't notice
the different spelling in his source a unit test won't
be of much help.


Well, if you are doing fairly frequent unit tests, then you
will have written a unit test to test the "someLongName"
method, and if you manage to type "sumLongName" in BOTH the
code and the unit test, then there must be some Freudian
reason you really did want to use "sumLongName". ;-)

It's a bit like the standard practice of making you type a
password twice. In fact, most of the common "bug avoidance"
methods in programming all come down to this -- you have to
type the same thing twice in two different places to get
the result.

C and C++ make you do declarations -- so you have
to mention the name before you can use it. You have to type
the variable names twice.

Interfaces define the "publically viewable" parts of a
class, then you have to actually create them in a separate
class definition. You have to type the methods twice.

In unit testing, you write the code, then write code to test
the code, which must correctly identify the methods in the
code. So you have to type 'everything' twice.

And so on.

The ideal of "don't repeat yourself" seems to get
nudged out by "repeat yourself exactly once" when it's
really important to get it right. ;-)

It's really just a fancy way to force you to proof-read your
own work carefully enough (which is tricky because you
tend to ignore stuff that's too repetitious).

Cheers,
Terry

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Jan 10 '06 #44
Sybren Stuvel wrote:
Xavier Morel enlightened us with:
1- The unit test will obviously fail in this case, telling you in
which code unit the issue is


Given the assumption the same mistake hasn't been made in the test as
well.


If the spelling in the test matches the spelling in the code, then
obviously it isn't a mistake at all! <0.5 wink>

-Peter

Jan 11 '06 #45
Terry Hancock wrote:
[...]

The ideal of "don't repeat yourself" seems to get
nudged out by "repeat yourself exactly once" when it's
really important to get it right. ;-)
I suppose most readers aren't old enough to remember the punch card
days, when you would hand your work in on coding sheets to the punch
room and it would be punched onto cards using huge machines (anyone
remember the 026 and 029 punches?).

Before you got the cards back they were processed twice: one operator
would actually punch the cards, and another would re-key the same input
on a verifier machine that alerted them to any differences between what
was on the card and what was keyed.
It's really just a fancy way to force you to proof-read your
own work carefully enough (which is tricky because you
tend to ignore stuff that's too repetitious).

That's why two different operators would do the punching and the verifying.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Jan 11 '06 #46
Op 2006-01-10, Terry Hancock schreef <ha*****@anansispaceworks.com>:
On 9 Jan 2006 11:21:10 GMT
Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2006-01-06, Terry Hancock schreef
<ha*****@anansispaceworks.com>:
> On 6 Jan 2006 07:30:41 -0800
> "KraftDiner" <bo*******@yahoo.com> wrote:
>> in an init method I declare a variable
>self.someLongName >
>> later in a different method of the class I use
>> self.sumLongName
>> Now I really meant self.someLongName.
>> In fact I don't want a variable called sumLongName.
>> Frankly how are you ever to know if this type of error
>is > occuring?
>
> Both "unit tests" and "interfaces" are useful for
> catching simple errors like this one. There is a
> 'unittest' module in the Python standard library, and
> 'interface' modules are available from the Zope 3
> project and PyProtocols, both are good.
I don't think unit tests are that helpfull in this case.
Unit tests help you in finding out there is a bug, they
don't help that much in tracking down a bug.

I for some reason a person is reading over the difference
between sumLongName and someLongName and doesn't notice
the different spelling in his source a unit test won't
be of much help.


Well, if you are doing fairly frequent unit tests, then you
will have written a unit test to test the "someLongName"
method, and if you manage to type "sumLongName" in BOTH the
code and the unit test, then there must be some Freudian
reason you really did want to use "sumLongName". ;-)


Who says someLongName is a method?
It's a bit like the standard practice of making you type a
password twice. In fact, most of the common "bug avoidance"
methods in programming all come down to this -- you have to
type the same thing twice in two different places to get
the result.

C and C++ make you do declarations -- so you have
to mention the name before you can use it. You have to type
the variable names twice.
But that is not an accepted idea here in c.p.l. I also find
it strange that redundancy via type declarations is so hard
resisted here and is then defended with the argument it
isn't needed is you test sufficiently (with unit tests)
which is also a kind of redundancy.
Interfaces define the "publically viewable" parts of a
class, then you have to actually create them in a separate
class definition. You have to type the methods twice. In unit testing, you write the code, then write code to test
the code, which must correctly identify the methods in the
code. So you have to type 'everything' twice.
But you don't type attribute names twice in unit tests,
because attributes are in general implementation details
that are of no concern to the tester. So unit tests can
not introduce the redundancy to find out a missed spelled
attribute in some methods.
The ideal of "don't repeat yourself" seems to get
nudged out by "repeat yourself exactly once" when it's
really important to get it right. ;-)

It's really just a fancy way to force you to proof-read your
own work carefully enough (which is tricky because you
tend to ignore stuff that's too repetitious).


Yes and you also tend to read over your own spelling errors.

--
Antoon Pardon
Jan 11 '06 #47
Dennis Lee Bieber <wl*****@ix.netcom.com> writes:
On Wed, 11 Jan 2006 06:57:06 +0000, Steve Holden <st***@holdenweb.com>
declaimed the following in comp.lang.python:
I suppose most readers aren't old enough to remember the punch card
days, when you would hand your work in on coding sheets to the punch
room and it would be punched onto cards using huge machines (anyone
remember the 026 and 029 punches?).

FORTRAN and COBOL on 029s -- and had to submit the school ID card to
check-out a drum; coding a drum card was actually taught in the COBOL
class.


Pretty much everything on the 029. Like you, I had to punch things
myself. And had a drum card with one track for FORTRAN and a second
for ALGOL.

Of course, I was employed to work with them. At one point, I actually
"helped" someone do data processing with the card sorter.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 11 '06 #48

Steve> I suppose most readers aren't old enough to remember the punch
Steve> card days, when you would hand your work in on coding sheets to
Steve> the punch room and it would be punched onto cards using huge
Steve> machines (anyone remember the 026 and 029 punches?).

I do remember the IBM Model 29 punch card machines, though as a student
nobody was there to punch my cards or verify them for me... :-(

Skip
Jan 11 '06 #49
Antoon Pardon wrote:
Op 2006-01-10, Terry Hancock schreef <ha*****@anansispaceworks.com>:
In unit testing, you write the code, then write code to test
the code, which must correctly identify the methods in the
code. So you have to type 'everything' twice.


But you don't type attribute names twice in unit tests,
because attributes are in general implementation details
that are of no concern to the tester. So unit tests can
not introduce the redundancy to find out a missed spelled
attribute in some methods.


I wouldn't call attributes "implementation details", at least not in
Python. And while it is true that unit tests might not find the
misspelling *directly* (i.e. you rarely test if you have misspelled
something), your tests should definitely show unexpected behavior and
results, if that attribute is of any importance. Otherwise there's a
loophole in your tests. :-)

--
Hans Nowak
http://zephyrfalcon.org/
Jan 11 '06 #50

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by English Teacher | last post: by
10 posts views Thread by gnat | last post: by
3 posts views Thread by Peter | last post: by
8 posts views Thread by Nick 'The Database Guy' | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.