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