On 12 Jan, 10:04 pm, martin at v.loewis.de wrote: >>[...] >>>I've done a fair bit of 3.x porting, and I'm firmly convinced that >>>2.x can do nothing: >>[...] >>>Inherently, 2.8 can't improve on that. >> >>I agree that there are limitations like the ones you've listed, but I >>disagree with your conclusion. Maybe you assume that it's just as >>hard >>to move to 2.8 (using the py3k backports not available in say 2.5) as >>it >>is to 3.x? > >Not at all, no. I'd rather expect that code that runs on 2.7 will run >on 2.8 unmodified. >>But a hypothetical 2.8 would also give people a way to move closer to >>py3k without giving up on using all their 2.x-only dependencies. > >How so? If they use anything that is new in 2.8, they *will* need to >drop support for anything before it, no??? >>I think it's much more likely that libraries like Twisted can support >>2.8 >>in the near future than 3.x. > >Most likely, Twisted "supports" 2.8 *today* (hopefully). But how does >that help Twisted in moving to 3.2? I'm not reading this thread carefully enough to make any arguments on either side, but I can contribute a fact. Twisted very likely does not support 2.8 today. I base this on the fact that Twisted does not support 2.7 today, and I expect 2.8 will be more like 2.7 than it will be like 2.3 - 2.6 (which Twisted does support). When I say "support" here, I mean "all of the Twisted unit tests pass on it". Jean-Paul
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4