[Python-3000] PEP 3108: Standard Library Reorganization

[Brett Cannon]

On 1/1/07, Barry Warsaw <barry at python.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jan 1, 2007, at 10:46 PM, Anthony Baxter wrote:
>
> > I could not agree more. The list of modules Brett gave covers enough
> > that pretty much every single piece of code I have will need to be
> > edited. Worse yet, I _can't_ edit it and change it to the new names
> > unless I want to abandon pre-2.6 compatibility. This is completely
> > unacceptable. Living with a huge spew of warnings is not an
> > acceptable outcome - for those of us running production systems in
> > Python, a warning should be an indication of something to be fixed,
> > not pointless log-filler.
>
> I agree with everything Anthony just said.  One of the things I tried
> to do with the email package in Python 2.5 was transition to PEP 8
> names, but hack in enough backward compatibility that the old module
> names would Just Work.  I think I was largely successful at that --
> the only disconnect is that code that failed in Python 2.4 would fail
> slightly differently in Python 2.5, but nothing that worked in 2.4
> would fail in 2.5.


The PEP has already been changed to use PendingDeprecationWarning, so that
will be as noisy as it gets.  From this point forward it will just be a
quieter warning.

To me, a standard library reorganization would proceed like this:
> figure out the new hierarchy and package names now and implement them
> for Python 2.6.  Make sure every old package name continues to work,
> but encourage people (through documentation and social coercion, not
> through warnings) to start using the new hierarchy.  Issue no
> warnings in Python 2.6 unless the magical -3 flag were given, but
> never make the old hierarchy issue errors in Python 2.x.  I
> personally wouldn't care if the old hierarchy just disappears in
> Python 3.0 if the Magical Code Tranmogrifier did most of the
> conversion work well enough.


Well, if someone wants to propose a -3 flag for warnings that's fine, but I
think that is a separate PEP.

As for just having the old naming never have a warning, I can live with that
if people are okay with it just disappearing in Py3K and completely relying
on the refactoring tool.  Is that what people want?


As for the mass extinction being planned, I'm not so sure.  I have a
> vague unease about it.  For one thing I think that the str/unicode ->
> unicode/bytearray change will be disruptive enough that we may not
> fully understand what interfaces we really want until that happens.
> I also have this feeling that by ditching so much that's widely used,
> we're setting Python 3.0 up for a lot of criticism that the batteries
> were removed.  For example, as icky as all those server modules are,
> they're darn handy and a lot of code has been written for them.
> Maybe I'm totally off base here, but it seems like it's one thing to
> restructure the hierarchy, and pepify the names, but it's another to
> just remove code unless there are compelling enough alternatives that
> folks are willing to rewrite everything to use them.


The server modules are not slated for removal.  All I proposed in the PEP
was grouping them in a package.  One person suggested (or at least I thought
they had) of there removal.  I said it can be discussed.  I am much more
lenient in removing modules for the removal list then adding to it.

But I don't think it is that far overboard.  Most of the stuff being
suggested is either old or marginal (in my opinion).  And people are already
speaking up on the ones that really should stick around (telnetlib and
fileinput).  This is all a give-and-take and we can find a balance.  Plus
Guido has not cleared anything so he might totally disagree with what I have
said (but I bet he is waiting for people to help me get this list to a good
set first).  Even with what I suggested there is still a ton of stuff in the
stdlib.  I really don't think anyone is going to think we pulled a battery
out of the stdlib.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070102/7cee4ba1/attachment.htm