Mailing List Archive

On Mon, 27 Mar 2000, Peter Funk wrote:

> If the result of this renaming initiative will be that I can't use
> import sys, os, time, re, struct, cPickle, parser
> import Tkinter; Tk=Tkinter; del Tkinter
> anymore in Python 1.x and instead I have to change this into (for example):
> form posix import time

from time import time

> from text import re
> from bin import struct
> from Python import parser
> from ui import Tkinter; ...

Yes.

> I would really really *HATE* this change!

Well, I'm sorry to hear that -- I'm waiting for this change to happen
for a long time.

> [side note:
> The 'from MODULE import ...' form is evil and I have abandoned its use
> in favor of the 'import MODULE' form in 1987 or so, as our Modula-2
> programs got bigger and bigger. With 20+ software developers working
> on a ~1,000,000 LOC of Modula-2 software system, this decision
> proofed itself well.

Well, yes. Though syntactically equivalent,

from package import module

Is the recommended way to use packages, unless there is a specific need.

> May be I didn't understand what this new subdivision of the standard
> library should achieve.

Namespace cleanup. Too many toplevel names seem evil to some of us.

> Why is a subdivision on the documentation level not sufficient?
> Why should modules be moved into packages? I don't get it.

To allow a greater number of modules to live without worrying about
namespace collision.
--
Moshe Zadka <mzadka@geocities.com>.
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com

Hi, Peter.

Your question as to the purpose of module reorganization is
well worth asking, and perhaps we should stand back for a
while and try to really answer it well first.

I think that my answers for your question would be:

1. To alleviate potential namespace collision.

2. To permit talking about packages as a unit.

I hereby solicit other reasons from the rest of the group...

Reason #1 is not a serious problem yet, but i think i've
seen a few cases where it might start to be an issue.
Reason #2 has to do with things like assigning people
responsibility for taking care of a particular package,
or making commitments about which packages will be
available with which distributions or platforms. Hence,
for example, the idea of the "unix" package.

Neither of these reasons necessitate a deep and holy
hierarchy, so we certainly want to keep it shallow and
simple if we're going to do this at all.

> If the result of this renaming initiative will be that I can't use
> import sys, os, time, re, struct, cPickle, parser
> import Tkinter; Tk=Tkinter; del Tkinter
> anymore in Python 1.x and instead I have to change this into (for example):
> form posix import time
> from text import re
> from bin import struct
> from Python import parser
> from ui import Tkinter; ...

Won't

import sys, os, time.time, text.re, bin.struct, data.pickle, python.parser

also work? ...i hope?

> The library documentation provides a existing logical subdivision into
> chapters, which group the library into several kinds of services.
> IMO this subdivision could be discussed and possibly revised.
> But at the moment I got the impression, that it was simply ignored.
> Why? What's so bad with it?

I did look at the documentation for some guidance in arranging
the modules, though admittedly it didn't direct me much.



-- ?!ng

"In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand."
-- Gerald Holton

Hi!

> > import sys, os, time, re, struct, cPickle, parser
[...]

Ka-Ping Yee:
> Won't
>
> import sys, os, time.time, text.re, bin.struct, data.pickle, python.parser
>
> also work? ...i hope?

That is even worse. So not only the 'import' sections, which I usually
keep at the top of my modules, have to be changed: This way for example
're.compile(...' has to be changed into 'text.re.compile(...' all over
the place possibly breaking the 'Maximum Line Length' styleguide rule.

Regards, Peter

Peter Funk said:
> The library documentation provides a existing logical subdivision into
> chapters, which group the library into several kinds of services.
> IMO this subdivision could be discussed and possibly revised.
> But at the moment I got the impression, that it was simply ignored.
> Why? What's so bad with it?

Ka-Ping Yee writes:
> I did look at the documentation for some guidance in arranging
> the modules, though admittedly it didn't direct me much.

The library reference is pretty well disorganized at this point. I
want to improve that for the 1.6 docs.
I received a suggestion a few months back, but haven't had a chance
to dig into it, or even respond to the email. ;(


-Fred

--
Fred L. Drake, Jr. <fdrake at acm.org>
Corporation for National Research Initiatives

>>>>> "PF" == Peter Funk <pf@artcom-gmbh.de> writes:

PF> That is even worse. So not only the 'import' sections, which I
PF> usually keep at the top of my modules, have to be changed: This
PF> way for example 're.compile(...' has to be changed into
PF> 'text.re.compile(...' all over the place possibly breaking the
PF> 'Maximum Line Length' styleguide rule.

There is nothing wrong with changing only the import statement:
from text import re

The only problematic use of from ... import ... is
from text.re import *
which adds an unspecified set of names to the current namespace.

Jeremy

Peter Funk said:
> The library documentation provides a existing logical subdivision into
> chapters, which group the library into several kinds of services.
> IMO this subdivision could be discussed and possibly revised.
> But at the moment I got the impression, that it was simply ignored.
> Why? What's so bad with it?

Ka-Ping Yee writes:
> I did look at the documentation for some guidance in arranging
> the modules, though admittedly it didn't direct me much.

Fred L. Drake, Jr. writes:
> The library reference is pretty well disorganized at this point. I
> want to improve that for the 1.6 docs.

Let me just mention where my inspirations came from: shame of shames, it
came from Perl. It's hard to use Perl's organization as is, because it
doesn't (view itself) as a general purpose langauge: so things like CGI.pm
are toplevel, and regex's are part of the syntax. However, there are a lot
of good hints there.


--
Moshe Zadka <mzadka@geocities.com>.
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com

On Mon, 27 Mar 2000, Jeremy Hylton wrote:

> >>>>> "PF" == Peter Funk <pf@artcom-gmbh.de> writes:
>
> PF> That is even worse. So not only the 'import' sections, which I
> PF> usually keep at the top of my modules, have to be changed: This
> PF> way for example 're.compile(...' has to be changed into
> PF> 'text.re.compile(...' all over the place possibly breaking the
> PF> 'Maximum Line Length' styleguide rule.
>
> There is nothing wrong with changing only the import statement:
> from text import re
>
> The only problematic use of from ... import ... is
> from text.re import *
> which adds an unspecified set of names to the current namespace.

Actually, i think there's another important gotcha with from .. import
which may be contributing to peter's sense of concern, but which i don't
think needs to in this case. I also thought we had discussed providing
transparency in general, at least of the 1.x series. ?

The other gotcha i mean applies when the thing you're importing is a
terminal, ie a non-module. Then, changes to the assignments of the names
in the original module aren't reflected in the names you've imported -
they're decoupled from the namespace of the original module.

When the thing you're importing is, itself, a module, the same kind of
thing *can* happen, but you're more generally concerned with tracking
revisions to the contents of those modules, which is tracked ok in the
thing you "from .. import"ed.

I thought the other problem peter was objecting to, having to change the
import sections in the first place, was going to be avoided in the 1.x
series (if we do this kind of thing) by inherently extending the import
path to include all the packages, so people need not change their code?
Seems like most of this would be fairly transparent w.r.t. the operation
of existing applications. Have i lost track of the discussion?

Ken
klm@digicool.com

On Mon, 27 Mar 2000, Ken Manheimer wrote:

> I also thought we had discussed providing
> transparency in general, at least of the 1.x series. ?

Yes, but it would be clearly marked as deprecated in 1.7, print out
error messages in 1.8 and won't work at all in 3000. (That's my view on
the point, but I got the feeling this is where the wind is blowing).

So the transperancy mechanism is intended only to be "something backwards
compatible"...it's not supposed to be a reason why things are ugly (I
don't think they are, though).

BTW: the transperancy mechanism I suggested was not pushing things into
the import path, but rather having toplevel modules which "from import *"
from the modules that were moved.

E.g.,
re.py would contain

# Deprecated: don't import re, it won't work in future releases
from text.re import *

--
Moshe Zadka <mzadka@geocities.com>.
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com

Peter> The library documentation provides a existing logical subdivision
Peter> into chapters, which group the library into several kinds of
Peter> services.

Perhaps it makes sense to revise the library reference manual's
documentation to reflect the proposed package hierarchy once it becomes
concrete.

--
Skip Montanaro | http://www.mojam.com/
skip@mojam.com | http://www.musi-cal.com/

Skip Montanaro writes:
> Perhaps it makes sense to revise the library reference manual's
> documentation to reflect the proposed package hierarchy once it becomes
> concrete.

I'd go for this. ;)


-Fred

--
Fred L. Drake, Jr. <fdrake at acm.org>
Corporation for National Research Initiatives

Peter Funk wrote:
> Why should modules be moved into packages? I don't get it.

fwiw, neither do I...

I'm not so sure that Python really needs a simple reorganization
of the existing set of standard library modules. just moving the
modules around won't solve the real problems with the 1.5.2 std
library...

> IMO this subdivision could be discussed and possibly revised.

here's one proposal:
http://www.pythonware.com/people/fredrik/librarybook-contents.htm

</F>

>>>>> "KLM" == Ken Manheimer <klm@digicool.com> writes:

>> The only problematic use of from ... import ... is
>> from text.re import *
>> which adds an unspecified set of names to the current
>> namespace.

KLM> The other gotcha i mean applies when the thing you're importing
KLM> is a terminal, ie a non-module. Then, changes to the
KLM> assignments of the names in the original module aren't
KLM> reflected in the names you've imported - they're decoupled from
KLM> the namespace of the original module.

This isn't an import issue. Some people simply don't understand
that assignment (and import as form of assignment) is name binding.
Import binds an imported object to a name in the current namespace.
It does not affect bindings in other namespaces, nor should it.

KLM> I thought the other problem peter was objecting to, having to
KLM> change the import sections in the first place, was going to be
KLM> avoided in the 1.x series (if we do this kind of thing) by
KLM> inherently extending the import path to include all the
KLM> packages, so people need not change their code? Seems like
KLM> most of this would be fairly transparent w.r.t. the operation
KLM> of existing applications.

I'm not sure if there is consensus on backwards compatibility. I'm
not in favor of creating a huge sys.path that includes every package's
contents. It would be a big performance hit.

Jeremy

On Tue, 28 Mar 2000, Jeremy Hylton wrote:

> >>>>> "KLM" == Ken Manheimer <klm@digicool.com> writes:
>
> >> The only problematic use of from ... import ... is
> >> from text.re import *
> >> which adds an unspecified set of names to the current
> >> namespace.
>
> KLM> The other gotcha i mean applies when the thing you're importing
> KLM> is a terminal, ie a non-module. Then, changes to the
> KLM> assignments of the names in the original module aren't
> KLM> reflected in the names you've imported - they're decoupled from
> KLM> the namespace of the original module.
>
> This isn't an import issue. Some people simply don't understand
> that assignment (and import as form of assignment) is name binding.
> Import binds an imported object to a name in the current namespace.
> It does not affect bindings in other namespaces, nor should it.

I know that - i was addressing the asserted evilness of

from ... import ...

and how it applied - and didn't - w.r.t. packages.

> KLM> I thought the other problem peter was objecting to, having to
> KLM> change the import sections in the first place, was going to be
> KLM> avoided in the 1.x series (if we do this kind of thing) by
> KLM> inherently extending the import path to include all the
> KLM> packages, so people need not change their code? Seems like
> KLM> most of this would be fairly transparent w.r.t. the operation
> KLM> of existing applications.
>
> I'm not sure if there is consensus on backwards compatibility. I'm
> not in favor of creating a huge sys.path that includes every package's
> contents. It would be a big performance hit.

Yes, someone reminded me that the other (better, i think) option is stub
modules in the current places that do the "from ... import *" for the
right values of "...". py3k finishes the migration by eliminating the
stubs.

Ken
klm@digicool.com

Hi!

> Peter Funk wrote:
> > Why should modules be moved into packages? I don't get it.
>
Fredrik Lundh:
> fwiw, neither do I...

Pheeewww... And I thought I'am the only one! ;-)

> I'm not so sure that Python really needs a simple reorganization
> of the existing set of standard library modules. just moving the
> modules around won't solve the real problems with the 1.5.2 std
> library...

Right. I propose to leave the namespace flat.

I like to argue with Brad J. Cox ---the author of the book "Object
Oriented Programming - An Evolutionary Approach" Addison Wesley,
1987--- who proposes the idea of what he calls a "Software-IC":
He looks closely to design process of electronic engineers which
ussually deal with large data books with prefabricated components.
There are often hundreds of them in such a databook and most of
them have terse and not very mnemonic names.
But the engineers using them all day *know* after a short while that a
7400 chip is a TTL-chip containing 4 NAND gates.

Nearly the same holds true for software engineers using Software-IC
like 're' or 'struct' as their daily building blocks.

A software engineer who is already familar with his/her building
blocks has absolutely no advantage from a deeply nested namespace.

Now for something completely different:
Fredrik Lundh about the library documentation:
> here's one proposal:
> http://www.pythonware.com/people/fredrik/librarybook-contents.htm

Whether 'md5', 'getpass' and 'traceback' fit into a category
'Commonly Used Modules' is ....ummmm.... at least a bit questionable.

But we should really focus the discussion on the structure of the
documentation. Since many standard library modules belong into
several logical catagories at once, a true tree structured organization
is simply not sufficient to describe everything. So it is important
to set up pointers between related functionality. For example
'string.replace' is somewhat related to 're.sub' or 'getpass' is
related to 'crypt', however 'crypt' is related to 'md5' and so on.

Regards, Peter
--
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)

Peter Funk quoted:
>Fredrik Lundh:
>> I'm not so sure that Python really needs a simple reorganization
>> of the existing set of standard library modules. just moving the
>> modules around won't solve the real problems with the 1.5.2 std
>> library...
>Right. I propose to leave the namespace flat.

I third that comment. Arguments against reorganizing for 1.6:

1) I doubt that we have time to do a good job of it for 1.6.
(1.7, maybe.)

2) Right now there's no way for third-party extensions to add
themselves to a package in the standard library. Once Python finds
foo/__init__.py, it won't look for site-packages/foo/__init__.py, so
if you grab, say, "crypto" as a package name in the standard library,
it's forever lost to third-party extensions.

3) Rearranging the modules is a good chance to break backward
compatibility in other ways. If you want to rewrite, say, httplib
in a non-compatible way to support HTTP/1.1, then the move from
httplib.py to net.http.py is a great chance to do that, and leave
httplib.py as-is for old programs. If you just copy httplib.py,
rewriting net.http.py is now harder, since you have to either
maintain compatibility or break things *again* in the next version
of Python.

4) We wanted to get 1.6 out fairly quickly, and therefore limited
the number of features that would get in. (Vide the "Python 1.6
timing" thread last ... November, was it?) Packagizing is feature
creep that'll slow things down

Maybe we should start a separate list to discuss a package hierarchy
for 1.7. But for 1.6, forget it.

--
A.M. Kuchling http://starship.python.net/crew/amk/
Posting "Please send e-mail, since I don't read this group": Poster is
rendered illiterate by a simple trepanation.
-- Kibo, in the Happynet Manifesto

> Maybe we should start a separate list to discuss a package hierarchy
> for 1.7. But for 1.6, forget it.

Yes! Please!

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

On Tue, 28 Mar 2000, Andrew M. Kuchling wrote:

> Peter Funk quoted:
> >Fredrik Lundh:
> >> I'm not so sure that Python really needs a simple reorganization
> >> of the existing set of standard library modules. just moving the
> >> modules around won't solve the real problems with the 1.5.2 std
> >> library...
> >Right. I propose to leave the namespace flat.
>
> I third that comment. Arguments against reorganizing for 1.6:

Let me just note that my original great renaming proposal was titled
"1.7". I'm certain I don't want it to affect the 1.6 release -- my god,
it's almost alpha time and we don't even know how to reorganize.
Strictly 1.7.

> 4) We wanted to get 1.6 out fairly quickly, and therefore limited
> the number of features that would get in. (Vide the "Python 1.6
> timing" thread last ... November, was it?) Packagizing is feature
> creep that'll slow things down

Oh yes. I'm waiting for that 1.6....I wouldn't want to stall it for the
world.

But this is a good chance as any to discuss reasons, before strategies.
Here's why I believe we should re-organize Python modules:
-- modules fall quite naturally into subpackages. Reducing the number
of toplevel modules will lessen the clutter
-- it would be easier to synchronize documentation and code (think
"automatically generated documentation")
-- it would enable us to move toward a CPAN-like module repository,
together with the dist-sig efforts.

--
Moshe Zadka <mzadka@geocities.com>.
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com

Andrew M. Kuchling wrote:
[snip]
> 2) Right now there's no way for third-party extensions to add
> themselves to a package in the standard library. Once Python finds
> foo/__init__.py, it won't look for site-packages/foo/__init__.py, so
> if you grab, say, "crypto" as a package name in the standard library,
> it's forever lost to third-party extensions.

That way lies madness. While I'm happy to carp at Java for
requiring "com", "net" or whatever as a top level name, their
intent is correct: the names grabbed by the Python standard
packages belong to no one but the Python standard
packages. If you *don't* do that, upgrades are an absolute
nightmare.

Marc-Andre grabbed "mx". If (as I rather suspect <wink>) he
wants to remake the entire standard lib in his image, he's
welcome to - *under* mx.

What would happen if he (and everyone else) installed
themselves *into* my core packages, then I decided I didn't
want his stuff? More than likely I'd have to scrub the damn
installation and start all over again.

- Gordon

On Tue, 28 Mar 2000, Gordon McMillan wrote:

> What would happen if he (and everyone else) installed
> themselves *into* my core packages, then I decided I didn't
> want his stuff? More than likely I'd have to scrub the damn
> installation and start all over again.

I think Greg Stein answered that objection, by reminding us that the
filesystem isn't the only way to set up a package hierarchy. In
particular, even with Python's current module system, there is no need to
scrub installations: Python core modules go (under UNIX) in
/usr/local/lib/python1.5, and 3rd party modules go in
/usr/local/lib/python1.5/site-packages. Need to remove stuff? Remove
whatever is in /usr/local/lib/python1.5/site-packages. Need to upgrade?
Just backup /usr/local/lib/python1.5/site-packages, remove
/usr/local/lib/python1.5/, install, and move 3rd party modules back from
backup. This becomes even easier if the standard installation is in a
JAR-like file, and 3rd party modules are also in a JAR-like file, but
specified to be in their natural place.

Wow! That was a long rant!

Anyway, I already expressed my preference of the Perl way, over the Java
way. For one thing, I don't want to have to register a domain just so I
could distribute Python code <wink>

--
Moshe Zadka <mzadka@geocities.com>.
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com

Gordon McMillan wrote:
>
> Andrew M. Kuchling wrote:
> [snip]
> > 2) Right now there's no way for third-party extensions to add
> > themselves to a package in the standard library. Once Python finds
> > foo/__init__.py, it won't look for site-packages/foo/__init__.py, so
> > if you grab, say, "crypto" as a package name in the standard library,
> > it's forever lost to third-party extensions.
>
> That way lies madness. While I'm happy to carp at Java for
> requiring "com", "net" or whatever as a top level name, their
> intent is correct: the names grabbed by the Python standard
> packages belong to no one but the Python standard
> packages. If you *don't* do that, upgrades are an absolute
> nightmare.
>
> Marc-Andre grabbed "mx". If (as I rather suspect <wink>) he
> wants to remake the entire standard lib in his image, he's
> welcome to - *under* mx.

Right, that's the way I see it too. BTW, where can I register
the "mx" top-level package name ? Should these be registered
in the NIST registry ? Will the names registered there be
honored ?

> What would happen if he (and everyone else) installed
> themselves *into* my core packages, then I decided I didn't
> want his stuff? More than likely I'd have to scrub the damn
> installation and start all over again.

That's a no-no, IMHO. Unless explicitly allowed, packages
should *not* install themselves as subpackages to other
existing top-level packages. If they do, its their problem
if the hierarchy changes...

--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/

Moshe Zadka wrote:

> On Tue, 28 Mar 2000, Gordon McMillan wrote:
>
> > What would happen if he (and everyone else) installed
> > themselves *into* my core packages, then I decided I didn't
> > want his stuff? More than likely I'd have to scrub the damn
> > installation and start all over again.
>
> I think Greg Stein answered that objection, by reminding us that the
> filesystem isn't the only way to set up a package hierarchy.

You mean when Greg said:
>Assuming that you use an archive like those found in my "small" distro or
> Gordon's distro, then this is no problem. The archive simply recognizes
> and maps "text.encoding.macbinary" to its own module.

I don't know what this has to do with it. When we get around
to the 'macbinary' part, we have already established that
'text.encoding' is the parent which should supply 'macbinary'.

> In
> particular, even with Python's current module system, there is no need to
> scrub installations: Python core modules go (under UNIX) in
> /usr/local/lib/python1.5, and 3rd party modules go in
> /usr/local/lib/python1.5/site-packages.

And if there's a /usr/local/lib/python1.5/text/encoding, there's
no way that /usr/local/lib/python1.5/site-
packages/text/encoding will get searched.

I believe you could hack up an importer that did allow this, and
I think you'd be 100% certifiable if you did. Just look at the
surprise factor.

Hacking stuff into another package is just as evil as math.pi =
42.

> Anyway, I already expressed my preference of the Perl way, over the Java
> way. For one thing, I don't want to have to register a domain just so I
> could distribute Python code <wink>

I haven't the foggiest what the "Perl way" is; I wouldn't be
surprised if it relied on un-Pythonic sociological factors. I
already said the Java mechanics are silly; uniqueness is what
matters. When Python packages start selling in the four and
five figure range <snort>, then a registry mechanism will likely
be necessary.

- Gordon

On Wed, 29 Mar 2000, Gordon McMillan wrote:

> And if there's a /usr/local/lib/python1.5/text/encoding, there's
> no way that /usr/local/lib/python1.5/site-
> packages/text/encoding will get searched.

Oh my god! I just realized you're right. Well, back to the drawing board.

> I haven't the foggiest what the "Perl way" is; I wouldn't be
> surprised if it relied on un-Pythonic sociological factors.

No, it relies on non-Pythonic (but not unpythonic -- simply different)
technical choices.

> I
> already said the Java mechanics are silly; uniqueness is what
> matters.

As in all things namespacish ;-)

Though I suspect a registry will be needed much sooner.
--
Moshe Zadka <mzadka@geocities.com>.
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com

> > Marc-Andre grabbed "mx". If (as I rather suspect <wink>) he
> > wants to remake the entire standard lib in his image, he's
> > welcome to - *under* mx.
>
> Right, that's the way I see it too. BTW, where can I register
> the "mx" top-level package name ? Should these be registered
> in the NIST registry ? Will the names registered there be
> honored ?

I think the NIST registry is a failed experiment -- too cumbersome to
maintain or consult. We can do this the same way as common law
handles trade marks: if you have used it as your brand name long
enough, even if you didn't register, someone else cannot grab it away
from you.

> > What would happen if he (and everyone else) installed
> > themselves *into* my core packages, then I decided I didn't
> > want his stuff? More than likely I'd have to scrub the damn
> > installation and start all over again.
>
> That's a no-no, IMHO. Unless explicitly allowed, packages
> should *not* install themselves as subpackages to other
> existing top-level packages. If they do, its their problem
> if the hierarchy changes...

Agreed. Although some people seem to *want* this. Probably because
it's okay to do that in Java and (apparently?) in Perl. And C++,
probably. It all probably stems back to Lisp. I admit that I didn't
see this subtlety when I designed Python's package architecture. It's
too late to change (e.g. because of __init__.py). Is it a problem
though? Let's be open-minded about this and think about whether we
want to allow this or not, and why...

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

On Tue, 28 Mar 2000, Fredrik Lundh wrote:
>
> > IMO this subdivision could be discussed and possibly revised.
>
> here's one proposal:
> http://www.pythonware.com/people/fredrik/librarybook-contents.htm

Wow. I don't think i hardly ever use any of the modules in your
"Commonly Used Modules" category. Except traceback, from time to
time, but that's really the only one!

Hmm. I'd arrange things a little differently, though i do like
the category for Data Representation (it should probably go next
to Data Storage though). I would prefer a separate group for
interpreter-and-development-related things. The "File Formats"
group seems weak... to me, its contents would better belong in a
"parsing" or "text processing" classification.

urlparse definitely goes with urllib.

These comments are kind of random, i know... maybe i'll try
putting together another grouping if i have any time.


-- ?!ng