On Oct 28, 2009, at 9:52 PM, Mike Orr wrote: > On Wed, Oct 28, 2009 at 10:27 AM, Mario Ruggier <[email protected]> > wrote: >> >> On Tue, Oct 27, 2009 at 9:27 PM, Mike Orr <[email protected]> >> wrote: >>> On Tue, Oct 27, 2009 at 4:07 AM, Mario Ruggier <[email protected]> >>> wrote:
>>> In the long term it would seem even more restraining, although >>> presumably you could abandon the policy in a year or two. >> >> Well, yes, that's the price to pay for having a unique code base (and >> dist package). In any case, you would still gain on other py3 >> features, like performance, when running under py3. > > Has Python 3's performance caught up to Python 2's yet? For a while > the I/O system was in Python though I think it's in C now, but the > last stats I saw showed Python 3 running slower. Sorry, I meant to say performance in some areas, like systematic returning iterators instead of lists e.g for dict.keys, map(), filter(), etc. For the general performance profile I believe you are right, py3 is still slower... >> But, name me *one* >> py3 feature for which a legacy package *must* have ?!? > > You can say the same about Python 2.6 features, Python 2.5 features, > etc. You don't *have* to use them and some people don't care, but > other people do and would like to use the features. For instance, > named tuples and defaultdict, which were added in 2.6. I had to > reimplement defaultdict in WebHelpers so it would be compatible with > 2.5. I still haven't used named tuples yet because we only switched > to Python 2.6 at work a few months ago. But, the key point here is *legacy*... in general you want to make a legacy (working, deployed) package available to py3 world for the benefit of applications that wish to migrate to py3 and need to carry over the dependency, and *not* to "selfishly" take advantage of the benefits of the new language version. Presumably, if anything is working in 2.5, it can be made to work on both 2.5 and 3.0 from the same code base, without deprecating anything in the 2.5 version or without back-porting any features of the new lang version. Of course if you want to back-port some 3.0 feature into your 2.5 version, then special work as you describe is needed... but then the question does not anymore concern support for 3.0 but whether you still want to support 2.5 and for how long. For the defaultdict example, it would be another type defn that will be obtained differently when running under 2.5 as opposed to when running under 3.0. m. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
