os.pipe() should return a structsequence (or namedtuple.)

[JonathanSlenders]

BPO	24536
Nosy	@tiran, @Rosuav, @vadmium, @1st1, @jonathanslenders
Files	ospipe.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2015-06-30.07:19:17.144>
labels = ['type-feature', 'expert-IO']
title = 'os.pipe() should return a structsequence (or namedtuple.)'
updated_at = <Date 2016-09-19.06:30:21.855>
user = 'https://github.com/jonathanslenders'

bugs.python.org fields:

activity = <Date 2016-09-19.06:30:21.855>
actor = 'christian.heimes'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['IO']
creation = <Date 2015-06-30.07:19:17.144>
creator = 'jonathan.slenders'
dependencies = []
files = ['39839']
hgrepos = []
issue_num = 24536
keywords = ['patch']
message_count = 11.0
messages = ['245980', '245981', '245991', '245992', '246011', '246023', '246026', '246027', '246028', '246885', '276948']
nosy_count = 5.0
nosy_names = ['christian.heimes', 'Rosuav', 'martin.panter', 'yselivanov', 'jonathan.slenders']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue24536'
versions = ['Python 3.6']

[JonathanSlenders]

As discussed on python-ideas, os.pipe should return a structsequence instead of a plain tuple.

To be decided is the naming for the read and write end.
Personally, I'm in favour of using readfd/writefd.

our_pipe = pipe()
os.write(our_pipe.writefd, b'data')
os.read(our_pipe.readfd, 1024)

[Rosuav]

Another good option is read/write without the 'fd' suffix. Either works, I'd prefer the shorter one but by a small margin.

[ethanfurman]

'read'/'write' is sufficient.

+1 for the proposal.

[JonathanSlenders]

Niki Spahiev made a valid argument saying that the following code is common:

if not hasattr(src, 'read'): src = open(src)

This will break if we name it 'read'/'write' like the methods of a file object.

[1st1]

+1 for readfd/writefd. I think 'fd' suffix is necessary to make it explicit that those aren't file objects.

[1st1]

Here's a patch, please review.

[ethanfurman]

Nowhere else in the stdlib is 'readfd' defined, and 'writefd' is only used once in a test.

I think tacking on the 'fd' is both too low level as well as misleading since these are not file descriptors.

If there is no agreement on read/write (understandable since those are usually methods), then perhaps input/output?

[ethanfurman]

Okay, scratch the "not file descriptors" part of my comment, but the rest still stands.

[ethanfurman]

As for Niki's example:
---------------------

--> src = os.pipe()
--> src
(3, 4)
--> if not hasattr(src, 'read'): src = open(src)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: invalid file: (3, 4)

---

This fails now. If they pass a pipe tuple into the new code they'll just get a different error somewhere else, which seems fine to me.

[vadmium]

The original Python-ideas thread: <https://www.marc.info/?t=143558954500004\>

If you want shorter field names, how about just r and w (as they are currently documented)?

os.write(our_pipe.w, b"data")
os.read(our_pipe.r, 1024)

“Input” and “output” would also work for me (though I am also happy with read, read_fd, etc). However it does seem a bit novel; in my experience people tend to say pipes have read and write ends, not inputs and outputs.

os.write(our_pipe.input, b"data")
os.read(our_pipe.output, 1024)

[tiran]

In C programming common names for both ends are reader and writer. We could go with the pipes analogy and call the ends inlet and outlet.