rh0dium wrote: > On Jul 9, 3:53 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
