I'm just arguing with no purpose since it's been commited, but just for the record, I consider this a horrific example of try/except usage, and since 'it's fine either way', a minute's worth of effort to change it to something sane would be a good idea.
On 20 August 2011 18:33, Andreas Schiefer <[email protected]>wrote: > > > On 20 August 2011 15:07:45 UTC+2 Mike Redhorse wrote: >> >> If it's 10FFFF, the vendor keys will work fine? Because they're under >> that. > > > On my laptop, the keycodes of the vendor keys are lower than both > constants, but the values of 'symbol' for them are much higher. So they > still throw an exception on a wide Python build. > > >> Quoting from there, "as long as the condition is not met". You can have a >> big if that checks if it's NOT a vendor key and that would time a lot less >> than a try block. Again, it doesn't make a difference, the code works the >> same, however using exceptions and 'pass'ing when caught is a bad idea. If >> at any point something OTHER than a vendor key causes ValueError to be >> raised, it's going to go invisible without being able to check. Hell, if >> anything breaks the actual dict containing the keys, every ValueError is >> going to disappear in that loop. >> >> Use try/except blocks where you need to catch an error. Not to replace an >> if statement. >> > > That is what is done in the fix I just commited, catching an error. An 'if' > would just duplicate a check for a CPython implementation detail that > is probably already made in unichr() itself. > Instead of passing, I directly assigned the user-key generated from the > keycode. That way, there is no lookup in the _key_names dict, where the > invalid symbol will not be found anyway. > > > > >> >> >> On 20 August 2011 11:00, Andreas Schiefer <[email protected]> wrote: >> >>> 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<http://stackoverflow.com/questions/2522005/cost-of-exception-handlers-in-python> >>> [2] >>> http://docs.python.org/**library/functions.html#unichr<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<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 >>> pyglet-users...@googlegroups.**com. >>> >>> For more options, visit this group at http://groups.google.com/** >>> group/pyglet-users?hl=en<http://groups.google.com/group/pyglet-users?hl=en> >>> . >>> >> >> -- > 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/-/97jgEtnUxXUJ. > > 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. > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. 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.
