On 5/30/06, Steven Bethard <
steven.bethard@gmail.com> wrote:
On 5/30/06, Brett Cannon <brett@python.org> wrote:
> So, first step in my mind is settling if we want to add one more depth to
> the stdlib, and if so, how we want to group (not specific groupings, just
> general guidelines).
I think that having a package level that exactly matches the divisions
in the Library Reference (
http://docs.python.org/lib/lib.html
) would
be great.
Currently, that would mean packages for:
3. Python Runtime Services
4. String Services
5. Miscellaneous Services
I
don't think we necessarily want a misc package. Should stuff that
falls into here just be at the root level? Besides, some stuff, such as
heapq, bisect, collections, and the User* modules could got into a data
structure package. I also think that a testing package would make
sense. Could also have a math package.
6. Generic Operating System Services
7. Optional Operating System Services
This includes socket, which I would think
would belong more in a networking-centric package (not including
web-specific stuff). Plus I believe a threading/concurrency package
has been proposed before (which included hiding 'thread' so that people
wouldn't use such low-level stuff).
8. Unix Specific Services
9. The Python Debugger
10. The Python Profiler
Can't the pdb and profiling going into a developer package?
11. Internet Protocols and Support
Should xmlrpclib be in here, or in something more in line with RPC and "concurrency"?
12. Internet Data Handling
Should we merge this with a more generic Internet/Web package? Have a separate email package that includes 'email', smtp, etc?
13. Structured Markup Processing Tools
14. Multimedia Services
15. Cryptographic Services
16. Graphical User Interfaces with Tk
17. Restricted Execution
=) This section's not really valid anymore (although I will be fixing that at some point).
18. Python Language Services
19. Python compiler package
20. SGI IRIX Specific Services
21. SunOS Specific Services
22. MS Windows Specific Services