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 >> [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. >> > > -- 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.
