If you ever get around to unboxing them that might be my way of paying you back. While I don’t have an electronics background I have been current NodeMCU firmware team since summer 2015. So, I know a thing or two about those devices.
I’ve got a test setup, but never got it to talk over the serial line. I’ve got something miswired somewhere, so there’s really nothing anyone else can do, I just need to put some time into figgerin’ it out. Thanks for the offer, though…
I definitely do care and when I build web forms I pay attention to this. Don’t know why I didn’t test this here. Will fix.
Yeah, that’s a quirk in some gui packages: some use the layout manager to dictate tab navigation order, some use widget creation order, just one of those things you have to know/remember.
What were those other “minimal changes to anything else”? The function names and their visibility?
I’m accustom to large applications (our big product has 80k lines just for the gui code), so I would (did) derive a real RadioBox class that completely encapsulates the RadioButtons and all their idiosyncracies. This would just add needless complexity to your program, which is nice and compact. If you intend for it to grow into some behemoth, do-it-all, uploader/downloader/browser, then it might be worth all the extra structure, but for a simple wrapper on a command-line utility, I think what you’ve done is just great.
That’s one other thing that I spent some time thinking and reading about. Knowing that I’m coming from Java that has private, (package) protected and public methods you may not be surprised I added those __ to all “internal” functions.
It’s more common to see just a single underscore, which is an idiom that says “hey, this is private, use it at your own risk”. The double underscores are usually reserved for the more emphatic “don’t even think about it” case. Pythonic programming is much more about adhering to a gentleperson’s agreement than dictating terms. When you do a production code review, you always flag it when someone uses an “_attribute” out of context, but during debugging it can save you all sorts of hoop-jumping. It’s just part of the culture.
I also used the all-lower snake case naming pattern rather than lower camel case as is common in Java. Your code and the wxPython code uses upper camel case. Python styling guidelines seem to be rather liberal?
Right, I use PEP-8 conventions (lower snake) for most code, but when dealing with “external” packages, I use the package conventions. Again, it’s idiomatic to do so, and deviations are documentation. (I just mentioned this one on python-ideas, but it applies everywhere as far as I’m concerned: Stupid Python Ideas: Why following idioms matters ) So, if I see lower-snake, I think, “ok, this is pure Python, nothing to do with WX”. When I see lower-camel, then I think, “this is an application-specific extension to the WX widget (maybe it talks to the database);” upper-camel means, “this is WX-like, either an override and in any case it’s not application-specific.”
···
On Friday, January 13, 2017 at 1:43:57 PM UTC-8, Marcel Stör wrote: