[Python-Dev] deprecate commands.getstatus() (original) (raw)
Michael Foord fuzzyman at voidspace.org.uk
Thu Mar 22 22:34:46 CET 2007
- Previous message: [Python-Dev] deprecate commands.getstatus()
- Next message: [Python-Dev] deprecate commands.getstatus()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Guido van Rossum wrote:
On 3/22/07, Jon Ribbens <jon+python-dev at unequivocal.co.uk> wrote:
""Martin v. Löwis"" <martin at v.loewis.de> wrote:
And do we even need os.fork(), os.exec*(), os.spawn*()?
I don't know about about os.fork; I surely like to have posix.fork. The posix module exposes many OS functions as-is. This has the advantage that their semantics are crystal-clear: they do whatever the system call does (which, ideally, is what POSIX specifies for it). So you can do systems programming in Python, and only need good knowledge of the underlying system calls (i.e. using Python as a better C). I definitely agree. Removing the POSIX system call mappings would make Python less useful and general-purpose. Yes it's nice to have high-level utility functions like those in the subprocess module, but I think it's very important for the low-level functions to be there too when you need them. Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(), that abomination invented by Microsoft? I also hear no opposition against killign os.system() and os.popen()
Except that 'os.system' is really easy to use and I use it rarely enough that I always have to RTFM for subprocess which makes you jump through a few more (albeit simple) hoops.
Additionally, AFAIK subprocess is still broken for py2exe'd applications which is a problem.
All the best,
Michael Foord
- Previous message: [Python-Dev] deprecate commands.getstatus()
- Next message: [Python-Dev] deprecate commands.getstatus()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]