Fix Python 3 compatibility.

[progval]

Added compatibility to run mine.py as-is with Python 3.
Of course, I did not break Python 2 compatibility.

[BertrandBordage]

Did you manage to get pyglet working on Python 3?

[progval]

If you run pyglet's setup.py with Python 3, it will run 2to3 before compiling and installing.

[embatbr]

Hum... nice. So, you reinstalled Pyglet and after runned the game? Just that? What version did you used? Python3.3?

[progval]

Yes, that's it. I use Python 3.2.3 (from Debian).

[embatbr]

And are the images OK? I am reading a post in a google group and the user says "Also the whole pyglet.image module needs some fixing, because it uses string regexes for the image data that is now stored as bytes."

https://groups.google.com/forum/?fromgroups=#!topic/pyglet-users/nVVCnWjRh2A

[progval]

This post is from 2010, while Pyglet announced support for Python 3 in 2012.

[BertrandBordage]

OK. Maybe we could simply replace xranges with ranges. I don't think it will have significant performance impact on the initialization. And since this pseudo-terrain generator needs to be entirely rewritten…

[embatbr]

My bad.

[embatbr]

Hum, I tried to run a hello world from the tutorial, using Python3.3 and there is a lot of exceptions. How did you do @progval?

[embatbr]

When I try to run the hello world (that is a simple code, so it should work) I get "NameError: global name 'unicode' is not defined"

[EDIT] I reinstalled of so many ways I can't remember what I did right but it's working.

[progval]

You have to install the latest alpha version, ie. download it from the Mercurial repo.

Then, cd to it and run "sudo python3 setup.py install".

[Lewiscowles1986]

I have pyglet running and got around the xrange / range (btw range in python3 is xrange, you have to call list(range(...)) to get python 2 range (DRY, nice).

Anyway there is still an issue with passing of float expected integer (possibly byte bug mentioned earlier in this thread)...

I'll post my code if I can get it working...

[leotada]

I think the right way is change the entire code to Python 3, using range, and backport to Python 2, then if version < Python3 use xrange.

[ocarneiro]

There's a better (IMHO) way to make it Python 2 and 3 compatible using the future module.

[progval]

@ocarneiro My solution does not add an external dependency, and is not harder to read than using six.

[tleeuwenburg]

Does this still need to be done? I did a simple 2to3 on my machine and basically it worked after some edits where ints were expected. I would find it straightforward to write a version than can run as 2 or 3 (e.g. import range as xrange or similar). I haven't reviewed anyones pre-existing code, I'd be happy to pick a pre-existing solution and tweak it into shape.

The only issue I found was that the blocks don't render initially. I think there's some bug in terms of deciding what's exposed and what's not. If I add a block, that works fine. If a delete a block, all the adjacent exposed blocks become visible.

[progval]

I did a simple 2to3 on my machine and basically it worked after some edits where ints were expected.

With this PR, 2to3 is not needed.
And the ints thing is half of the content of the PR.

I would find it straightforward to write a version than can run as 2 or 3 (e.g. import range as xrange or similar).

That's exactly what this PR does

The only issue I found was that the blocks don't render initially. I think there's some bug in terms of deciding what's exposed and what's not. If I add a block, that works fine. If a delete a block, all the adjacent exposed blocks become visible.

What do you mean by “exposed”? I don't see a difference in behavior between running on Python 2 or 3.

[progval]

@fogleman Thanks!