[issue43298] Windows build issue
Zack added the comment: Hello. I want to record a game in Windows 7 and I can not install it can you help me -- nosy: +Zack_Barton ___ Python tracker <https://bugs.python.org/issue43298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34721] json module loads function
New submission from zack : the json.loads function think a string variable is a json type, but the variable is "123" -- components: Library (Lib) files: json_test.py messages: 325639 nosy: jaihong priority: normal severity: normal status: open title: json module loads function type: behavior versions: Python 3.5 Added file: https://bugs.python.org/file47813/json_test.py ___ Python tracker <https://bugs.python.org/issue34721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23473] Allow namedtuple to be JSON encoded as dict
New submission from Zack: We used to be able to override _iterencode prior to 2.7 to get our namedtuples to be encoded as dict using json.dump(s) but now we can not. Namedtuples are automatically encoded as list but it would be more logical and convenient to have them encoded as dict -- messages: 236139 nosy: Zack--, ezio.melotti, pitrou, rhettinger priority: normal severity: normal status: open title: Allow namedtuple to be JSON encoded as dict type: behavior 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/issue23473> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23473] Allow namedtuple to be JSON encoded as dict
Zack added the comment: >From memory, something along the lines of from json import JSONEncoder class ExtendedJSONEncoder(JSONEncoder): def _iterencode(self, o, markers=None): if isinstance(o, tuple) and hasattr(obj, '_fields'): gen = self._iterencode_dict(o.__dict__, markers) else: gen = JSONEncoder._iterencode(self, o, markers) for chunk in gen: yield chunk -- ___ Python tracker <http://bugs.python.org/issue23473> ___ ___ 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
[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
[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
[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
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Zack McCauley added the comment: Could this be bumped to a version update to like 3.10.1 or just replace the old package with this updated one? The package name and format now break automations that relied on matching version names in the url. This pattern has worked since 2.7 releases. For example: https://www.python.org/ftp/python/3.10.0/python-3.10.0-macos11.pkg no longer works https://www.python.org/ftp/python/3.9.7/python-3.9.7-macos11.pkg works -- nosy: +WardsParadox status: pending -> open ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Zack McCauley added the comment: Awesome, thanks for the clear update reason. Makes more sense now. I was able to get our software to patch around. An API to get the installer urls would be super helpful. Thanks Ned! On Wed, Nov 3, 2021 at 4:19 PM Ned Deily wrote: > > Ned Deily added the comment: > > After I posted the previous reply, I saw that there have been other users > affected by this, so I have now also made the updated installer available > under the old URL. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue44828> > ___ > -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Zack McCauley added the comment: If you use the older methods to detect OSVersion, Monterey will also identify as 10.16. iirc there’s an environment variable to enable or disable that. On Thu, Nov 4, 2021 at 7:54 AM Marc Culler wrote: > > Marc Culler added the comment: > > According to wikipedia, it was only the Big Sur beta that identified > itself as 10.16. (And I observed this with the beta). But the release > and, I think, the later Big Sur betas stopped doing that. > > But I did eventually find a page showing a tweet that "documents" this > behavior: > > https://eclecticlight.co/2020/07/21/big-sur-is-both-10-16-and-11-0-its-official/ > > I guess obscure tweets have replaced documentation. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue44828> > ___ > -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ 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`
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
[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] 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
[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
[issue31620] asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently
New submission from Zack Elan : Repro: Call asyncio.wait_for(some_queue.get(), some_timeout) repeatedly, with no items in the queue, so that the call times out each time. Expected: No increase in memory while polling an empty queue Actual: The queue holds on to pending "getter" futures until a item passes through the queue, which clears the pending tasks out. Use case: I have producer and consumer asyncio.Tasks, linked by an asyncio.Queue. The producer is idle most of the time and pushes messages very infrequently. The consumer task polls the queue with wait_for and a timeout so that it's able to record "yep, I'm still idle" when the wait_for times out. Attached script has a minimal repro. The producer emits an item every 60 seconds and the consumer polls every second. At the 59th second the _getters member of the queue is holding on to 59 pending futures. By varying the intervals this can leak an arbitrary amount of memory, for example producer emitting an item once a day vs. consumer polling once a second will leak 86,400 futures. >From the attached script: 2017-09-28 10:09:12,699 Queue is idle ... 2017-09-28 10:10:09,784 Queue is idle 2017-09-28 10:10:10,785 Queue is idle 2017-09-28 10:10:11,699 Received 0 from 2017-09-28 10:10:12,700 Queue is idle 2017-09-28 10:10:13,702 Queue is idle Noticed this in 3.6.1, though based on no changes to https://github.com/python/cpython/blob/master/Lib/asyncio/queues.py between the 3.6 branch and master I suspect it also affects 3.6.x and 3.7. -- components: asyncio files: test.py messages: 303264 nosy: yselivanov, zackelan priority: normal severity: normal status: open title: asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently type: resource usage versions: Python 3.6 Added file: https://bugs.python.org/file47174/test.py ___ Python tracker <https://bugs.python.org/issue31620> ___ ___ 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
[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
[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
[issue4709] Mingw-w64 and python on windows x64
Simon Zack added the comment: The problem is still present in python 3.4 with mingw gcc 4.8.2. I was having trouble with compiling radare2's python swig bindings. The solution described here: http://ascend4.org/Setting_up_a_MinGW-w64_build_environment#Setup_Python_for_compilation_of_extensions also fixes my problem when using generated dlls. -- nosy: +simonzack ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ 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
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
[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
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: 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
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
[issue22250] unittest lowercase methods
New submission from Simon Zack: The python unittest module currently uses camel case. This feels rather inconsistent with the rest of the python library, which is in lower case and follows PEP8. Would it be a good idea to add lower-case aliases, and possibly deprecate the camel case methods in the future? -- components: Library (Lib) messages: 225673 nosy: simonzack priority: normal severity: normal status: open title: unittest lowercase methods versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue22250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22452] addTypeEqualityFunc is not used in assertListEqual
New submission from Simon Zack: Functions added by addTypeEqualityFunc is not used for comparing list elements in assertListEqual, and only used in assertEqual. It would be nice to have assertListEqual use functions added by addTypeEqualityFunc for comparisons of list elements. I think this provides more flexibility, and we get nicely formatted error messages for nested list compares for free. -- components: Library (Lib) messages: 227210 nosy: simonzack priority: normal severity: normal status: open title: addTypeEqualityFunc is not used in assertListEqual ___ Python tracker <http://bugs.python.org/issue22452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22452] addTypeEqualityFunc is not used in assertListEqual
Changes by Simon Zack : -- type: -> enhancement ___ Python tracker <http://bugs.python.org/issue22452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7962] Demo/ directory needs to be tested and pruned
Zack Goldstein added the comment:
I've started going through the demos. So far I've gone through cgi and classes.
If this is what you're looking for I'll try and go through the rest in the next
week or so.
Python 3.2a0
/cgi
all work
/classes
Complex.py - fail
1 and Complex(0, 10) ->
Traceback (most recent call last):
File "Complex.py", line 314, in
test()
File "Complex.py", line 310, in test
checkop(*(t+item))
File "Complex.py", line 235, in checkop
ok = abs(result - value) <= fuzz
File "Complex.py", line 184, in __rsub__
return other - self
File "Complex.py", line 180, in __sub__
return Complex(self.re - other.re, self.im - other.im)
TypeError: unsupported operand type(s) for -: 'type' and 'int'
Dates.py - fail
Traceback (most recent call last):
File "Dates.py", line 227, in
test(1850, 2150)
File "Dates.py", line 185, in test
if (not a < b) or a == b or a > b or b != b:
TypeError: unorderable types: Date() < Date()
Dbm.py - fail
{}
key: "myKey"
Traceback (most recent call last):
File "Dbm.py", line 66, in
test()
File "Dbm.py", line 49, in test
if key in d:
File "Dbm.py", line 25, in __getitem__
return eval(self.db[repr(key)])
KeyError: '0'
Range.py - fail
Exception: error in implementation:
correct = range(5, 100, 3)
old-style = [5, 8, 11, 14, 17, 20, 23, 26, 29, 32, 35, 38, 41, 44, 47,
50, 53, 56, 59, 62, 65, 68, 71, 74, 77, 80, 83, 86, 89, 92, 95, 98]
generator = [5, 8, 11, 14, 17, 20, 23, 26, 29, 32, 35, 38, 41, 44, 47,
50, 53, 56, 59, 62, 65, 68, 71, 74, 77, 80, 83, 86, 89, 92, 95, 98]
Rev.py - fail
1 items had failures:
10 of 17 in Rev
***Test Failed*** 10 failures.
Looks like mostly invalid print syntax
Vec.py - pass
bitvec.py - fail
use of __cmp__()
use of __*slice__()
didn't check further
--
nosy: +goldsz
___
Python tracker
<http://bugs.python.org/issue7962>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7962] Demo/ directory needs to be tested and pruned
Zack Goldstein added the comment: I'm assuming tested means "run", and that a good demo is one that "works" for some nominal input. -- ___ Python tracker <http://bugs.python.org/issue7962> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[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
[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
[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
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: > 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
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: 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: ??? 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: 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
[issue22944] Python argument tuple unpacking
New submission from Simon Zack: Python already has tuple unpacking in many places, I wonder if this has been considered for arguments yet, it seems rather convenient and a natural extension to me. Here's what I mean: def func((a, b, c)): print(a, b, c) func((1, 2, 3)) should print "1 2 3" -- components: Interpreter Core messages: 231689 nosy: simonzack priority: normal severity: normal status: open title: Python argument tuple unpacking ___ Python tracker <http://bugs.python.org/issue22944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22961] ctypes.WinError & OSError
Changes by Simon Zack : -- components: +ctypes versions: +Python 3.4 ___ Python tracker <http://bugs.python.org/issue22961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22961] ctypes.WinError & OSError
New submission from Simon Zack: The ctypes.WinError function returns: OSError(None, descr, None, code) However OSError does not appear to allow None as a first argument, and converts it to 22 which is the EINVAL "Invalid Argument" error. This is rather confusing as there was no invalid argument errors in the code. I think the behaviour for one of WinError and OSError should be modified so that the handling of errno is more compatible. -- messages: 231796 nosy: simonzack priority: normal severity: normal status: open title: ctypes.WinError & OSError ___ Python tracker <http://bugs.python.org/issue22961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22961] ctypes.WinError & OSError
Simon Zack added the comment: Ok, my bad, I was creating my own OSErrors so I was just testing it out. I just found the default to be rather confusing as I thought None would not be mapped to anything. -- ___ Python tracker <http://bugs.python.org/issue22961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14965] super() and property inheritance behavior
Simon Zack added the comment: +1 to this feature, this will dramatically simplify property setting code. -- nosy: +simonzack ___ Python tracker <http://bugs.python.org/issue14965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14965] super() and property inheritance behavior
Simon Zack added the comment: For those who want to use this right away, I've added a python implementation of the patch, which passes the unit tests. There's a slight difference in usage, where instead of using super() directly, super_prop(super()) needs to be used, so we can still use super without arguments. -- Added file: http://bugs.python.org/file37546/superprop.py ___ Python tracker <http://bugs.python.org/issue14965> ___ ___ 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
[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
[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
[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
[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
[issue26945] difflib.HtmlDiff().make_file() treat few change as whole line change
New submission from Fairuz Zack: html diff threat 2.011 as whole line added instead of only "11" is changed. example file i want to diff is under bug_report.txt. seems the diff not reasonable for other line in the txt as well. -- components: Library (Lib) files: bug_report.txt messages: 264801 nosy: Fairuz Zack priority: normal severity: normal status: open title: difflib.HtmlDiff().make_file() treat few change as whole line change type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file42709/bug_report.txt ___ Python tracker <http://bugs.python.org/issue26945> ___ ___ 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
[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
