[Python-3000] [Python-Dev] What should the focus for 2.6 be?

[Guido van Rossum]

On 8/21/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> As we approach Py3k, I again ask, "what are the compelling features?"
> Wholesale breakage of anything that uses ascii strings as text or binary
> data? A completely changed IO stack (requiring re-learning of everything
> known about Python IO)?  Dictionary .keys(), .values(), and .items()
> being their .iter*() equivalents (making it just about impossible to
> optimize for Py3k dictionary behavior now)?

I guess py3k is not for you yet. That's a totally defensible point of
view, and that's why there will be Python 2.6, 2.7, 2.8 and 2.9
(probably) which will gradually close the gap, after which you will
have the choice of maintaining 2.9 yourself or making the switch. :-)

> I understand getting rid of the cruft, really I do (you should see some
> cruft I've been replacing lately). But some of that cruft is useful, or
> really, some of that cruft has no alternative currently, which will
> require significant rewrites of user code when Py3k is released.  When
> everyone has to rewrite their code, they are going to ask, "Why don't I
> just stick with the maintenance 2.x? It's going to be maintained for a
> few more years yet, and I don't need to rewrite all of my disk IO,
> strings in dictionary code, etc.  I will be right along with them (no
> offense intended to those currently working towards py3k).

And yet offense is taken. Have you watched the video of my Py3k talk?
Search for it on Google Video.

> I can code defensively against buffer-sturating DOS attacks with my
> socket code, but I can't code defensively to handle some (never mind all)
> of the changes and incompatabilities that Py3k will bring.

And that's why there will be conversion tools and aids.

> Here's my suggestion: every feature, syntax, etc., that is slated for
> Py3k, let us release bit by bit in the 2.x series.  That lets the 2.x
> series evolve into the 3.x series in a somewhat more natural way than
> the currently proposed *everything breaks*.  If it takes 1, 2, 3, or 10
> more releases in the 2.x series to get to all of the 3.x features, great.
> At least people will have a chance to convert, or at least write correct
> code for the future.

That will happen, whenever possible. For other features it is infeasible.

> Say 2.6 gets bytes and special factories (or a special encoding argument)
> for file/socket to return bytes instead of strings, and only accept
> bytes objects to .write() methods (unless an encoding on the file, etc.,
> was previously given). Given these bytes objects, it may even make sense
> to offer the .readinto() method that Alex B has been asking for (which
> would make 3 built-in objects that could reasonably support readinto:
> bytes, array, mmap).
>
> If the IO library is available for 2.6, toss that in there, or offer it
> in PyPI as an evolving library.

Could do.

> I would suggest pushing off the dict changes until 2.7 or later, as
> there are 340+ examples of dict.keys() in the Python 2.5b2 standard
> library, at least half of which are going to need to be changed to
> list(dict.keys()) or otherwise.  The breakage in user code will likely
> be at least as substantial.

Perhaps you want to help write the transition PEP?

> Those are just examples that come to mind now, but I'm sure there are
> others changes with similar issues.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)