A clean way to program an interface

[Diez B. Roggisch]

rh0dium wrote:

> Hi all,
> 
> I got this new radio scanner (toy!!) this weekend and I can access it
> via a serial cable. I want to write a interface around it but I am
> looking for some suggestions.  I thought at first I would simply class
> the Scanner and write the various methods as attibutes similar to
> below..  But then I thought about it and I don't like it for a couple
> of obvious reasons - there isn't any data checking, and it's terribly
> repetitive.
> 
> So I started searching on google - and I think it might be better to
> use a (sub)class for each function ( class STS, PRG, etc.). where the
> attributes are accessible as both dict items and lists - which
> ultimately go and "set" the scanner.
> 
> I guess my question is this.
> 
> I have a function SIN which when one argument is given does an
> effective "get" from the scanner - this returns some 10+ values.  When
> some 10+ parameters are given it does an effective "set" to the
> scanner.  Given that I can't remember all 10+ parameters I attempted
> below to represent them as a dict where the key tells me what the heck
> the parameter is supposed to represent.  So a simple translation
> occurs on both the set and get which splits the list into a named dict
> and vice versa.   Question 1 - I think I should be checking the data
> before a set - is this a smart thing or should I just do a try/
> except?  Question 2 - Since I only want to do this once (ok twice)
> should I represent each function as a class or should I keep the code
> I have below?

THROW IT AWAY!!!!

Seriously. That's one of the most convoluted, incomprehensible pieces of
python I've seen. Ever.

All the sys._getframe()-stuff has to go. Really. There are about a dozen
pieces of code worldwide that are allowed to have that in them. Maybe two
dozen.

And while I'm having difficulties grasping what you actually mean by " I
represent each function as a class or should I keep the code
 I have below?", I've done my fair share of serial programming. And I would
say that having one class that exposes different methods for commands is
the way to go.

But first - throw that code away. Fast. Faster.

Diez