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.
Makes sense to me.
Currently, that would mean packages for:
- Python Runtime Services
- String Services
- 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
- 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
- The Python Debugger
- 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
- Multimedia Services
- Cryptographic Services
- Graphical User Interfaces with Tk
- Restricted Execution
=) This section's not really valid anymore (although I will be fixing that at some point).
18. Python Language Services
- Python compiler package
- SGI IRIX Specific Services
- SunOS Specific Services
- MS Windows Specific Services
[Steven Bethard]
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.
[Brett Cannon]
Makes sense to me.
[snip]
- 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.
That sounds about reasonable. One possible grouping:
Testing Stuff: * 5.2 doctest -- Test interactive Python examples * 5.3 unittest -- Unit testing framework * 5.4 test -- Regression tests package for Python * 5.5 test.test_support -- Utility functions for tests
Math/Numeric Stuff: * 5.6 decimal -- Decimal floating point arithmetic * 5.7 math -- Mathematical functions * 5.8 cmath -- Mathematical functions for complex numbers * 5.9 random -- Generate pseudo-random numbers * 5.10 whrandom -- Pseudo-random number generator
Data Structures/Collections Stuff: * 5.11 bisect -- Array bisection algorithm * 5.12 collections -- High-performance container datatypes * 5.13 heapq -- Heap queue algorithm * 5.14 array -- Efficient arrays of numeric values * 5.15 sets -- Unordered collections of unique elements * 5.16 itertools -- Functions creating iterators for efficient looping
Stuff I still don't know what to do with: * 5.1 pydoc -- Documentation generator and online help system * 5.17 ConfigParser -- Configuration file parser * 5.18 fileinput -- Iterate over lines from multiple input streams * 5.19 calendar -- General calendar-related functions * 5.20 cmd -- Support for line-oriented command interpreters * 5.21 shlex -- Simple lexical analysis
- Unix Specific Services
- The Python Debugger
- The Python Profiler
Can't the pdb and profiling going into a developer package?
I thought the same thing when I copied the list over the first time.
Steve
On 5/30/06, Steven Bethard steven.bethard@gmail.com wrote:
[Steven Bethard]
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.
[Brett Cannon]
Makes sense to me.
[snip]
- 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.
That sounds about reasonable. One possible grouping:
Testing Stuff: * 5.2 doctest -- Test interactive Python examples * 5.3 unittest -- Unit testing framework * 5.4 test -- Regression tests package for Python * 5.5 test.test_support -- Utility functions for tests
Yep, what I was thinking but possibly renaming 'test' to another naming or putting its functions at the package top level.
Math/Numeric Stuff:
* 5.6 decimal -- Decimal floating point arithmetic * 5.7 math -- Mathematical functions * 5.8 cmath -- Mathematical functions for complex numbers * 5.9 random -- Generate pseudo-random numbers * 5.10 whrandom -- Pseudo-random number generatorData Structures/Collections Stuff: * 5.11 bisect -- Array bisection algorithm * 5.12 collections -- High-performance container datatypes * 5.13 heapq -- Heap queue algorithm * 5.14 array -- Efficient arrays of numeric values * 5.15 sets -- Unordered collections of unique elements * 5.16 itertools -- Functions creating iterators for efficient looping
Stuff I still don't know what to do with: * 5.1 pydoc -- Documentation generator and online help system * 5.17 ConfigParser -- Configuration file parser * 5.18 fileinput -- Iterate over lines from multiple input streams * 5.19 calendar -- General calendar-related functions * 5.20 cmd -- Support for line-oriented command interpreters * 5.21 shlex -- Simple lexical analysis
There are just going to be some things that are odd. Those will probably just have to sit at the top-level with no place to stick them so that they get proper visibility rather than sticking them in misc, forcing people to hunt in there every time they can't find a specific module that does what they want.
- Unix Specific Services
- The Python Debugger
- The Python Profiler
Can't the pdb and profiling going into a developer package?
I thought the same thing when I copied the list over the first time.
Well, there you go then. It's just *that* good of an idea. =)
-Brett
Steve
-- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
On Tue, May 30, 2006 at 03:36:02PM -0600, Steven Bethard wrote:
That sounds about reasonable. One possible grouping:
Note that 2.5's library reference has a different chapter organization from 2.4's. See http://docs.python.org/dev/lib/lib.html.
--amk
On 5/30/06, A.M. Kuchling amk@amk.ca wrote:
On Tue, May 30, 2006 at 03:36:02PM -0600, Steven Bethard wrote:
That sounds about reasonable. One possible grouping:
Note that 2.5's library reference has a different chapter organization from 2.4's. See http://docs.python.org/dev/lib/lib.html.
That's better. Here are my issues with it:
I don't know if I like 'data types' containing stuff like datetime which provide information rather than help deal with data. And other stuff like sched don't seem to really have anything to do with data directly.
I think pdb and profile can be moved to developer tools.
I realize that the misc. category is there just to have a place to stick 'formatter' since it doesn't need its own root-level spot, but I think in terms of a package I don't like the idea of a misc package.
-Brett
A.M. Kuchling wrote:
On Tue, May 30, 2006 at 03:36:02PM -0600, Steven Bethard wrote:
That sounds about reasonable. One possible grouping:
Note that 2.5's library reference has a different chapter organization from 2.4's. See http://docs.python.org/dev/lib/lib.html.
I like it. Its a much cleaner organization than the 2.4 libs. I would like to see it used as a starting point for a reorg of the standard lib namespace.
One question that is raised is whether the categories should map directly to package names in all cases. For example, I can envision a desire that 'sys' would stay a top-level name, rather than 'rt.sys'. Certain modules are so fundamental that they deserve IMHO to live in the root namespace.
-- Talin
On Tue, May 30, 2006 at 11:46:06PM -0700, Talin wrote:
I like it. Its a much cleaner organization than the 2.4 libs. I would like to see it used as a starting point for a reorg of the standard lib namespace.
I'm not convinced that the chapter organization of a book is necessarily the best choice for the actual package layout of the standard library. A grouping that's useful for reference may not be ideal for staying in one's memory.
--amk
-
A.M. Kuchling -
Brett Cannon -
Steven Bethard -
Talin