On 1/1/07, Barry Warsaw <[EMAIL PROTECTED]> 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
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
