Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
On 11:15 am, _...@lvh.cc wrote: >I hear tickets is how you get things done: http://tm.tl/5181 But not this. If we want *new* backwards compatibility stuff to be private, then give it a private name. The old stuff is public though, so it should be treated how we treat public stuff. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
I hear tickets is how you get things done: http://tm.tl/5181 ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
On Jul 5, 2011, at 8:32 AM, Laurens Van Houtven wrote: > In doing twisted.positioning I find my self writing a bunch of code in ways I > would ordinarily write it differently, because we have to support 2.4 still > (when is that going away? Isn't the most recent RHEL 2.6 already?). > > Is there some way to register that so that as soon as we stop supporting 2.4, > we can make a lot of code a lot prettier? For certain functions such as > any/all, perhaps a twisted.python._backports (with the explicit mention that > code in backports will go away as soon as the version it's built to work > around is no longer supported). That way, as soon as you support 2.5 (which > has any/all), you just remove it from _backports, see which tests break, > remove the imports, run tests again, commit. Woo! > > Of course, _backports is obviously not a solution for everything, since not > every language feature can be fixed by defining a class or a function > somewhere. Yes, we've done that many times before, in twisted.python.compat. (that should probably be an _ module now; it has always been treated as such, but it's not named appropriately.) ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
On Tue, Jul 5, 2011 at 2:41 PM, Laurens Van Houtven <_...@lvh.cc> wrote: > By "registration" I meant stuff where we could put reminders that some code > can be cleaned up now. > > Perhaps that means "ticket", if there's some way to mark a ticket as being > only relevant when we stop supporting $PYTHON_VERSION_WHATEVER? > Jp's excellent points aside, could we just use the code itself to do this? Whenever you see something that looks overly complicated and it turns out that that complexity is there to provide support for older Pythons, add a comment saying so. "2.3" is fairly easy to grep for, and it's almost always a good idea to explain the motive behind ugly code. jml ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
On Tue, 2011-07-05 at 14:32 +0200, Laurens Van Houtven wrote: > In doing twisted.positioning I find my self writing a bunch of code in > ways I would ordinarily write it differently, because we have to > support 2.4 still (when is that going away? Isn't the most recent RHEL > 2.6 already?). The plan was to drop 2.4 as of 11.2. At the rate things are going (someone review #5118 so I can merge it and put up #5063 for review!) we may not have 11.2 this year, only 11.1... in which case I'd be happy to drop 2.4 in this release. Others may disagree - discuss it here: http://twistedmatrix.com/trac/ticket/4962 ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
On 01:41 pm, _...@lvh.cc wrote: >By "registration" I meant stuff where we could put reminders that some >code >can be cleaned up now. > >Perhaps that means "ticket", if there's some way to mark a ticket as >being >only relevant when we stop supporting $PYTHON_VERSION_WHATEVER? In the past we haven't tried too hard to do this kind of tracking, because we have actually avoided going out of our way to break Twisted in lots of ways for older versions of Python after we stop supporting them. Going through the codebase and making changing things to use Python 2.5 features *just* because we don't have to make the code run on Python 2.4 anymore is to be avoided. Instead, code can be updated to Python 2.5 syntax and APIs where changes are being made anyway and/or where the Python 2.5 version otherwise reduces the maintenance burden. Otherwise, it's just busywork from which no one really benefits. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
By "registration" I meant stuff where we could put reminders that some code can be cleaned up now. Perhaps that means "ticket", if there's some way to mark a ticket as being only relevant when we stop supporting $PYTHON_VERSION_WHATEVER? cheers lvh ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
On 12:32 pm, _...@lvh.cc wrote: >Hi, > > >In doing twisted.positioning I find my self writing a bunch of code in >ways >I would ordinarily write it differently, because we have to support 2.4 >still (when is that going away? Isn't the most recent RHEL 2.6 >already?). > >Is there some way to register that so that as soon as we stop >supporting >2.4, we can make a lot of code a lot prettier? For certain functions >such as >any/all, perhaps a twisted.python._backports (with the explicit mention >that >code in backports will go away as soon as the version it's built to >work >around is no longer supported). That way, as soon as you support 2.5 >(which >has any/all), you just remove it from _backports, see which tests >break, >remove the imports, run tests again, commit. Woo! > >Of course, _backports is obviously not a solution for everything, since >not >every language feature can be fixed by defining a class or a function >somewhere. Previously we've added things like this - socket.inet_pton, set, even dict long, long ago - to twisted.python.compat, which sounds similar to the _backports module you suggest. I didn't think of the addition of such things to a module as "registration" or I would have mentioned this when you asked before on IRC. :) Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] Ways to register stuff only done for backwards compatibility
Hi, In doing twisted.positioning I find my self writing a bunch of code in ways I would ordinarily write it differently, because we have to support 2.4 still (when is that going away? Isn't the most recent RHEL 2.6 already?). Is there some way to register that so that as soon as we stop supporting 2.4, we can make a lot of code a lot prettier? For certain functions such as any/all, perhaps a twisted.python._backports (with the explicit mention that code in backports will go away as soon as the version it's built to work around is no longer supported). That way, as soon as you support 2.5 (which has any/all), you just remove it from _backports, see which tests break, remove the imports, run tests again, commit. Woo! Of course, _backports is obviously not a solution for everything, since not every language feature can be fixed by defining a class or a function somewhere. cheers lvh ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
