OK. I’m back with another implementation question. This has to do with using a dictionary to branch rather than if/then/else.
Are there instances where one is better than the other like in speed or code space? I am specifically using dictionary/switch codes to call other routines based on certain conditions.
It would seem that if/then is good if there are not too many (?) needed. Also, it seems if code can (or is desired to) be executed within the if/then construct, if/then seems to have the advantage since it’s not clear to me that can be done from within a dictionary structure.
From the little I’ve read, it seems a dictionary is more efficient in its execution (don’t know about the amount of memory required, tho). However, if there is code to be executed, a call must be made to another procedure or function (if I understand it correctly) containing that code. I’m not sure if that makes the code more clean or more complicated to sort thru.
I’d welcome some insight and feedback on this from those much more experienced and enlightened than I Thx.
I’m just an old, retired developer now, but I agree with the maxim that “premature optimization is the root of all evil”. I think applications should be written with the overwhelming priority being straightforward, non-tricky, easy to understand code. Optimization should never enter in until a working prototype exists. At that point, it may turn out to be fast enough to keep users happy, in which case, it’s done.
If it does turn out to require optimization, then a profiler should be used to determine where most of the cycles are going. Usually, there will be only a few hot spots where the code is spending the most time. At this point, it is time to look at those code segments, and think in terms of optimization. Repeat until performance is adequate.
Regarding your specific question, about what is the most efficient way to simulate a C switch construct in python, I think you’d have to have a lot of branches, or call the code a huge number of times per second before the difference would be humanly noticeable. If such code turns out to be using up a lot of cycles, then sure, optimize it, but that probably won’t happen.
for the python kernel I think you are 20 years too late, but the idea lingers on and there are much more exotic versions than a profane dict (see f.i. Python Notes for Professionals, chapter 140)
I appreciate the input. After thinking abt it some more, I realized with the speed of the machine and the amount of memory, it prob’ly doesn’t matter, dictionary or if/then/else. It just seems the if/then is so inelegant, so clunky. On the other side, my limited understanding of Python and how it appears to be array/table-oriented makes dictionaries for procedure calls so natural.
Of course, I am a novice at this (came up thru h/w and assembly language coding) so I could be off in my sense of things.
Not sure of the “…20 years too late…” reference, but I truly appreciate your link. I did not know about that document and looks like a nice reference to go along with the others I have. Thanks!!
from the masters own tutorial
‘An if … elif … elif … sequence is a substitute for the switch or case statements found in other languages’
of course it’s definitely not a one liner and against ‘Beautiful is better than ugly’ (first command of the Zen of Python) but I put it to GvR’s fight against the boundless ‘non use case’ arguing that he stuck to this early decision
it will be interesting how Python will perform under the new government (https://www.mail-archive.com/python-committers@python.org/msg05628.html)
I know, but the BDFL times are certainly over and there are plenty of controversial topics (and basic ones, think of type checking or interfaces); but I’m just a pensioner and enjoy the freedom python offers me for programming and, of course, the smooth integration of wxPython for a professional GUI
@profconn1
If you find it more elegant to use a dictionary of functions rather than if/elif…, then by all means do it. I always use this technique when I write an xmlrpc server. I prefer to have just one entry point, and include the function name in the argument list.
Appreciate it. That’s the approach I’m taking. I have places where an if/then works for me (small number of options to test) and others where a switch function works better (and reads better). Having been thru this process, I find I’m getting more comfortable with if/thens so it isn’t as big an issue (for now