[Python] Duda con el modulo subprocess..

[Avispon99]

Hola

Tengo una duda desde hace tiempo, aun no me queda muy clara la diferencia entre los metodos subprocess.popen , subprocess.call y subprocess.check_output  ..

Digamos que lo que tengo entendido es que popen no oculta el proceso a diferencia de call y check_output, pero por lo demas no me queda muy clara la diferencia ya que siempre que los he usado me dan el mismo resultado..

Según lo que he leido en la documentación en ingles dice que la diferencia esta en algo del retorno del valor o del codigo o algo asi, pero ya saben que en ingles las cosas no son tan claras a menos de que domines  el ingles a la perfección..

Es por eso que quisiera saber si alguien aquí entiende claramente cual la diferencia exacta entre los tres métodos, y también quisiera saber si subprocess remplaza completamente al modulo os o si aun hay cosas que solo se puedan hacer con el modulo os?  ..  esa es mi duda.

[engel lex]

codigo fuente (no es malo leerlo de vez en cuando )

basicamente es popen, pero espera que que finalice... así que esto frenará tu codigo (se le llama "funciones bloqueantes o "blocking functions", popen no es bloqueante)

este es subprocess.call

Código (python) [Seleccionar] Expandir


def call(*popenargs, timeout=None, **kwargs):
    """Run command with arguments.  Wait for command to complete or
    timeout, then return the returncode attribute.

    The arguments are the same as for the Popen constructor.  Example:

    retcode = call(["ls", "-l"])
    """
    with Popen(*popenargs, **kwargs) as p:
        try:
            return p.wait(timeout=timeout)
        except:
            p.kill()
            p.wait()
            raise

Código (python) [Seleccionar] Expandir

def check_output(*popenargs, timeout=None, **kwargs):
    r"""Run command with arguments and return its output as a byte string.

+
−    If the exit code was non-zero it raises a CalledProcessError.  The
    CalledProcessError object will have the return code in the returncode
    attribute and output in the output attribute.

    The arguments are the same as for the Popen constructor.  Example:

    >>> check_output(["ls", "-l", "/dev/null"])
    b'crw-rw-rw- 1 root root 1, 3 Oct 18  2007 /dev/null\n'

    The stdout argument is not allowed as it is used internally.
    To capture standard error in the result, use stderr=STDOUT.

    >>> check_output(["/bin/sh", "-c",
    ...               "ls -l non_existent_file ; exit 0"],
    ...              stderr=STDOUT)
    b'ls: non_existent_file: No such file or directory\n'
    """
    if 'stdout' in kwargs:
        raise ValueError('stdout argument not allowed, it will be overridden.')
    with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
        try:
            output, unused_err = process.communicate(timeout=timeout)
        except TimeoutExpired:
            process.kill()
            output, unused_err = process.communicate()
            raise TimeoutExpired(process.args, timeout, output=output)
        except:
            process.kill()
            process.wait()
            raise
        retcode = process.poll()
        if retcode:
            raise CalledProcessError(retcode, process.args, output=output)
    return output

[Avispon99]

codigo fuente (no es malo leerlo de vez en cuando )

En realidad mi duda no esta relacionada con un problema que tenga en este momento en especifico, por eso no comparti codigo fuente. Simplemente es una duda que me atormenta desde hace algun tiempo.

Y respecto a tu respuesta me compartiste directamente los métodos de la librería..

Si en este momento me lió con la simple documentación imagínate como me va intentando entenderlo directamente de la librería...

Usted es diabolico  jajajaja

[Eleкtro]

Tengo una duda desde hace tiempo, aun no me queda muy clara la diferencia entre los metodos subprocess.popen , subprocess.call y subprocess.check_output  ..

¿para qué está la documentación oficial si no es para aclarar este tipo de dudas básicas?. Tan solo tienes que leer las descripciones principales (y ya si quieres, la de los parámetros de cada función)...

subprocess.popen
Execute a child program in a new process

subprocess.call
Run the command described by args. Wait for command to complete, then return the returncode attribute.

subprocess.check_output
Run command with arguments and return its output as a byte string.

Como puedes ver por ti mismo con solo leer, de por si son tres miembros con propósitos/valores de retorno bien diferenciados.

La diferencia principal está en los valores de retorno, popen devuelve una instancia de la clase popen (la cual representa el proceso en ejecución), call devuelve el código de salida del proceso, y check_output el bufer de la salida estándar (o Standard output o stdout) del proceso. Básicamente estas dos últimas funciones son wrappers de las funciones de la clase popen, son funciones de conveniencia por así decirlo, del mismo modo que si me da la gana puedo implementar una clase para representar un libro, y una función de conveniencia que utilice esa clase para devolver solamente el título del libro o la cantidad de páginas total, por ejemplo.

No te fijes mucho en si la diferencia consiste en que si "X" es asincrónico e "Y" es sincrónico, por que esa no es la diferencia principal por así decirlo ...como ya expliqué más arriba. Ten en cuenta que una instancia de la clase popen provee el miembro popen.wait() ( https://docs.python.org/2.4/lib/node239.html ), el cual también es una llamada bloqueante (o blocking call) cuyo propósito es esperar la terminación del proceso y devolver el código de salida, como por ejemplo harías con una llamada a subprocess.call() para obtener lo mismo y "del mismo modo", puesto que lo que hace es llamar a popen internamente...

ya saben que en ingles las cosas no son tan claras a menos de que domines  el ingles a la perfección..

En mi opinión es más bien al contrario: en un idioma traducido (ej. Español) las cosas no son tan claras, a menos que entiendas las burdas y estúpidas traducciones que hace la gente y algunos de aquellos que se hacen llamar profesores (ej. llamarle "arreglo" a un Array), el aprendizaje en general será muy mediocre, por que la mayoría de términos cambian de un idioma a otro (como es evidente) y el desconocimiento de la terminología en el idioma "nativo" (Inglés) será un gran obstáculo en el futuro, por que en el futuro vas a querer (iniciativa) o a tener (obligación) que programar en Inglés sí o sí, al menos si realmente te tomas la programación en serio lo más probable es que sea así, y entonces te darás cuenta de que el aprendizaje en Español fue como una pérdida de tiempo, algo que realmente carece de valor para el aprendizaje, o algo parecido...

Y no es necesario "dominar el Inglés a la perfección", todo el mundo sabe un mínimo de Ingles hoy en día, un mínimo de Inglés a nivel usuario para poder leer y entender frases, terminología de programación, etc... tan solo se necesita eso para empezar a leer libros o documentación oficial; todo está mucho mejor explicado en Inglés que en cualquier otro idioma, o al menos mucho mejor explicado que en el Español. Yo cada vez que leo un artículo de la MSDN o Microsoft Docs en Español (la página donde se hospeda la documentación oficial de .NET Framework / C# ) me entran arcadas por como cambian todas las terminologías hasta un punto en que te cuesta enterarte (por falta de costumbre) con traducciones que parecen querer cambiarle el sentido a los conceptos de la programación... todo bastante confuso, cuando se lee en Inglés se entiende todo a la perfección.

Es indispensable saber ese mínimo de Inglés, sobre todo para depurar tus programas/scripts, de lo contrario ten mucha fe cuando sientas la inexorable necesidad de buscar información y/o solución a un error del compilador en Google, en Español... es de inútiles buscar info. en Español a ese tipo de problema (y a cualquier otro relacioando con la informática y la programación), eso es lo que pienso personálmente. Lo digo humíldemente, yo no me considero un gurú del Inglés, ni mucho menos, solo intento ser realista... el mundo de la programación se mueve, crece y se extiende en un solo idioma: Inglés, en ese sentido todos los demás idiomas son una miserable minoria que no sirven para nada aprender...

Saludos!

[Avispon99]

En mi opinión es más bien al contrario: en un idioma traducido (ej. Español) las cosas no son tan claras, a menos que entiendas las burdas y estúpidas traducciones que hace la gente y algunos de aquellos que se hacen llamar profesores (ej. llamarle "arreglo" a un Array), el aprendizaje en general será muy mediocre, por que la mayoría de términos cambian de un idioma a otro (como es evidente) y el desconocimiento de la terminología en el idioma "nativo" (Inglés) será un gran obstáculo en el futuro, por que en el futuro vas a querer (iniciativa) o a tener (obligación) que programar en Inglés sí o sí, al menos si realmente te tomas la programación en serio lo más probable es que sea así, y entonces te darás cuenta de que el aprendizaje en Español fue como una pérdida de tiempo, algo que realmente carece de valor para el aprendizaje, o algo parecido...

Y no es necesario "dominar el Inglés a la perfección", todo el mundo sabe un mínimo de Ingles hoy en día, un mínimo de Inglés a nivel usuario para poder leer y entender frases, terminología de programación, etc... tan solo se necesita eso para empezar a leer libros o documentación oficial; todo está mucho mejor explicado en Inglés que en cualquier otro idioma, o al menos mucho mejor explicado que en el Español. Yo cada vez que leo un artículo de la MSDN o Microsoft Docs en Español (la página donde se hospeda la documentación oficial de .NET Framework / C# ) me entran arcadas por como cambian todas las terminologías hasta un punto en que te cuesta enterarte (por falta de costumbre) con traducciones que parecen querer cambiarle el sentido a los conceptos de la programación... todo bastante confuso, cuando se lee en Inglés se entiende todo a la perfección.

Es indispensable saber ese mínimo de Inglés, sobre todo para depurar tus programas/scripts, de lo contrario ten mucha fe cuando sientas la inexorable necesidad de buscar información y/o solución a un error del compilador en Google, en Español... es de inútiles buscar info. en Español a ese tipo de problema (y a cualquier otro relacioando con la informática y la programación), eso es lo que pienso personálmente. Lo digo humíldemente, yo no me considero un gurú del Inglés, ni mucho menos, solo intento ser realista... el mundo de la programación se mueve, crece y se extiende en un solo idioma: Inglés, en ese sentido todos los demás idiomas son una miserable minoria que no sirven para nada aprender...

Saludos!

Eso ya lo se, por eso vine aquí...  Por que, por un lado esta la realidad de que la documentación en español es basura y mucho peor aun si usas la traducción de google, y por el otro lado si una persona tiene un nivel de ingles mediocre entonces su interpretación de la documentación en ingles logicamente también sera mediocre (tan mediocre como la traducción misma de google de hecho)..

Así que, si yo quiero saber algo ahora mismo (por que soy muy impaciente y no quiero esperar a saber mas ingles para tener la respuesta exacta), simplemente acudo a un foro como una sanguijuela y le chupo el conocimiento a otras personas que ya tengan las ideas claras y la experiencia necesaria, como tu por ejemplo.. sin lugar a duda el metodo mas eficaz.

La vieja y confiable. :v

Respecto a tu respuesta sobre las diferencias de los retornos, muchas gracias, me has ayudado, eso era justo lo que necesitaba saber.

Ahora iré a Stack Overflow a buscar otra victima a la cual chuparle sus conocimientos.
!Mua ha ha ha ha!

Saludos.  

[Eleкtro]

Ahora iré a Stack Overflow a buscar otra victima a la cual chuparle sus conocimientos.
!Mua ha ha ha ha!

No se puede decir que hagas mal, aunque desde luego ese no sea el mejor plan de estudio por así decirlo, pero como ya te habrás dado cuenta SO está lleno de auténticos gurús de la programación (EDITO: y en absoluto lo digo por mi, claro está, que no se me malinterprete, creo que tengo publicadas más preguntas que respuestas, y ninguna es sobre Python), solo con que elijas a un par de "candidatos" para analizar su perfil de usuario y ponerte a leer respuestas suyas de forma aleatoria, se aprenden cosas sobre el lenguaje que te interese, consejos y "trucos" que no resultarían tan evidentes por otros medios de aprendizaje...

Saludos.

[Avispon99]

No se puede decir que hagas mal, aunque desde luego ese no sea el mejor plan de estudio por así decirlo, pero como ya te habrás dado cuenta SO está lleno de auténticos gurús de la programación (EDITO: y en absoluto lo digo por mi, claro está, que no se me malinterprete, creo que tengo publicadas más preguntas que respuestas, y ninguna es sobre Python), solo con que elijas a un par de "candidatos" para analizar su perfil de usuario y ponerte a leer respuestas suyas de forma aleatoria, se aprenden cosas sobre el lenguaje que te interese, consejos y "trucos" que no resultarían tan evidentes por otros medios de aprendizaje...

Saludos.

En el tiempo que llevo interesado en esto de la programación, no he conocido al primer puritano de la documentación, tal vez solo el primero en usar un determinado lenguaje lo fue.. pero una vez un lenguaje ya tiene un cierto recorrido lo mas adecuado es utilizar los foros o el contacto con otros usuarios del lenguaje antes que ir corriendo a por la documentación, por que ni la mas perfecta documentación se compara con la experiencia ya vivida de otros, por eso nacieron lugares como estos donde la gente pregunta, por eso existe Stack Overflow en ingles a pesar de que la documentación también este en ingles, por que hay cosas de las que solo te enteras una vez te pones a picar código, pero picarlo todo es humanamente imposible..

Así que es mucho mejor intercambiar experiencias antes que leer un simple texto "correctamente escrito", especialmente en este mundo del software en donde todo tiene que ocurrir rápido y sin tregua o de lo contrario ya te dicen que no sirves para el trabajo.. la documentación es una guía útil, pero de la guía a la practica hay un buen trecho...

Salu2.