Re: Pyglet

[Andreas Schiefer]

Hi!

As I'm not the main author of pyglet, just one of it's contributors,
I'll forward your mail to the pyglet mailing list (which you can find
at http://groups.google.com/group/pyglet-users) so everyone involved
can read it.

Answering your questions:
Glad you like pyglet!

Is that sort of a strategy game with Minecraft graphics? Looks nice!

I was not aware of this bug. Have you tested the attached patch? If it
works as expected, I can commit it to the development version of
pyglet if I find time.

I don't think it's possible to donate money to pyglet, as there is no
single developer responsible for it. But you can always help by
creating patches, fixing bugs, etc.

If you have any additional questions, feel free to post it to the
pyglet mailing list.

(You can also check out the very new unofficial pyglet forum at
http://remike.homelinux.org/pyglet/ and showcase your project there if
you want.)

---------- Forwarded message ----------
From: Perttu Ahola <cele...@gmail.com>
Date: Fri, Aug 19, 2011 at 10:32 AM
Subject: Pyglet
To: andreas....@gmail.com

Hi!

Four things:

I want to thank you a lot of the making and maintaining of Pyglet. It
is a terribly good library! Please keep it going!

Here's a screenshot of something I am making with it currently:
http://celeron.55.lt/~celeron55/random/2011-08/ternadim_2011-08-19_2.png

Also, why hasn't this been fixed already? It is quite annoying as a
Linux laptop user:
http://code.google.com/p/pyglet/issues/detail?id=487&q=not%20in%20range&colspec=ID%20Status%20Type%20Milestone%20OpSys%20Summary#makechanges

And finally, is it possible to donate a bit of money for the ongoing
maintenance of Pyglet?

// Perttu Ahola | celeron55 | http://celeron.55.lt/minetest/

[celeron55]

It seems google groups allows me to post directly on this web page so
here goes. (Somebody should make the link to http://groups.google.com/group/pyglet-users
more visible on pyglet.org. Everybody probably misses it.)

> As I'm not the main author of pyglet, just one of it's contributors

I chose you due to the fact that you are the only one committing
recently to the repository. :-)

> Have you tested the attached patch?

I have tested the suggested fix and it works, and actually I have
fixed my system-wide installed version of pyglet that way. (python
makes that almost *too* easy 8))

// celeron55

On Aug 19, 1:34 pm, Andreas Schiefer <andreas.schie...@gmail.com>
wrote:

> Hi!
>
> As I'm not the main author of pyglet, just one of it's contributors,
> I'll forward your mail to the pyglet mailing list (which you can find

> athttp://groups.google.com/group/pyglet-users) so everyone involved

> can read it.
>
> Answering your questions:
> Glad you like pyglet!
>
> Is that sort of a strategy game with Minecraft graphics? Looks nice!
>
> I was not aware of this bug. Have you tested the attached patch? If it
> works as expected, I can commit it to the development version of
> pyglet if I find time.
>
> I don't think it's possible to donate money to pyglet, as there is no
> single developer responsible for it. But you can always help by
> creating patches, fixing bugs, etc.
>
> If you have any additional questions, feel free to post it to the
> pyglet mailing list.
>

> (You can also check out the very new unofficial pyglet forum athttp://remike.homelinux.org/pyglet/and showcase your project there if

> you want.)
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Perttu Ahola <celero...@gmail.com>
> Date: Fri, Aug 19, 2011 at 10:32 AM
> Subject: Pyglet
> To: andreas.schie...@gmail.com
>
> Hi!
>
> Four things:
>
> I want to thank you a lot of the making and maintaining of Pyglet. It
> is a terribly good library! Please keep it going!
>
> Here's a screenshot of something I am making with it currently:http://celeron.55.lt/~celeron55/random/2011-08/ternadim_2011-08-19_2.png
>
> Also, why hasn't this been fixed already? It is quite annoying as a

> Linux laptop user:http://code.google.com/p/pyglet/issues/detail?id=487&q=not%20in%20ran...

[Michael Red]

The project looks very promising. If you have time, I suggest showcasing it on the unofficial forum. ( http://remike.homelinux.org/pyglet )

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.

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To post to this group, send email to pyglet...@googlegroups.com.
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.

[Andreas Schiefer]

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

 

On 19 August 2011 14:59, celeron55 <cele...@gmail.com> wrote:

It seems google groups allows me to post directly on this web page so
here goes. (Somebody should make the link to http://groups.google.com/group/pyglet-users
more visible on pyglet.org. Everybody probably misses it.)

> As I'm not the main author of pyglet, just one of it's contributors

I chose you due to the fact that you are the only one committing
recently to the repository. :-)

> Have you tested the attached patch?

I have tested the suggested fix and it works, and actually I have
fixed my system-wide installed version of pyglet that way. (python
makes that almost *too* easy 8))

// celeron55

On Aug 19, 1:34 pm, Andreas Schiefer <andreas....@gmail.com>

[Michael Red]

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.

To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/c8j55SdE64cJ.

[Andreas Schiefer]

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

[Michael Red]

If it's 10FFFF, the vendor keys will work fine? Because they're under that.

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.

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

[Andreas Schiefer]

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 <andreas....@gmail.com> 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 <andre...@gmail.com> 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...

[Michael Red]

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.

To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/97jgEtnUxXUJ.

[Andreas Schiefer]

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 <andreas....@gmail.com> 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 <andre...@gmail.com> 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 <andr...@gmail.com> 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 pygl...@googlegroups.com.

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.

[Michael Red]

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.

To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/SMMnz1KZb5QJ.