classification
Title: Group some os functions in submodules
Type: enhancement Stage: resolved
Components: Extension Modules Versions: Python 3.3
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, benjamin.peterson, eric.araujo, ezio.melotti, georg.brandl, loewis, neologix, petri.lehtinen, pitrou, rhettinger, rosslagerwall, vstinner
Priority: normal Keywords:

Created on 2011-10-25 12:06 by ezio.melotti, last changed 2012-09-26 14:58 by ezio.melotti. This issue is now closed.

Messages (13)
msg146363 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-10-25 12:06
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.*.
msg146386 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-10-25 18:20
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.
msg146390 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-10-25 18:40
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.
msg146392 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-10-25 18:45
> 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.).
msg146393 - (view) Author: Ross Lagerwall (rosslagerwall) (Python committer) Date: 2011-10-25 19:04
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".
msg146399 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-10-25 20:25
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.
msg146417 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-10-26 06:29
> 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.
msg146419 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-10-26 06:41
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.
msg146509 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-10-27 17:53
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.
msg146512 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-10-27 17:59
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.
msg146513 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-10-27 18:09
> 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.
msg163645 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2012-06-23 16:59
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
msg171343 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2012-09-26 14:58
Now it's too late to fix this, so I'm closing it.
History
Date User Action Args
2012-09-26 14:58:15ezio.melottisetstatus: open -> closed
resolution: out of date
messages: + msg171343

stage: needs patch -> resolved
2012-06-23 17:22:53Arfreversetnosy: + Arfrever
2012-06-23 16:59:12ezio.melottisetmessages: + msg163645
2011-10-27 18:09:06pitrousetmessages: + msg146513
2011-10-27 17:59:23ezio.melottisetmessages: + msg146512
2011-10-27 17:53:30pitrousetmessages: + msg146509
2011-10-27 15:54:14eric.araujosetnosy: + eric.araujo
2011-10-26 06:41:47ezio.melottisetmessages: + msg146419
2011-10-26 06:29:59neologixsetmessages: + msg146417
2011-10-25 20:25:24vstinnersetmessages: + msg146399
2011-10-25 19:04:31rosslagerwallsetmessages: + msg146393
2011-10-25 18:45:10neologixsetnosy: + neologix
messages: + msg146392
2011-10-25 18:40:13ezio.melottisetmessages: + msg146390
2011-10-25 18:20:35loewissetmessages: + msg146386
2011-10-25 12:44:12rosslagerwallsetnosy: + rosslagerwall
2011-10-25 12:29:36petri.lehtinensetnosy: + petri.lehtinen
2011-10-25 12:24:38vstinnersetnosy: + vstinner
2011-10-25 12:06:16ezio.melotticreate