[Python-3000] PEP 3108: Standard Library Reorganization

Barry Warsaw barry at python.org
Tue Jan 2 07:48:55 CET 2007


-----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.

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.

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.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRZoAWHEjvBPtnXfVAQKcqwP/aVuZfWW6XWSlIZkFejndNscTbwrBc3Bz
qFEudQ4fcvZVGLa70u+q6oVLHnmINZ3rcYKogzsBC5VgZYcxkOC54BP9EhxZ8N1A
Byxmcb/pd4bmx1llaFZmEtNZFWnTRW9W+JK6PHkuRkcizH3sTlQLZ9dIKgKKsck1
iVao7uVvX2Y=
=Sjeg
-----END PGP SIGNATURE-----


More information about the Python-3000 mailing list