"Martin v. Loewis" wrote: > > > > this could be > > > established only by implementing it (you don't need to implement > > > the parser/compiler aspects, just the changes to ceval.c). > > > > Hmm. How is that supposed to work ? I would like the compiler > > to generate different code for these "switch" statements. It > > would also have to generate the hash table and store it in > > the constants. > > You would need to generate the byte code literally. Come up with a > byte code definition for this feature, support it in ceval, then come > up with a byte string that is an example for a large optimized "if" > chain, and generate a code object from it. Adapting Lib/compiler may > be helpful in generating byte code more flexible. > > Only when it is known that this byte code that you generated more or > less manually indeed performs significantly faster, only then it would > be worthwhile looking into parser/compiler support for that byte code. Ok. > > Well, just try to write an XML parser using mxTextTools and the > > taggin engine which then generates a tag list to be processed in > > Python by an if..elif...else "switch" statement and > > compare the speed to a method call based one. You'll note the > > difference in performance (and have a second application ;-). > > If it is unacceptably inefficient, perhaps this approach to XML > parsers is doomed to fail... It is not unacceptably inefficient. Indeed this approach already outperforms the method callback based one using the current Python versions and long if-elif-else statements. What I'm argueing for is that we make it perform even better ;-) > > This is just one aspect, though. I think that a lot more state > > machine like code could be written in Python if well-performing > > "switches" would be possible in Python. > > I think people have successfully used dictionaries of functions for > that. Why do you insist on generating long "if" chains? I don't "insist" on any programming technique. It just happens that I have made very good experience with this kind of approach in both C and Python (except that Python could be made smarter when it comes to finding the right code snippet to execute). > > Now how could the compiler be provided with the needed > > information... ? > > I still think this is the last question to ask. First define the > opcodes, and show us that they really do speed up things, then look > into the syntax needed to support this optimization. I'll do that, but only if people on python-dev agree that it's worth trying (I'm +1 on it, obviously). There's not much point investing time into something which then get's lots of -1's just because I can't convince you guys of the benefits, whether its performance, gaining new grounds for Python development (writing low-level fast parsers in Python) or simply introducing a different way of approaching a common problem (method callbacks vs. switches). > If you think you need an annotation, you may just as well propose to > introduce a switch statement into the language. True, but that would probably be even harder to get accepted on python-dev (or would it ;-) ? > switch x: > case 'foo': > ... > case 'bar': > ... > case 42: > ... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4