Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixing the Python subprocess interface

amoffat.github.com

Post reply on HN
Print view View original

11–20 of 65 posts

Re: Fixing the Python subprocess interface

#11

Post by dman »

petsos wrote: post #5
dman wrote: post #4

Earlier quoted context omitted.

Anything that encourages a from ... import * usage is evil irrespective of its implementation.

Why?

Off the top of my head a) Nothing prevents the writer of the module you are importing from overriding symbols that you expect b) In many cases increased load times. c) Irrelevant symbols present in scope when debugging d) Makes the order of import statements important, because potentially different modules might be providing the same variable name

Re: Fixing the Python subprocess interface

#12

Post by rytis »

petsos wrote: post #5
dman wrote: post #4

Earlier quoted context omitted.

Anything that encourages a from ... import * usage is evil irrespective of its implementation.

Why?

because this might mess up your script by either overwriting something that's already defined, or you might accidentally overwrite something that is 'hidden' behind the '* '.

somewhat naive example:

    >>> time = 'blah'
    >>> time
    'blah'
    >>> from datetime import *
    >>> time
    
    >>>

Re: Fixing the Python subprocess interface

#13

Post by ulope »

petsos wrote: post #5
dman wrote: post #4

Earlier quoted context omitted.

Anything that encourages a from ... import * usage is evil irrespective of its implementation.

Why?

Because it leads to namespace pollution and hard-to-track-down bugs.

It's especially bad in this case where adding an executable in the system can suddenly shadow any built-in name (e.g. imagine someone adds a "print" or "sys" executable).

Re: Fixing the Python subprocess interface

#14

Post by rplnt »

petsos wrote: post #6

Why not use pipes for piping? e.g. print du("*", "-sb") | sort("-rn")

Would break syntax too much and would make even less sense to python user reading the code. But there is several packages which does this (piping using pipes), maybe you could use that.

Re: Fixing the Python subprocess interface

#15

Post by andylei »

petsos wrote: post #5
dman wrote: post #4

Earlier quoted context omitted.

Anything that encourages a from ... import * usage is evil irrespective of its implementation.

Why?

makes references ambiguous to anyone but the interpreter

let's say you have

from a import foo from b import *

what does 'foo' refer to? 'b' could contain 'foo', which would overwrite your previous reference to 'a.foo'. its hard to figure out what 'foo' now refers to from inspecting the code. its better to be explicit:

from a import foo from b import bar, baz

Re: Fixing the Python subprocess interface

#16

Post by tantalor »

VMG wrote: post #10
petsos wrote: post #5

Earlier quoted context omitted.

Why?

pollution of the global name space

Irrelevant for shell-style scripts because they are entry points, not included from other modules.

--And its not a "global" name space, its just the namespace of your script.--

Re: Fixing the Python subprocess interface

#17

Post by tswicegood »

FWIW, re-replaying the stack trace to figure out what was imported and re-implementing it is a horrible idea. There are much better ways to do this type of import voodoo, specifically the import hooks that Python ships with. Here's an example of their use inside a small side project of mine: https://github.com/tswicegood/maxixe/blob/master/maxixe/__in...

All that said, this is horribly un-Pythonic. A much better route to so is something like envoy[1] which simply wraps `subprocess` in a sane API.

[1]: https://github.com/kennethreitz/envoy

Post reply on HN