Issue 207 in los-cocos: Be python 3 compatible

[los-...@googlecode.com]

Status: Started
Owner: ccan...@gmail.com
Labels: Type-Enhancement

New issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

make the codebase support (python 2.7, python 3.3+)

Steps:
make test/ syntax compatible with 2 and 3
make utest/ syntax compatible with 2 and 3
make cocos/ support 2 and 3, verifying that render / behavior is the
same
make samples/ compatible
make tools/ compatible



--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[los-...@googlecode.com]

Comment #1 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

dependency six added

r1281 is the last revision completely compatible with python 2.4 and 2.5

In the near time you can only use py 2.6 or 2.7

[los-...@googlecode.com]

Comment #2 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

Comment by project member ccanepacc, Today (moments ago)
At r1289 all the test/*.py have the compatibility line

from __future__ import division, print_function, unicode_literals

All the division operations have been inspected and disambiguated so as the
meaning (integer or float division) is one intended when the script was
written.

Added a script
tools/check_py3_prefix.py
to check that all scripts in test/ have been inspected and changed.

[los-...@googlecode.com]

Comment #3 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

at r1290 utest/ disambiguated and made p23 sintax-compatible.
test results in py 2.6 same as in prev revisions.

[los-...@googlecode.com]

Comment #4 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

Maybe the minimun py version supported should be raised to 2.6.5:

"""
Also in 2.6 (before python 2.6.5 RC1+) unicode literals doesn't play nice
with keyword arguments (issue4978):
"""

http://stackoverflow.com/questions/809796/any-gotchas-using-unicode-literals-in-python-2-6

[los-...@googlecode.com]

Comment #5 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

need to investigate: in the hints to vertex list for pyglet, like "v2i"
or "t2f", "v3f/stream","c4B" , which type is expecting pyglet ? bytes or
what ?

Seen in cocos/draw.py , samples/demo_flag3d.py ; surely they are more.

[los-...@googlecode.com]

Comment #6 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

at r1302 , in branches/b_py_3, files in
cocos/
actions/
layers/
resources/
scenes/
test/
utest/

are all syntax compatible, and division disambiguated, with both py2 and 3,
except the files
cocos\collision_model.py
cocos\grid.py
cocos\shader.py

cocos/audio remains untouched.

r1281 was the last 'pure 2.x' cocos revision.

The unit tests in utest/ give the same results in r1302 as in r1281

Snapshotting the runs of test/test_*.py with tools/autotest/recon.py at
r1281 and then comparing with snapshots in r1302 (using
tools/autotest/snapcompare.py) gives pixel identical images.

So the refactor is neutral in py 2.x , x>=6

[los-...@googlecode.com]

Comment #7 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

r1303 adds a tentative conversion of cocos/audio and subfolders.
That code interacts with SDL buffers, probably will need more work.

An alternative is to drop all SDL audio, which does not support modern Macs
(darwin support, no Cocoa support)

[los-...@googlecode.com]

Comment #8 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

Conversion of cocos.euclid is going on https://github.com/euclid3/euclid3

[los-...@googlecode.com]

Comment #9 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

A py3 compatible euclid incorporated to branch b_py3 at r1308, corresponds
to
https://github.com/euclid3/euclid3 master at 2014 02 18 , sha e1157b

[los-...@googlecode.com]

Comment #10 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

The old code in CocosNode.add fails in py3 when adding a node whit same z
as an existing child, by example in test_anchor_sprites.py, test_batch2.py,
test_fluent.py, test_hierarchy2.py, test_loop.py, test_rect.py

The traceback is similar to
Traceback (most recent call last):
File "test_anchor_sprites.py", line 72, in <module>
main()
File "test_anchor_sprites.py", line 67, in main
test_layer = TestLayer ()
File "test_anchor_sprites.py", line 40, in __init__
self.add( sprite3 )
File "..\cocos\cocosnode.py", line 455, in add
bisect.insort( self.children, elem )
TypeError: unorderable types: Sprite() < Sprite()

An initial fix was committed at r1314, which inlines a customized
bisect.insort_right.
It works, but now the insertion is done in python, and before its was done
in the C extension, so node additions will be slower.

[los-...@googlecode.com]

Comment #11 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

Some tests are failing due to pyglet problems.

one is py3 specific:
http://code.google.com/p/pyglet/issues/detail?id=704
I submitted a patch for this.
Affected tests: test_htmllabel.py

the other is for any python but windows specific:
http://code.google.com/p/pyglet/issues/detail?id=702
Affected tests: test_htmllabel.py, test_rich_label.py
I suggested a fix for this.

[los-...@googlecode.com]

Comment #12 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

At r1320 running a tools/autotest/recon.py in the clean mode runs all
scripts in py3 without tracebacks, except for the one comming from pyglet
problems.

Besides the two pyglet issues above, theres a problem when taking snapshots
fullscreen, reported as http://code.google.com/p/pyglet/issues/detail?id=707

Now I need to compare (snapshots of tests runs with py2.6) with the
corresponding ones in py3

[los-...@googlecode.com]

Comment #13 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

Issue 707 on pyglet turned to be an issue in 2to3, reported at python
bugtracker as
http://bugs.python.org/issue20867
It only affects Windows.
As it may take some time to be fixed in python a warning should be added in
the release notes.

[los-...@googlecode.com]

Comment #14 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

status report at r1334

The automatic comparison of snapshots for the test/*.py scripts, between
revision r1281 (just before any py3 change) and r1334 (last commit in
branch b_py3), the first taken under py2.6.6, the last under py3.3.1 gives:

177 scripts runs with snapshots being equal at any pixel

14 are not compared because anomalies in the code taking automatic
snapshots, they are
test/test_SequenceScene.py
test/test_camera_orbit.py
test/test_draw_elbows2.py
test/test_fadeto.py
test/test_jumptiles3d.py
test/test_pyglet_vb.py
test/test_schedule_interval.py
test/test_text_movement.py
test/test_transition_zoom.py
test/test_transitions_with_pop_recipe.py

7 scripts give non matching snapshots between the two runs, like:

test/test_rect.py : draw order for childs with same z is different, this
comes from a change in CocosNode.add() This needs to be reviewed,
tentatively I think the new behavior is correct (old behavior from implicit
and unknown details of bisect module, new behavior from explicit inlined
and customized bisect code)

test/test_animation.py : the test plays a sprite animation, and snapshots
at the same time show different animation frames under 2 vs 3.
Needs more investigation, probably the snapshot machinery or a pyglet
behavior change between 2 and 3

test/test_scrolling_manager_without_tiles.py
test/test_scrolling_manager_without_tiles_autoscale.py
Strange. The visible sprite position is different.

test/test_tiles_autotest.py
test/test_tmx_autotest.py
Currently I see diferences in the debug info ( CTRL + D ), some labels are
seen and others not. This may come from the change in CocosNode.add

test/test_action_non_interval.py : Green square renders at same position,
small red squares show at different locations.
I have a weak suspect in schedule_interval : it was involved in others
cases of non-repeteability for snapshots under the same python

[los-...@googlecode.com]

Comment #15 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

Further examination of cases with non matching snapshots:

test/test_scrolling_manager_without_tiles.py
test/test_scrolling_manager_without_tiles_autoscale.py
fixed at r1335, was an euclid bug in py3

test/test_animation.py
some runs give equal snapshot sequence, some not.
Probably the special clock used to take the snapshots needs an upgrade for
truly repeatable schedule_interval

test/test_action_non_interval.py
adding debug prints shows that red's position are not equal from the first
step.
adding more prints shows matching positions until in r1281 it spawns second
bullet, and in r1335 does not.
Probably the same as in previous script.

test/test_tiles_autotest.py
test/test_tmx_autotest.py
Differences in debug mode labels, they draw in different order.
Partially explained because tiles uses unordered batches.

test/test_rect.py : draw order for childs with same z is different, this
comes from a change in CocosNode.add() This needs to be reviewed,
tentatively I think the new behavior is correct (old behavior from implicit
and unknown details of bisect module, new behavior from explicit inlined
and customized bisect code)

Visual inspection of the scripts not automatically compared show same
behavior between r1281 and r1335.

Now to convert code under samples/ and tools/

[los-...@googlecode.com]

Comment #16 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

All cocos code is now 2 and 3 compatible.
Landed in trunk at r1347

Need to adjust and test setup.py

[los-...@googlecode.com]

Comment #17 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

pyglet issues #702 and #704 fixed / workarounded in repo default after
c7f948

While upgrading setup.py to handle a (pyglet) dependency from repo at a
specific revision a bug in setuptools 3.3 was found, Windows only, when it
will pull from the repo but will left installed the tip, not the requested
revision.

Reported to setuptools at
https://bitbucket.org/pypa/setuptools/issue/170/with-dependency-link-to-an-hg-repo-install

[los-...@googlecode.com]

Updates:
Status: Fixed

Comment #18 on issue 207 by ccan...@gmail.com: Be python 3 compatible
http://code.google.com/p/los-cocos/issues/detail?id=207

made to cocos 0.6.0