[issue38727] setup.py sdist --format=gztar should use (equivalent of) `gzip -n`
Zack Weinberg added the comment: The code that needs to be changed is in distutils, setuptools just calls into it. I haven't checked flit but I expect it does the same. -- ___ Python tracker <https://bugs.python.org/issue38727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Zack Weinberg added the comment: I have yet another use case for the function implemented by this patch (i.e. retrieving the cert chain actually sent by the server, regardless of whether that gives a path to a trust anchor). I'm implementing a network forensics tool, and one of the situations it's supposed to detect is when a man-in-the-middle is attempting to substitute its own cert for a site's "legitimate" cert (yes, possibly having suborned a public CA in order to do so). To make all of the planned heuristics for this work correctly, I need to record exactly what came over the wire. If it would be useful for me to dust off the patch and/or implement the _other_ function that people requested (retrieve the chain that OpenSSL concluded was a valid chain to an accepted trust anchor) I can probably scare up time to do so in the next week or two. I imagine it's too late for 3.8 patch releases at this point, but assuming I did this, could it make 3.9? -- nosy: +zwol ___ Python tracker <https://bugs.python.org/issue18233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38727] setup.py sdist --format=gztar should use (equivalent of) `gzip -n`
New submission from Zack Weinberg : Recent versions of the gzip command-line utility have an option `-n` which causes it to omit the FNAME field of the gzip file header, and write out the MTIME field as zero. Both of these properties are desirable when constructing reproducible build artifacts (see https://reproducible-builds.org/ ). An sdist tarball is a build artifact and it should be created as reproducibly as possible. In particular, --format=gztar should behave as-if `gzip -n` were in use. (The stdlib's gzip module can produce output equivalent to what gzip -n does, but this is not currently documented nor is it accessible via `tarfile`. Both of those should be easy fixes. See bug 38725 and bug 38726.) -- components: Distutils messages: 356152 nosy: dstufft, eric.araujo, zwol priority: normal severity: normal status: open title: setup.py sdist --format=gztar should use (equivalent of) `gzip -n` ___ Python tracker <https://bugs.python.org/issue38727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38726] Add equivalent of `gzip -n` (omit timestamp and original file name) to tarfile module's auto-compression support
New submission from Zack Weinberg : Recent versions of the gzip command-line utility have an option `-n` which causes it to omit the FNAME field of the gzip file header, and write out the MTIME field as zero. Both of these properties are desirable when constructing reproducible build artifacts (see https://reproducible-builds.org/ ). Right now, it's possible to get the `gzip` module to do the same thing (it's not documented, but it's possible; see bug 38725) but, as far as I can tell, if you use `tarfile`'s "w:gz" or "w|gz" modes you will always get a timestamp and a filename in the output. Please add `w[:|]gzn`, or something like that, that behaves as-if the output were piped through `gzip -n`. (It might make sense to remove the manual creation of a gzip file header from the tarfile module at the same time; it looks like this code predates the addition of the gzip module to the stdlib.) -- messages: 356151 nosy: zwol priority: normal severity: normal status: open title: Add equivalent of `gzip -n` (omit timestamp and original file name) to tarfile module's auto-compression support ___ Python tracker <https://bugs.python.org/issue38726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38725] Documented equivalent of `gzip -n` (omit timestamp and original file name) in gzip module
New submission from Zack Weinberg :
Recent versions of the gzip command-line utility have an option `-n` which
causes it to omit the FNAME field of the gzip file header, and write out the
MTIME field as zero. Both of these properties are desirable when constructing
reproducible build artifacts (see https://reproducible-builds.org/ ).
Right now, the gzip module lets you set MTIME to zero explicitly by passing
`mtime=0` to the GzipFile constructor, but this is not documented. You can
avoid writing out a filename by opening the output file yourself:
with gzip.GzipFile(fileobj=open("foo.gz", "wb"),
filename='', mtime=0) as ofp:
... write to ofp ...
but that's awkward and, again, not documented. I'd like to be able to write
something like this instead:
with gzip.open("foo.gz", mtime=0, record_filename=False) as ofp:
with this being the documented way to achieve the same effect as `gzip -n`.
--
components: Library (Lib)
messages: 356150
nosy: zwol
priority: normal
severity: normal
status: open
title: Documented equivalent of `gzip -n` (omit timestamp and original file
name) in gzip module
___
Python tracker
<https://bugs.python.org/issue38725>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38632] setup.py sdist should honor SOURCE_DATE_EPOCH
New submission from Zack Weinberg : Reproducibility has so far been concerned primarily with binary packages, but it's also desirable for source tarballs to be reproducible starting from a version-control checkout. This is particularly important for Python, where 'setup.py sdist' can run arbitrary code and generated files (e.g. Cython-generated C) are often included in sdists. As a small step toward this goal, please add support for the SOURCE_DATE_EPOCH environment variable to distutils.command.sdist. The most natural way to implement this would be with an additional user option, perhaps called 'timestamp_limit', which takes a date and time argument. File modification timestamps in the generated tarball or zipfile will be adjusted to be no later than that time. If 'timestamp_limit' is not set, it defaults to the value of os.environ['SOURCE_DATE_EPOCH']. The specification for SOURCE_DATE_EPOCH may be found at https://reproducible-builds.org/specs/source-date-epoch/ . -- components: Distutils messages: 355652 nosy: dstufft, eric.araujo, zwol priority: normal severity: normal status: open title: setup.py sdist should honor SOURCE_DATE_EPOCH ___ Python tracker <https://bugs.python.org/issue38632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18748] io.IOBase destructor silence I/O error on close() by default
Zack Weinberg added the comment: > To be clear: this issue is NOT a bug in Python I don't think that's entirely true. I think CPython needs to be linked against libgcc_s.so, so that this class of application bugs will no longer manifest as interpreter crashes. I filed #37395 for that. -- ___ Python tracker <https://bugs.python.org/issue18748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37395] Core interpreter should be linked with libgcc_s.so on Linux
New submission from Zack Weinberg : There are several existing issues (e.g. #18748 and #35866) where at least part of the problem is that GNU libc tried to dlopen() `libgcc_s.so` at a moment when that's not safe, e.g. during thread or process shutdown. This converts a recoverable error into a deadlock or crash. This is arguably a bug in glibc, but Python can easily work around it by linking the core interpreter (the `python` executable and/or `libpython.so`) with libgcc_s at build time (`-lgcc_s`) on Linux. It will then be loaded already if and when it's needed, and glibc won't try to load it on demand. In order for this to be 100% reliable, it needs to be at least theoretically possible for code within the interpreter to call a function defined in libgcc_s.so. `_Unwind_Backtrace` is probably the most practical option. (See https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/baselib--unwind-backtrace.html .) -- components: Interpreter Core messages: 346468 nosy: zwol priority: normal severity: normal status: open title: Core interpreter should be linked with libgcc_s.so on Linux type: crash ___ Python tracker <https://bugs.python.org/issue37395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18748] libgcc_s.so.1 must be installed for pthread_cancel to work
Zack Weinberg added the comment:
I have observed this problem in a production application using Python 3.5 and
3.6 (system-packaged interpreters from Ubuntu) and I would like to mention that
this is an effective workaround:
```
import ctypes
libgcc_s = ctypes.CDLL("libgcc_s.so.1")
```
provided you do it before creating any threads, and the variable `libgcc_s`
remains live until after all threads are terminated.
--
nosy: +zwol
___
Python tracker
<https://bugs.python.org/issue18748>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34156] Nail down and document the behavior of range expressions in RE character classes
Zack Weinberg added the comment: Also, whether or not the current behavior is the intended behavior, I think programmers would appreciate an explicit statement of whether or not it might change in the future. -- ___ Python tracker <https://bugs.python.org/issue34156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34156] Nail down and document the behavior of range expressions in RE character classes
New submission from Zack Weinberg :
The documentation of the semantics of range expressions in regular expression
character classes is not precise enough. All it says is
Ranges of characters can be indicated by giving two characters and
separating them by a '-', for example [a-z] will match any lowercase ASCII
letter [... more examples, none involving non-ASCII characters]
In testing it seems that the behavior is simply to expand the range to a set of
characters by numeric code point, e.g. '[ᄀ-ፚ]' will match any single character
whose ord() is in between ord('ᄀ') and ord('ፚ') (inclusive). If that is the
intended behavior, I would like the documentation to explicitly say so. If
that is _not_ the intended behavior, I would like to know what the intended
behavior actually is, and for both the code and the documentation to be changed
to reflect the intent.
(I think expansion by numeric code point makes sense and is probably what most
existing programs want, but this is a contended issue in the context of POSIX
regular expressions, e.g. some C libraries try (not always successfully) to
make [0-9] match all of the characters that Python's \d matches, so it's not
"obvious".)
--
assignee: docs@python
components: Documentation, Regular Expressions
messages: 321963
nosy: docs@python, ezio.melotti, mrabarnett, zwol
priority: normal
severity: normal
status: open
title: Nail down and document the behavior of range expressions in RE character
classes
type: behavior
___
Python tracker
<https://bugs.python.org/issue34156>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32511] Thread primitives do not report the OS-level error on failure
New submission from Zack Weinberg : [_]thread.start_new_thread can fail if the underlying OS primitive fails (pthread_create / _beginthreadex), but the exception that is thrown when this happens is a generic RuntimeError (it's _called_ ThreadError in the source code, but it doesn't have its own subtype, so you can't even catch it specifically) and the OS-level error code is lost. It should instead throw (an appropriate subclass of) OSError and capture the error code, like when other OS primitives fail. Reading through the code, it looks like _all_ of the threading code has this problem - throughout [_]threadmodule.c, thread.c, and thread_pthread.h, I see error codes being dropped on the floor or at best reported with perror or dprintf, not properly captured in an OSError. This affects all maintained versions of Python, but sadly I expect it's messy enough to fix that it's only practical to do so on trunk. -- components: Library (Lib) messages: 309623 nosy: zwol priority: normal severity: normal status: open title: Thread primitives do not report the OS-level error on failure type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27496] unicodedata.name() doesn't have names for control characters
Zack Weinberg added the comment: It looks to me as if NameAliases.txt is the better reference for the C0 and C1 controls. It matches the UnicodeData.txt field 10 names for most entries where the field 1 name is "", but it has names for U+0080, U+0081, U+0084, and U+0099, which have no field 10 name. The only catch is that NameAliases may have *several* names for the same character, with the same category tag, e.g. 0009;CHARACTER TABULATION;control 0009;HORIZONTAL TABULATION;control It probably makes sense to consistently use the first listed. -- ___ Python tracker <http://bugs.python.org/issue27496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27496] unicodedata.name() doesn't have names for control characters
New submission from Zack Weinberg:
unicodedata.name() doesn't have name information for the C0 and C1 control
characters. To see this, run
pprint.pprint(["U+{:04X} {}".format(n, unicodedata.name(chr(n), ""))
for n in range(256)])
and you will observe printed for U+ through U+001F and U+007F
through U+009F. These characters do have official Unicode names and they
should be known to name().
I may see if I can come up with a patch for this one, in my copious free time.
--
components: Library (Lib)
messages: 270242
nosy: zwol
priority: normal
severity: normal
status: open
title: unicodedata.name() doesn't have names for control characters
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue27496>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27446] struct: allow per-item byte order
New submission from Zack Weinberg:
Occasionally one encounters binary formats which do not stick to one byte order
throughout. For example, I have a C program that reads and writes arrays of
this struct:
```
struct conn_data
{
uint32_t ipv4_addr; /* read - network byte order - target IPv4 address */
uint16_t tcp_port; /* read - network byte order - target TCP port */
uint16_t errnm; /* write - native byte order - errno code */
uint64_t elapsed; /* write - native byte order - elapsed time in ns */
};
```
On little-endian systems, the first and second fields of this struct will be in
the opposite byte order from the third and fourth.
If the struct module allowed specification of byte order on a per-item basis,
it would make working with structures of this type simpler. Hypothetical
notation:
```
addr, port, errnm, elapsed = struct.unpack("=4s!H=H=Q")
addr = socket.inet_ntoa(addr)
```
instead of what one must do now,
```
addr, port, errnm, elapsed = struct.unpack("=4sHHQ")
addr = socket.inet_ntoa(addr)
port = socket.ntohs(port)
```
To avoid ambiguities and confusion, I would suggest that, if more than one item
has its own byte-order specifier, _all_ items must have byte-order specifiers
(with the possible exception of the 1-byte item types?), and that this is not
allowed in an '@'-mode format.
--
components: Library (Lib)
messages: 269770
nosy: zwol
priority: normal
severity: normal
status: open
title: struct: allow per-item byte order
type: enhancement
___
Python tracker
<http://bugs.python.org/issue27446>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26666] File object hook to modify select(ors) event mask
Zack Weinberg added the comment: > Obvious question: why not working on the asyncio support in this library? The whole point of a transparent SOCKS module is that it provides a function that's a *drop-in replacement* for socket.socket(). An asyncio-based SOCKS module would have a completely different API. -- ___ Python tracker <http://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26666] File object hook to modify select(ors) event mask
New submission from Zack Weinberg: This is pretty esoteric, please bear with me. I'm attempting to enhance a transparent-SOCKS module (https://github.com/Anorov/PySocks) to support non-blocking connect(). This means, you should be able to do this: socks.set_default_proxy(socks.SOCKS5, "localhost") s = socks.socksocket(socket.AF_INET, socket.SOCK_STREAM) s.setblocking(False) err = s.connect_ex(address) if err == errno.EINPROGRESS: select.select([], [s], []) # returns when connection completes Note the position of s in the select() arguments: the documented behavior of non-blocking connect(), at the operating system level, is that the socket will become *writable* when the connection resolves (whether successfully or not). However, in this case, under the hood, the socket is *already connected* -- to the proxy server -- after socksocket() returns. When connect_ex() returns EINPROGRESS, the thing we're really waiting for is a SOCKS-protocol reply message, i.e. the socket needs to become *readable* before the application can continue. An application that used the above code (with a hypothetical version of PySocks where this was supported) would get woken up immediately, since the initial SOCKS client->server message doesn't even come close to filling up the TCP send buffer. There's no practical way to hide this divergence with the current library. What would be needed, I think, is a pair of new special methods on filelikes, which rewrite the set of events to listen for and the set of events to report. Hypothetical, for my use case: def __preselect__(self, events): if not self._connecting: return events return selectors.EVENT_READ def __postselect__(self, events): if not self._connecting: return events return selectors.EVENT_WRITE (I'm using the high-level selectors.EVENT_* constants for illustration. This needs to happen in the low-level select-module methods, because callers can't be expected to use selectors.) There are a bunch of awkward corner cases to worry about with this, and I'm not even sure the feature is worth it, but I thought I'd write up the problem and see what other people think. -- components: IO messages: 262612 nosy: zwol priority: normal severity: normal status: open title: File object hook to modify select(ors) event mask type: enhancement ___ Python tracker <http://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25743] Clarify exactly what \w matches in UNICODE mode
Zack Weinberg added the comment: FWIW, the actual behavior of \w matching "everything in Unicode general categories L* and N*, plus U+005F (underscore)" is consistent across all versions I can conveniently test (2.7, 3.4, 3.5). In 2.7, there are four characters in general category Nl that \w doesn't match, but I believe that is just a bug, not an intentional difference of behavior. -- ___ Python tracker <http://bugs.python.org/issue25743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25743] Clarify exactly what \w matches in UNICODE mode
New submission from Zack Weinberg: The `re` module documentation does not do a good job of explaining exactly what `\w` matches. Quoting https://docs.python.org/3.5/library/re.html : > \w > For Unicode (str) patterns: > Matches Unicode word characters; this includes most characters > that can be part of a word in any language, as well as numbers > and the underscore. Empirically, this appears to mean "everything in Unicode general categories L* and N*, plus U+005F (underscore)". That is a perfectly sensible definition and the documentation should state it in those terms. "Unicode word characters" could mean any number of different things; note for instance that UTS#18 gives a very different definition. (Further reading: https://gist.github.com/zackw/3077f387591376c7bf67 plus links therefrom). -- assignee: docs@python components: Documentation messages: 255463 nosy: docs@python, zwol priority: normal severity: normal status: open title: Clarify exactly what \w matches in UNICODE mode versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue25743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25416] Add encoding aliases from the (HTML5) Encoding Standard
New submission from Zack Weinberg: The codecs registry (as of 3.4) is unaware of two of the canonical encoding names from <https://encoding.spec.whatwg.org/#names-and-labels>: "windows-874" and "x-mac-cyrillic". For interoperability's sake, please make these aliases for "cp874" and "mac_cyrillic" respectively. (For full interop, *every* name and label in that list should be understood by str.encode(), but the canonical names are most useful. Lack of support for iso-8859-i is already reported as https://bugs.python.org/issue18624 . I have not tested the full set of non-canonical labels.) -- messages: 253061 nosy: zwol priority: normal severity: normal status: open title: Add encoding aliases from the (HTML5) Encoding Standard type: enhancement ___ Python tracker <http://bugs.python.org/issue25416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23518] Misplaced diagnostic caret for some SyntaxErrors
Zack Weinberg added the comment: In terms of the formal grammar of the language, you are correct. However, the position of the caret should be chosen based *not* on the formal grammar, but on a heuristic estimation of what the most probable mistake actually is. In both of the cases I listed, the most probable mistake is as I described. Please reconsider. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue23518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23518] Misplaced diagnostic caret for some SyntaxErrors
New submission from Zack Weinberg: I tripped over a couple of SyntaxError cases where the diagnostic caret is misplaced. >>> While x: File "", line 1 While x: ^ SyntaxError: invalid syntax The caret should point to the capital W in 'While'. >>> for x in the range(10): File "", line 1 for x in the range(10): ^ SyntaxError: invalid syntax The caret should point to the 'the'. -- messages: 236560 nosy: zwol priority: normal severity: normal status: open title: Misplaced diagnostic caret for some SyntaxErrors ___ Python tracker <http://bugs.python.org/issue23518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Zack Weinberg added the comment: OK, I get that, but what I'm saying is I think input= is still desirable even if stdin= becomes more powerful. -- ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Zack Weinberg added the comment: ??? communicate() has always had input= AFAIK. -- ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Zack Weinberg added the comment: My position is: * input= should be supported in check_output(), for consistency with communicate(). * I like the idea of making stdin= support file-like objects which don't have a fileno, in both communicate() and everything that calls it, but that does not belong in this issue, I do not have time to code it myself, and, again, it should be *in addition to*, not *instead of*, supporting input= in check_output(). -- ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Zack Weinberg added the comment: Note also that allowing `stdin=` in a clean fashion would require rather more surgery than you suggest, because a filelike can produce an infinite stream of data, and people would expect that to work when the subprocess only reads a finite prefix; making it *actually* work would involve teaching communicate() to take a filelike and copy blocks into the pipe. I have no *objection* to that change but I think it is too much mission creep for this proposal. With the present design, where stdin= has to be something for which fileno() is defined, and input= has to be a string (hence of finite length), no one is going to expect something to work that won't. -- ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Zack Weinberg added the comment: > I think that it will be better not introduce a new argument, but reuse stdin. > Just allow io.BytesIO (or perhaps even any file object) be specified as stdin. If we were designing from scratch I might agree, but we aren't. Principle of least astonishment says that the API here should match `subprocess.communicate`, and that has separate `stdin=FILE` and `input=STRING` arguments. -- ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Changes by Zack Weinberg : Removed file: http://bugs.python.org/file28247/issue16624-v34.diff ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Zack Weinberg added the comment: Here is a new patch vs latest trunk. -- Added file: http://bugs.python.org/file29924/issue16624-v34a.diff ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Zack Weinberg added the comment: Contributor agreement resent by email. Sorry for the delay. -- ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Zack Weinberg added the comment: I don't have the ability to test on Windows, but the construct you are concerned about was copied from other tests in the same file which were not marked as Unix-only. I have faxed in a contributor agreement. -- ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Changes by Zack Weinberg : Removed file: http://bugs.python.org/file28218/subprocess-check-output-allow-input.diff ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
Zack Weinberg added the comment: OK, here is a patch against the latest development version. Now also with tests and documentation updates. -- Added file: http://bugs.python.org/file28247/issue16624-v34.diff ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16624] subprocess.check_output should allow specifying stdin as a string
New submission from Zack Weinberg: subprocess.check_output calls Popen.communicate but does not allow you to specify its argument (i.e. data to send to the child process's stdin). It would be nice if it were enhanced to allow this. Proposed patch attached (to the 2.7 subprocess.py; should apply with trivial changes in 3.x). -- components: Library (Lib) files: subprocess-check-output-allow-input.diff keywords: patch messages: 177014 nosy: zwol priority: normal severity: normal status: open title: subprocess.check_output should allow specifying stdin as a string type: enhancement Added file: http://bugs.python.org/file28218/subprocess-check-output-allow-input.diff ___ Python tracker <http://bugs.python.org/issue16624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
