A clean way to program an interface

[Diez B. Roggisch]

rh0dium wrote:

> On Jul 9, 3:53 am, "Diez B. Roggisch" <d... at nospam.web.de> wrote:
>> 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
> 
> Hi Diez,
> 
> Totally understand your confusion with sys._getframe().f_code.co_name
> - that was borne out of the fact that I was creating a method for each
> serial function and it was repeating.. over and over.. 
> So I got tired 
> of changing the three items that differentiated each method so I
> simplified it a bit. Perhaps too much.  

I can't say that it has become simpler... It would have been if you at least
created a function for it. But even then, it's certainly the wrong way to
go.

> So can I ask you to show or 
> point me to a good interface example?  I think we both can agree that
> fundamentally this is pretty simple but I want to do it right and an
> solid class example of interface programming would be nice.

I don't understand what you mean by "interface programming". If you tell us
how the serial protocol works, and what it accomplishes, one might come up
with a clean solution.

But that depends on the actual protocol.

Diez