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

[799b3bab-002d-4ce6-a216-b9eed2ae16a4]

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: ```python assignee = None closed_at = None created_at = labels = ['type-feature', 'expert-IO'] title = 'os.pipe() should return a structsequence (or namedtuple.)' updated_at = user = 'https://github.com/jonathanslenders' ``` bugs.python.org fields: ```python activity = actor = 'christian.heimes' assignee = 'none' closed = False closed_date = None closer = None components = ['IO'] creation = 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'] ```

[799b3bab-002d-4ce6-a216-b9eed2ae16a4]

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.

[799b3bab-002d-4ce6-a216-b9eed2ae16a4]

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.