Future indeed looks better. I am also wondering what using a library like that does to performance. In essence most of the code can be written in a way that works the same on Py2 and Py3, so only the places were differences occur must be checked. In some places there are already similar functions in use (pyglet.compat.*).
My main pro would be that it becomes easy to develop and test for Py2 and Py3 at the same time. If I want to fix a Py3 specific bug, I currently need to install a develop version that is passed through 2to3 and then port the changes back to the original Py2 version. Then have to run 2to3 again to check. With Future, Pyglet would in essence by a Py3 library, with some backward compatibility fixes through future. Rob Op donderdag 5 februari 2015 10:31:33 UTC+1 schreef Nicola Larosa (tekNico): > > Rob wrote: > > Currently we natively support Py2 and support Py3 through 2to3. Fixing > > issues in Py3 is quite a hassle like this, but we also do not want to > > lose Py2 support yet. How would you feel about using a library like > > six to create a codebase that supports both Py2 and Py3 without 2to3? > > Rather than six, you want to use future <http://python-future.org/>. > > Here's why: > > What is the relationship between future and six? > < > http://python-future.org/faq.html#what-is-the-relationship-between-future-and-six> > > > > -- > Nicola 'tekNico' Larosa <http://www.tekNico.net/> > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
