use of open() results or filehandles

[iwelch]

[novice warning]

per the discussion in https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!searchin/julia-users/reading$20compressed$20csv/julia-users/1C97f24SmKo/2K5c2OdAV94J and #6948

I would suggest that all functions that work with a part of the tuple returned by open() also work with the full tuple. in particular, I would like to see familiar language constructs like the following to "just work":

close(open(...))
fs=open(`cat file.csv`); readcsv(fs); close(fs);

having to index fs is neither intuitive nor necessary.

regards,

/iaw

[elextr]

A better way of doing the open(), do something, close() pattern is to use the do syntax:

open(`gzcat file.gz`, "r") do f
   readcsv(f) # or whatever do something is
end

Then if the do something throws the file still gets closed politely.

[kmsquire]

@elextr, while that construct is useful, it isn't always appilcable, and either way, the fact that open(cmd) returns a tuple seems (to me) to be somewhat inconsistent and confusing.

Ivo, thanks for opening up this issue!

Ref: #6948

[elextr]

@kmsquire wasn't attempting to say don't improve it, just that for the simple use-case there is a safer way of doing the pattern (it hadn't been mentioned on the thread last I looked).

As was hinted in the thread, why not define the stream like reads and writes for the process object, it carries three asyncstreams with it.

[JeffBezanson]

This is a fair point. It would be good for open(cmd) to just return a stream, with a separate function or option for getting the process object, which you don't always need.

[vtjnash]

to just return a stream, with a separate function or option for getting the process object, which you don't always need.

on the contrary, i think it should perhaps return only a process object, but that a process object should inherit from stream and redirect reads and writes to the appropriate stdin/stdout stream.

[nalimilan]

on the contrary, i think it should perhaps return only a process object, but that a process object should inherit from stream and redirect reads and writes to the appropriate stdin/stdout stream.

FWIW, that was how I envisioned it too.

[tkelman]

This was actually not closed by #12739, but it would be closed by #12807, so reopening

[StefanKarpinski]

It seems to be decided that we return a process object that you can read and write to.

[tkelman]

quoting Jameson - "not the top of the priority list," so isn't making 0.6