According to [1] it is actually the other way round. Try-blocks are very cheap unless the exception really happens. The if condition has to be checked every time, the exception is only executed if the symbol is not valid. I expect vendor keys to be used quite rarely and the try-except version would not slow down normal key presses. Also, the 0xFFFF constant depends on the Python build. For wide builds, it is 0x10FFFF [2]. Don't know if there is a built-in constant for checking this.
Overall, I think it doesn't make that much of a difference, either version would be fine. [1] http://stackoverflow.com/questions/2522005/cost-of-exception-handlers-in-python [2] http://docs.python.org/library/functions.html#unichr On 19 August 2011 20:56:00 UTC+2 Mike Redhorse wrote: > > It would work, yes. But I don't find it good behavior for a program to just > pass for an exception being caught. The better solution is for no exception > to be triggered, if we don't intend to do anything about it anyway. Just > have an if statement before-hand to see if it's specifically THIS case, > where we have values over 0xFFFF (non-standard keys), and if so, skip the > whole thing, or format them with the raw keycode if you really want to. Come > to think of it, the cost of a try statement is generally higher than a > simple if statement, and that gets run pretty often, so it's better to have > it this way. > > On 19 August 2011 21:32, Andreas Schiefer <[email protected]> wrote: > >> >> >> On 19 August 2011 16:19:13 UTC+2 Mike Redhorse wrote: >>> >>> The fix on that issue works, but isn't really ideal. It's just passing >>> from the exception with no warning or anything at all. I don't think there >>> are cases where that would be a problem, but technically it should print >>> out >>> a warning that you're using unsupported keys. Or just have something to >>> handle them as needed. But using unichr() makes that difficult. An if >>> before-hand to see if we're over 0xFFFF should prevent any ValueErrors >>> occuring. If a program needs to use vendor keys, they can overwrite this >>> code themselves and use something other than unichr. >>> >> >> Actually, I think the fix should work as expected. Because right after the >> fixed line, the keycode is used as the symbol, if the symbol is still not >> valid (which would be the case if unichr() raises a ValueError). So programs >> can use vendor keys by using the raw keycode. >> >> I'll try it out later... >> >> -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/Snuti0bt_2sJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
