Hi Claudio, Thanks for the example. I see what you mean. There might be software out there that is relying on overridding some private methods, such as the old setters and getters, but in my personal opinion it's not an excuse to hold back modernization of the modules. These private methods are not intended to be used by end-users, so are unlikely to cause trouble to users who are following the API documentation. For other projects that are relying on overridding these methods, I think it's fair to ask them to update their code, so that pyglet can continue to evolve.
I suppose a workaround would be to add the old _set_x() methods back to the module, but it would be a lot of extra cruft in the code. Just my personal opinions -Ben On Thursday, March 24, 2016 at 11:32:11 AM UTC+9, claudio canepa wrote: > > > > On Wed, Mar 23, 2016 at 10:36 PM, Benjamin Moran <[email protected] > <javascript:>> wrote: > >> Hi Claudio, >> >> With regards to your question #3, in what way does it break support? I >> know Cocos has it's own sprite.py module, so I'm curious what the issue is. >> > > Example with one property, which is written in the old style like it was > pyglet > > class Sprite(BatchableNode, pyglet.sprite.Sprite): > ... > > def _set_rotation(self, a): > BatchableNode._set_rotation(self, a) > pyglet.sprite.Sprite._set_rotation(self, a) > > this explodes because now theres no _set_rotation in pyglet.sprite.Sprite > > Hmm... for any pyglet class with the @property refactor made as in Sprite, > user code that subclasses that class and overrides the setter/getter and > calls the superclass setter/getter will break > > > > >> I did the property decorator refactor, but it should have been mostly >> cosmetic. I think one or two methods were marked as depricated, but it >> should be functionally identicle. >> I'm curious what the issue is. >> >> Thanks, >> -Ben >> >> >> >> On Wednesday, March 23, 2016 at 6:06:57 AM UTC+9, claudio canepa wrote: >>> >>> With the current tip of pyglet master at bitbucket >>> >>> ( >>> K:\cocos_pristine\pyglet\examples>hg parents >>> changeset: 3429:f10760f57976 >>> tag: tip >>> user: Rob van der Most <[email protected]> >>> date: Tue Mar 15 17:08:11 2016 +0100 >>> files: pyglet/media/drivers/directsound/__init__.py >>> description: >>> Use generic player worker for DirectSound driver >>> ) >>> >>> >>> Running on win7-64bits I got tracebacks running >>> example/image_display.py, both in py 2.7.11 64 bits and py 3.5.1 64 bits >>> >>> traceback in py27-64bits: http://pastebin.com/QQu28iDJ >>> traceback in py35-64bits: http://pastebin.com/Z1ryM9UZ >>> traceback in py27-32bits: http://pastebin.com/XU1vGntf >>> >>> Looking at commit logs seems that a heavy refactor is on course, so: >>> 1. master is supposed to work right now on windows ? >>> >>> 2. changes is setup.py seems to imply that the current codebase is >>> directly compatible with py3 and py2 (no 'use_2to3' or other >>> transformations necessary), is that correct ? >>> >>> 3. The pyglet version in setup.py is 1.3,0a1 . I noticed changes in >>> pyglet's Sprite properties breaks cocos's Sprites, so, how much disruptive >>> are meant to be the changes from 1.2 to 1.3 ? >>> >>> 4. any tip to manage transition from 1.2 to 1.3 ? >>> >>> >>> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/pyglet-users. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
