On Fri, 2008-04-18 at 17:25 +0200, python-list-request@python. org wrote:
of the major issues that prompted the Py3K push in the first place. The
accumulated cruft had gotten heavy, and was slowing python down. Py3K
is deliberately conservative, so that the transition will be as painless
as possible, but strips away the warts that were slowing things down.
Having print as a statement meant it was difficult to add functionality
there. Supporting both new and old style classes meant that you
couldn't count on expected functionality in external libraries. The
string/unicode dichotomy caused innumerable headaches for everybody.
The big changes you are hoping for to justify py3k won't come in python
3.0. They'll come in python 3.2 and python 3.3.
Of course, I'm well aware that I'm talking about vaporware, but making
the architectural changes now to make that advancement possible in the
future is the point of python 3.0.
In the meantime, your code will always work on Python 2.5. If you're
worried about wild code, bundle it with its own interpreter when you
distribute it. It'll survive.
Cheers,
Cliff
I really like developing in Python -- but it's hard
to keep doing it when the growth curve is so slow
and a so many people have deep reservations about it,
inspired in part, justifiably, by nonsense like this.
In fact, I basically stopped. Then I came back. Now
I'm wondering if it was such a good idea...
>
-- Aaron Watters
to keep doing it when the growth curve is so slow
and a so many people have deep reservations about it,
inspired in part, justifiably, by nonsense like this.
In fact, I basically stopped. Then I came back. Now
I'm wondering if it was such a good idea...
>
-- Aaron Watters
>From what I've read, the slowness of the growth curve was actually one
accumulated cruft had gotten heavy, and was slowing python down. Py3K
is deliberately conservative, so that the transition will be as painless
as possible, but strips away the warts that were slowing things down.
Having print as a statement meant it was difficult to add functionality
there. Supporting both new and old style classes meant that you
couldn't count on expected functionality in external libraries. The
string/unicode dichotomy caused innumerable headaches for everybody.
The big changes you are hoping for to justify py3k won't come in python
3.0. They'll come in python 3.2 and python 3.3.
Of course, I'm well aware that I'm talking about vaporware, but making
the architectural changes now to make that advancement possible in the
future is the point of python 3.0.
In the meantime, your code will always work on Python 2.5. If you're
worried about wild code, bundle it with its own interpreter when you
distribute it. It'll survive.
Cheers,
Cliff