[Python-Dev] Best Python API for exposing posix_spawn (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Jan 9 03:29:21 EST 2018
- Previous message (by thread): [Python-Dev] Best Python API for exposing posix_spawn
- Next message (by thread): [Python-Dev] Best Python API for exposing posix_spawn
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 9 January 2018 at 17:07, Serhiy Storchaka <storchaka at gmail.com> wrote:
09.01.18 05:31, Nick Coghlan пише:
As with DirEntry, I don't see any obvious value in making the new objects iterable though - we should be able to just use named field access in both the C and Python APIs. Do you suggest to add a class corresponding to posixspawnfileactionst with methods corresponding to posixspawnfile* functions?
Sorry, I should have said explicitly that I liked Greg's suggestion of modeling this as an iterable-of-objects at the Python layer - I was just agreeing with Brett that those should be objects with named attributes, rather than relying on tuples with a specific field order.
That way a passed in list of actions would look something like one of the following:
# Three distinct classes, "FileActions" namespace for disambiguation
[os.FileActions.Close(0),
os.FileActions.Open(1, '/tmp/mylog', os.O_WRONLY, 0o700),
os.FileActions.Dup2(1, 2),
]
# Single class, three distinct class constructor methods
[os.FileAction.close(0),
os.FileAction.open(1, '/tmp/mylog', os.O_WRONLY, 0o700),
os.FileAction.dup2(1, 2),
]
While my initial comment supported having 3 distinct classes, writing it out that way pushes me more towards having a single type where the constructor names match the relevant module function names.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] Best Python API for exposing posix_spawn
- Next message (by thread): [Python-Dev] Best Python API for exposing posix_spawn
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]