In Python 3.3 the os module gained a few new functions and constants:

Python 3.2.2+ (3.2:58a75eeb5c8e, Sep 29 2011, 02:11:05) 
>>> import os; len(dir(os))
232

Python 3.3.0a0 (default:a50f080c22ca+, Oct 25 2011, 09:56:01) 
>>> import os; len(dir(os))
332

http://docs.python.org/dev/py3k/whatsnew/3.3.html#os lists some of these additions, and they are already grouped (e.g. the sched_* functions, the "at" functions, ...).

Before the os API gets even more bloated, maybe we should group some of these functions in new submodules, like os.sched.*.

I think there is a value to use the very same function names in the posix module as in the posix API. The posix API (and C in general) is also flat, and uses the prefix convention. People who look at the function lists will know to ignore blocks of functions by prefix if they don't need them.

Of the new ones, only the sched_* ones share a common prefix, the *xattr and *at functions share a common suffix, and it's difficult to find them e.g. in dir() (also it's difficult to find other common os functions among all the names).  The fact that the Posix API and C in general use a flat API doesn't seem to me a valid reason to do the same in Python.  Having the same name is a good reason to avoid sched.*, even if I don't think that having sched.* will make finding/recognizing these functions much more difficult.

> I think there is a value to use the very same function names in the 
> posix module as in the posix API.

It would still be the case, except that they'd live in distinct submodule.

> The posix API (and C in general) is also flat, and uses the prefix 
> convention.

That's because C doesn't have namespaces: it's certainly due to this limitation, and not a design choice (and when you think about it, there is a namespace hierarchy, in the header files: <sys/sched.h>, <attr/xatr.h>, etc.).

Some functions would be easy to split off into separate modules conceptually like the sched_* functions and the cap_* functions (see #1615158).

However, certain groups of functions like the *at functions cover a lot of different functionality and don't really belong together.

Perhaps the only grouping that should be done is for functions that start with a common prefix like sched_* since they are basically in a C "namespace".

I would prefer to keep the shared prefix even if we move functions to a new module. Python refers usually to the C documentation for the details of a function. If we rename a function, it becomes more difficult to get the manual of the function.

> I would prefer to keep the shared prefix even if we move functions to a new module. Python refers usually to the C documentation for the details of a function. If we rename a function, it becomes more difficult to get the manual of the function.

Indeed.
But that's what I understood from Ezio's proposal, I don't think he's
suggesting to rename them.

It would be fine for me to rename os.sched_get_priority_max() to os.sched.get_priority_max().
os.sched.sched_get_priority_max() is a bit redundant, and I think it's not to difficult to figure out that os.sched.get_priority_max() corresponds to the posix sched_get_priority_max() function, especially if we add a note to the doc (I'm only -0 about keeping the original name though).
Regarding the other functions that don't share a common prefix it's certainty better to keep the original name.

I don't think submodules are a good idea. In practice, for example, urllib.request.urlopen is more painful to use than good old urllib.urlopen.

If it's a matter of documentation, it can be split in several subchapters.
If it's a matter of organizing source code, it can also be split in several C files: see the _io module for an example.

I agree about urllib.request.urlopen, but os.sched.get_priority_max() is not longer than os.sched_get_priority_max().
I also agree about the documentation -- that should be organized in several sections, regardless of what happens with the module.

> I agree about urllib.request.urlopen, but os.sched.get_priority_max()
> is not longer than os.sched_get_priority_max().

Agreed. There are not many functions which could get this treatment,
though.

FWIW we have 12 functions less since 3.3.0a0 (probably after #14626):

Python 3.3.0a4+ (default:8dd2f5754b2f, Jun 23 2012, 16:50:40) 
>>> import os; len(dir(os))
320

Now it's too late to fix this, so I'm closing it.