[issue24230] tempfile.mkdtemp() doesn't work with bytes paths
Matt Mackall added the comment: Another way of putting it is: os.listdir() -> [,...] os.listdir() -> [,...] is the usual pattern, and tempfile isn't following it. -- nosy: +Matt.Mackall ___ Python tracker <http://bugs.python.org/issue24230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio
Matt Mackall added the comment: We already presize the output dict and have for ages. The question here is what size to use. In the current state, we use twice as much memory and CPU as necessary quite often because we end up spilling and growing... even though we apparently intentionally sized the object to fit. In the sparse case, if we allocate a 1GB dictionary and use two entries in it, we will have consumed 1GB of address space but 1kB of actual memory. -- nosy: +Matt.Mackall ___ Python tracker <http://bugs.python.org/issue23971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21672] Python for Windows 2.7.7: Path Configuration File No Longer Works With UNC Paths
Matt Mackall added the comment: Changeset 26ec62 regressed Mercurial. http://bz.selenic.com/show_bug.cgi?id=4557 Before: >>> ntpath.join(r'\\foo\bar\baz', '') 'foo\\bar\\baz\\' >>> ntpath.join(r'\\foo\bar', '') 'foo\\bar\\' After: >>> ntpath.join(r'\\foo\bar\baz', '') 'foo\\bar\\baz\\' >>> ntpath.join(r'\\foo\bar', '') 'foo\\bar' -- nosy: +Matt.Mackall ___ Python tracker <http://bugs.python.org/issue21672> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14099] ZipFile.open() should not reopen the underlying file
Matt Mackall added the comment: The committed fix breaks Mercurial. http://bz.selenic.com/show_bug.cgi?id=4492 The "underlying file-like object" in our case is a wsgirequest but anything else trying to serve a dynamically-generated zip file on the web will probably die. We wrapped wsgirequest to support tell() many years ago probably copying someone else's hack, and it's worked fine across Python 2.4-2.7, but we fundamentally can't support all the new seek()s that were added here. -- nosy: +Matt.Mackall ___ Python tracker <http://bugs.python.org/issue14099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length
Matt Mackall added the comment: Actually, no, all the size_t types are 64-bit on Windows 64: https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models To confirm this, I found someone nearby with a 64-bit Windows and he had no trouble allocating a 3G string with a = b'a' * 30. -- ___ Python tracker <http://bugs.python.org/issue21199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length
New submission from Matt Mackall: Python's file_read uses an 'l' type to parse its args which results in a 31-bit size limit on reads on 64-bit Windows. It should instead use an ssize_t. Related Mercurial bug: http://bz.selenic.com/show_bug.cgi?id=4215 -- components: IO messages: 215893 nosy: Matt.Mackall, larry, ncoghlan priority: normal severity: normal status: open title: Python on 64-bit Windows uses signed 32-bit type for read length type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by Matt Mackall : -- nosy: -Matt.Mackall ___ Python tracker <http://bugs.python.org/issue1602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Matt Mackall added the comment: The underlying cause of Python's write exceptions with cp65001 is: The ANSI C write() function as implemented by the Windows console returns the number of _characters_ written rather than the number of _bytes_, which Python reasonably interprets as a "short write error". It then consults errno, which gives the effectively random error message seen. This can be bypassed by using os.write(sys.stdout.fileno(), utf8str), which will a) succeed and b) return a count <= len(utf8str). With os.write() and an appropriate font, the Windows console will correctly display a large number of characters. Possible workaround: clear errno before calling write, check for non-zero errno after. The vast majority of (non-Python) applications never check the return value of write, so don't encounter this problem. -- nosy: +Matt.Mackall ___ Python tracker <http://bugs.python.org/issue1602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8688] distutils sdist is too laze w.r.t. recalculating MANIFEST
Matt Mackall added the comment: Ok, we need a change that will work with Python 2.4 through 2.7. -- ___ Python tracker <http://bugs.python.org/issue8688> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8688] distutils sdist is too laze w.r.t. recalculating MANIFEST
Matt Mackall added the comment: This change just wrecked Mercurial's release build process. We've been building Mercurial release tarballs with a Makefile target wrapped around sdist for most of five years, and we've never had or wanted a MANIFEST.in file. We generate an exact, complete, and correct MANIFEST ourselves with: hg manifest > MANIFEST This fix ignores that MANIFEST entirely and attempts to build a new one even though MANIFEST.in doesn't exist. So not only does this change years of documented behavior in a way that very nearly caused us to ship a tarball missing over a thousand files, it means doing what we want to do with sdist (ship precisely the files listed in our version control manifest) is now significantly harder. Unfortunately, this fix is now in a long-lived Python release which we support, which means we're stuck with it. -- nosy: +mpm ___ Python tracker <http://bugs.python.org/issue8688> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
