Uh. It throws a ValueError exception. Not a specific one. It IS up to you to decide which values you think are valid for your program. These constants can't change, because that'd be breaking backwards compatibility MASSIVELY. Furthermore, you're still missing the point. But I probably am too, from your point of view. And this is going nowhere, so let's leave it at that.
On 20 August 2011 21:47, Andreas Schiefer <[email protected]>wrote: > > > On 20 August 2011 19:00:08 UTC+2 Mike Redhorse wrote: >> >> 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. > > > Well, and I find code that checks for implementation details of a specific > Python implementation horrific. That's a good way to create non portable > python code (by portable, I mean across Python implementations - pyglet runs > fine on pypy too...). Also that constants can change with every Python > release, if the Python developers decide to change the internal unicode > representation. > Why do think unichr() even throws an exception? Well, because that you > don't have to decide yourself which values you think are valid for every > Python implementation. > > Just my view on that subject... > > > >> 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/**q**uestions/2522005/cost-of-**excep** >>>>> tion-handlers-in-python<http://stackoverflow.com/questions/2522005/cost-of-exception-handlers-in-python> >>>>> [2] >>>>> http://docs.python.org/**lib**rary/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/* >>>>> *ms**g/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.**c**om. >>>>> >>>>> 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<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 >>> 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/-/SMMnz1KZb5QJ. > > 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.
