Mike Meyer wrote:
> Yup, it's probably futile - most people don't care about portability
> or precision, and will use "byte" to mean "8-bit byte".
Nor will this be an issue in Python. Maybe an inset paragraph on some
footnote of a bit of documentation on a wiki page.
> Standards can't get away
IMO os.popen() is wrong here.
On Sat, Apr 12, 2008 at 4:33 PM, Tim Heaney <[EMAIL PROTECTED]> wrote:
> In Python 3.0, it seems that os.popen yields a string, whereas
> subprocess.Popen yields bytes
>
> $ ./python
> Python 3.0a4 (r30a4:62119, Apr 12 2008, 18:15:16)
> [GCC 4.1.3 20070929 (pre
> IMO os.popen() is wrong here.
Should os.popen go away entirely?
Apparently, it does two things:
a) redefine close to block until the child process terminated,
and
b) wrap stdout/stdout with a TextIOWrapper
If there is an actual need to specify an encoding when communicating
with the subprocess
I think the original plan was to reimplement os.popen() on top of
subprocess.py as a convenience (the API is an order of magnitude
simpler). That still sounds good to me.
On Mon, Apr 21, 2008 at 2:44 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > IMO os.popen() is wrong here.
>
> Should os.
