[issue38727] setup.py sdist --format=gztar should use (equivalent of) `gzip -n`

2020-10-22 Thread Zack Weinberg


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()

2020-06-29 Thread Zack Weinberg


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`

2019-11-06 Thread Zack Weinberg


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

2019-11-06 Thread Zack Weinberg


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

2019-11-06 Thread Zack Weinberg


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

2019-10-29 Thread Zack Weinberg


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

2019-07-04 Thread Zack Weinberg


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

2019-06-24 Thread Zack Weinberg


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

2019-04-05 Thread Zack Weinberg


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

2018-07-19 Thread Zack Weinberg


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

2018-07-19 Thread Zack Weinberg

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

2018-01-07 Thread Zack Weinberg

New submission from Zack Weinberg <za...@panix.com>:

[_]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 <rep...@bugs.python.org>
<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

2016-07-12 Thread Zack Weinberg

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 <rep...@bugs.python.org>
<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

2016-07-12 Thread Zack Weinberg

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 <rep...@bugs.python.org>
<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

2016-07-03 Thread Zack Weinberg

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 <rep...@bugs.python.org>
<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

2016-03-29 Thread Zack Weinberg

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 <rep...@bugs.python.org>
<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

2016-03-29 Thread Zack Weinberg

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 <rep...@bugs.python.org>
<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

2015-11-27 Thread Zack Weinberg

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 <rep...@bugs.python.org>
<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

2015-11-27 Thread Zack Weinberg

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 <rep...@bugs.python.org>
<http://bugs.python.org/issue25743>
___
___
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

2015-02-25 Thread Zack Weinberg

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 rep...@bugs.python.org
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

2015-02-24 Thread Zack Weinberg

New submission from Zack Weinberg:

I tripped over a couple of SyntaxError cases where the diagnostic caret is 
misplaced.

 While x:
  File stdin, line 1
While x:
  ^
SyntaxError: invalid syntax

The caret should point to the capital W in 'While'.

 for x in the range(10):
  File stdin, 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 rep...@bugs.python.org
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

2013-04-18 Thread Zack Weinberg

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 rep...@bugs.python.org
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

2013-04-18 Thread Zack Weinberg

Changes by Zack Weinberg za...@panix.com:


Removed file: http://bugs.python.org/file28247/issue16624-v34.diff

___
Python tracker rep...@bugs.python.org
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

2013-04-18 Thread Zack Weinberg

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 rep...@bugs.python.org
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

2013-04-18 Thread Zack Weinberg

Zack Weinberg added the comment:

Note also that allowing `stdin=any filelike` 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 rep...@bugs.python.org
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

2013-04-18 Thread Zack Weinberg

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 rep...@bugs.python.org
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

2013-04-18 Thread Zack Weinberg

Zack Weinberg added the comment:

??? communicate() has always had input= AFAIK.

--

___
Python tracker rep...@bugs.python.org
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

2013-04-18 Thread Zack Weinberg

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 rep...@bugs.python.org
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

2013-01-28 Thread Zack Weinberg

Zack Weinberg added the comment:

Contributor agreement resent by email.  Sorry for the delay.

--

___
Python tracker rep...@bugs.python.org
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

2012-12-07 Thread Zack Weinberg

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 rep...@bugs.python.org
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

2012-12-07 Thread Zack Weinberg

Changes by Zack Weinberg za...@panix.com:


Removed file: 
http://bugs.python.org/file28218/subprocess-check-output-allow-input.diff

___
Python tracker rep...@bugs.python.org
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

2012-12-07 Thread Zack Weinberg

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 rep...@bugs.python.org
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

2012-12-05 Thread Zack Weinberg

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 rep...@bugs.python.org
http://bugs.python.org/issue16624
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com