Re: [Python-Dev] A question about the subprocess implementation
On 2012-01-08 10:48 , Vinay Sajip wrote: Terry Reedy udel.edu> writes: The behavior matches the doc: Popen.stdin If the stdin argument was PIPE, this attribute is a file object that provides input to the child process. Otherwise, it is None. Right, but it's not very helpful, nor especially intuitive. Why does it have to be None in the case where you pass in a file object? Is there some benefit to be gained by doing this? Does something bad happen if you store that file object in proc.stdin / proc.stdout / proc.stderr? proc.stdin, proc.stdout, and proc.stderr aren't meant to be a reference to the file that got connected to the subprocess' stdin/stdout/stderr. They are meant to be a reference to the OTHER END of the pipe that got connected. When you pass in a normal file object there is no such thing as the OTHER END of that file. The value None reflects this fact, and should continue to do so. -Phil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add os.path.resolve to simplify the use of os.readlink
On 2012-06-21 06:23, Armin Ronacher wrote: Due to an user error on my part I was not using os.readlink correctly. Since links can be relative to their location I think it would make sense to provide an os.path.resolve helper that automatically returns the absolute path: def resolve(filename): try: target = os.readlink(filename) except OSError as e: if e.errno == errno.EINVAL: return abspath(filename) raise return normpath(join(dirname(filename), target)) The above implementation also does not fail if an entity exists but is not a link and just returns the absolute path of the given filename in that case. It's expensive (not to mention racy) to do this correctly, when any component of the pathname (not just the component after the last slash) might be a symlink. For example: mkdir -p foo1/foo2 touch bar ln -s ../../bar foo1/foo2/symlink ln -s foo1/foo2 foo Now try to resolve "foo/symlink" using your function. It produces "../bar", which doesn't exist. Why not just work with the pathname you're given and let the kernel worry about resolving it? -Phil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
