API compatibility tests

[doismellburning]

http://www.raspberrypi.org/documentation/usage/minecraft/ transcribed into code (ish)

Plus a whole bunch of reversion needed to fix compatibility breakages

[doismellburning]

Currently blocked on #38

[dbrgn]

Good idea to rename minecraft to mcpi.

We could (and should) keep the newer and the compat API in two totally separate packages.

[doismellburning]

So, shall I kick off a Minecraft server in .travis-ci.sh or is that a terrible idea? (I say this; I'm about to give it a try...)

[dbrgn]

You can try whether it even works (did someone do that yet?). I did an attempt with emulating the Raspberry Pi once, and IIRC Minecraft did not run correctly. But maybe this qemu script works better :)

[doismellburning]

Running mock_server.py with these tests results in woe and suffering that I have yet to debug, except so far as to want to bin mock_server

[doismellburning]

I mocked all the things, and then this passed on the code from 6eeb804 (i.e. pre-sprint); looks like I'm going to need to revert/fix a bunch of changes from then

[doismellburning]

Tests should pass now, huzzah! (That is to say, they do locally under Python 2.7; I haven't tried 3)

It looks like a bunch of stuff got broken at the sprint; I've done some slightly heavy-handed reversion, because not breaking teachers' existing tutorials is a massive priority

[doismellburning]

Note that this is quite insufficient - it doesn't actually test that the commands we're sending are in any way valid (see my monkey-patching) BUT it took nontrivial work to get (back) to just this amount of working-ness, so I'd call this a significant net improvement

[doismellburning]

Well, it passes on my machine but I'm baffled as to why; time for more monkeypatching!

[doismellburning]

So close. Failed because an example uses xrange which isn't in Py3k

I consider it acceptable to change that test to use range, rather than introduce some xrange backwards compatibility thing, because this is a Python change

(Relatedly, I am saddened by Python 3 dropping xrange, but that's out of scope for this...)

[dbrgn]

(Relatedly, I am saddened by Python 3 dropping xrange, but that's out of scope for this...)

Why? In Python 3 range returns a generator by default, so no xrange is needed anymore. It's more consistent.

We could add a simple compat.py module that does things like

try:
    xrange = xrange
except NameError:
    xrange = range

[doismellburning]

Because needless compatibility breakage makes me sad

Yes we could do that, but I do not want to, because it would seem contrary to the goal of encouraging Python 3 (even though I happen to find that change infuriating)

[dbrgn]

Well, if a user uses Python 3 he can still use range directly. The compat xrange would only be used internally.

OTOH, xrange is only useful to reduce memory consumption. For small lists it is even slower than range if I remember correctly.

[doismellburning]

Please don't assume "he"

[dbrgn]

You're right, I try not to, but it's a bad habit :) (Btw, the thing about range being faster was wrong. I had generator expressions vs list comprehensions in mind.)

[doismellburning]

[ghickman]

10 points for amazing giffing!