----- Original Message ----- > On 23/07/13 03:16 -0400, Bohuslav Kabrda wrote: > > ----- Original Message ----- > >> On 19/07/13 02:41 -0400, Bohuslav Kabrda wrote: > >>> ----- Original Message ----- > >>>> On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote: > >>>>> FAQ: > >>>>> Q: Why do we need to switch to Python 3? > >>>>> A: Because Python 2 is old, slower, less pythonic, doesn't get any more > >>>>> functionality and it won't be that long before the official upstream > >>>>> support ends [1] > >>>>> > >>>> Although I agree with the need to switch to python3, I don't think the > >>>> first > >>>> three reasons are very compelling arguments (they're only half-truths) > >>>> -- > >>>> we > >>>> should concentrate on the last reason and also on features that python3 > >>>> has that pyhton2 doesn't. Chained exceptions are a pretty nice thing, > >>>> for > >>>> instance. > >>>> > >>> > >>> So first three reason: > >>> - Python 2 is old - how is that a half-truth? > >>> - Slower - yes, in the beginning, Python 3 was significantly slower > >>> because of nonoptimal code after the rewrite from Python 3. But with > >>> Python 3.3 for instance, you get tons of speed improvements - > >>> decimal module for instance got a significant boost. Brett Cannon > >>> had a nice presentation about speed benchmarking [1]. Yes, Python 3 > >>> is slower in some areas, but mostly it's faster. > >> > >> Mind to share some grounds for this claim? My negligible experience > >> told me the contrary, but perhaps timeit module is a bad indicator. > >> > > > > There is the presentation that I referenced in the email that you > > reacted to (referenced by [1]). > > Saw the presentation before actually replying -- it doesn't show > any evidence Python 3.3 would be noticably faster. And my micro > tests unfortunately fell into the "slower" category as nicely > demonstrated in the graphs there. > Yes, it is not _noticably_ faster, I agree. The thing is that micro tests do tend to be slower on Python 3.3 because of different integer and string representations. Things start to change when you start to use stdlib. > > You can also have a look at pystone benchmark results (a quick googling > > around gave me e.g. > > http://www.levigross.com/post/2340736877/pystone-benchmark-on-2-6-2-7-3-2) > > This is more than two years old. The score reliability of this benchmark > is also questionable (not speaking about order of magnitude difference as > with PyPy). > Yeah, PyPy is known to be a lot faster than any cPython. The problem with PyPy is that C extension support is still in beta [1] and requires some patching. So unfortunately PyPy is not suitable for default Python implementation for distribution such as Fedora, IMO. > >> Otherwise yes, let's get gently beyond 3000. > > -- > Jan -- Regards, Bohuslav "Slavek" Kabrda. [1] http://doc.pypy.org/en/latest/faq.html#do-cpython-extension-modules-work-with-pypy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
