[issue39840] FileNotFoundError et al show b-prefix on filepaths if passed as bytes
New submission from Augie Fackler : I'm not really sure if this is a bug per se, so please feel encouraged to close as WAI if you like, but: >>> open(b'foo', 'rb') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: b'foo' Seems a little weird to me (and it shows up in the UI layer of hg), because the path-as-bytes seems like it shouldn't show up in the human-readable version of the exception (I think I would have expected the fsdecode() of the bytes, for consistency?) But that's up to you. If the presentation format of this feels right to Python that's no big deal. -- messages: 363297 nosy: durin42 priority: normal severity: normal status: open title: FileNotFoundError et al show b-prefix on filepaths if passed as bytes versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue39840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27664] Allow specifying prefix for thread name in concurrent.futures.ThreadPoolExecutor
New submission from Augie Fackler: This is mostly useful for when you've got a large number of threads and want to try and identify what threadpool is going nuts. -- components: Library (Lib) files: cpython.patch keywords: patch messages: 271790 nosy: durin42 priority: normal severity: normal status: open title: Allow specifying prefix for thread name in concurrent.futures.ThreadPoolExecutor type: enhancement Added file: http://bugs.python.org/file43967/cpython.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24230] tempfile.mkdtemp() doesn't work with bytes paths
Augie Fackler added the comment: I just removed my hack that gave us unicode to hand to mkdtemp() and everything still passes with your new commit. Thanks much for the quick response! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24230 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24230] tempfile.mkdtemp() doesn't work with bytes paths
Augie Fackler added the comment: I'll build a patched Python3.5 tomorrow (I'm on the road today) and let you know if this does everything we need. I'd be shocked if it wasn't plenty. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24230 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24230] tempfile.mkdtemp() doesn't work with bytes paths
Augie Fackler added the comment: In any way Mercurial people need their own wrapper if they want to support Python 3.5. We need format operations on bytes objects, so we have no plans to support Python3 for any version before 3.5. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24230 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24230] tempfile.mkdtemp() doesn't work with bytes paths
New submission from Augie Fackler: Many things in the OS module work with bytestrings for paths in Python 3, but tempfile isn't so happy. It'd be very useful to be able to have the same bytes-in-bytes-out behavior in tempfile as for the os.path.* methods. This is something we're working around in hg, but I figured I'd file a bug anyway in case we can improve the situation. -- components: Library (Lib) messages: 243498 nosy: durin42 priority: normal severity: normal status: open title: tempfile.mkdtemp() doesn't work with bytes paths versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24230 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24230] tempfile.mkdtemp() doesn't work with bytes paths
Augie Fackler added the comment:
Today we're doing something like this:
tmpdir = tempfile.mkdtemp('', 'hgtests.', d and
d.decode('utf-8')).encode('utf-8')
but would rather have
tmpdir = tempfile.mkdtemp(b'', b'hgtests.', d)
# and now tmpdir is a bytestring containing the path to the tmpdir
basically, we want to maintain our pedantry around paths being sequences of
bytes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24230
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Augie Fackler added the comment: Changes to 3.4 aren't going to help Mercurial. Given that bytes formatting is new in 3.5, I won't be attempting a port that supports a version of Python 3 any older than 3.5. At this point, just a difflib.diff_bytes method in 3.5 would be sufficient to satisfy my needs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Augie Fackler added the comment: (For values of our == Mercurial.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Augie Fackler added the comment: Friendly ping. With bytes formatting in Python 3.5a3, this is now the biggest pain port for getting our test runner working cleanly on Python 3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21590] Systemtap and DTrace support
Changes by Augie Fackler li...@durin42.com: -- nosy: +durin42 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21590 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Changes by Augie Fackler li...@durin42.com: -- nosy: +durin42 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13405 ___ ___ 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
Changes by Augie Fackler li...@durin42.com: -- nosy: +durin42 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22165] Empty response from http.server when directory listing contains invalid unicode
Augie Fackler added the comment: Why not treat the filename as opaque bytes, and let the client fetch it anyway? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17621] Create a lazy import loader mixin
Changes by Augie Fackler li...@durin42.com: -- nosy: +durin42 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17621 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19510] lib2to3.fixes.fix_import gets confused if implicit relative imports and absolute imports are on the same line
New submission from Augie Fackler: While tinkering (again) with Mercurial Python 3 messes, I ran across this gem: import error, osutil, encoding, collections (http://selenic.com/hg/file/e1317d3e59e1/mercurial/util.py#l17) That import statement contains 3 relative imports (that is, mercurial.error, mercurial.osutil, and mercurial.encoding), and one standard library import (collections). Because of the standard lib import on that line, lib2to3 doesn't rewrite any of the imports. If I instead move collections to its own line, then the first three imports get correctly rewritten to the from . import error form. I've got Python 3.3.2 locally, and the lib2to3 is the one from that stdlib. -- components: 2to3 (2.x to 3.x conversion tool) messages: 202248 nosy: durin42, twouters priority: normal severity: normal status: open title: lib2to3.fixes.fix_import gets confused if implicit relative imports and absolute imports are on the same line versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19510 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Augie Fackler added the comment: Is there any chance we could just have it work for bytes, ints, and floats? That'd solve the immediate need, and it'd be obviously correct how to have those behave. Punting this to 3.5 basically means we'll have to either wait for 3.5, or do something awful like use cffi to grab sprintf to port Mercurial. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Augie Fackler added the comment: On Tue, Oct 8, 2013 at 11:08 AM, Antoine Pitrou rep...@bugs.python.orgwrote: Is there any chance we could just have it work for bytes, ints, and floats? That'd solve the immediate need, and it'd be obviously correct how to have those behave. You mean %s and %d? Basically, yes. Punting this to 3.5 basically means we'll have to either wait for 3.5, or do something awful like use cffi to grab sprintf to port Mercurial. Or write a pure Python implementation. Hah. Probably too slow for anything beyond a proof of concept, no? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Augie Fackler added the comment:
On Tue, Oct 8, 2013 at 5:11 PM, Antoine Pitrou rep...@bugs.python.orgwrote:
Antoine Pitrou added the comment:
Punting this to 3.5 basically means we'll have to either wait for
3.5, or do something awful like use cffi to grab sprintf to port
Mercurial.
Or write a pure Python implementation.
Hah. Probably too slow for anything beyond a proof of concept, no?
If it's only for the Mercurial test suite, that shouldn't be a problem?
It's not just the testsuite though: we do this _all over_ hg itself. For
example, status needs to do something like this:
sys.stdout.write('%(state)s %(path)s\n' % {'state': 'M', 'path':
'some/filesystem/path'})
except we don't know the encoding of the filesystem path (Hi unix!) so we
have to treat the whole thing as opaque bytes. It's even more fun for
'log', becase then it's got localized strings in it as well.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3982
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Augie Fackler added the comment:
On Oct 8, 2013, at 5:24 PM, STINNER Victor rep...@bugs.python.org wrote:
STINNER Victor added the comment:
2013/10/8 Augie Fackler rep...@bugs.python.org:
sys.stdout.write('%(state)s %(path)s\n' % {'state': 'M', 'path':
'some/filesystem/path'})
except we don't know the encoding of the filesystem path (Hi unix!) so we
have to treat the whole thing as opaque bytes.
You are doing it wrong. In Python 3, you should store filenames as
Unicode (str type). If Python fails to decode a filename, undecodable
bytes are stored as surrogate characters (see the PEP 383).
No, I'm not. In Mercurial, all end-user data is OPAQUE BYTES, and must remain
that way. We're not able to change either our on-disk data format OR our stdout
format, even to support a newer version of Python. I don't know the encoding of
the filename's bytes, but I _must_ faithfully reproduce them exactly as they
are or I'll break tools like make(1) and patch(1). Similarly, if a file goes
from ISO-8859-1 to UTF-8, I have to emit a diff that has some ISO bytes and
some UTF bytes - it's not in *any* valid encoding. Changing that is a
showstopper regression.
The Unicode type became natural in Python 3, as byte string (old str
type) was natural in Python 2.
sys.stdout.write() expects a Unicode string, not a byte string.
Ouch. Is there any way to write things to stderr and stdout without decoding
and hopelessly breaking user data?
Does it mean that Mercurial is moving to Python 3? Cool :-)
Not likely, honestly. I tackle this when I've got some spare cycles and my
ability to handle pain is high. As it stands, I have the test-runner barely
working, but it's making wrong assumptions to get there. The best estimate is
that it's a year of work to upgrade to Python 3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3982
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3982
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Augie Fackler added the comment: On Oct 8, 2013, at 6:19 PM, Glyph Lefkowitz rep...@bugs.python.org wrote: Glyph Lefkowitz added the comment: On Oct 8, 2013, at 2:35 PM, Eric V. Smith wrote: What proposal is actually on the table here? Sorry Eric, you're right, there is too much discussion here. This issue ought to be about .format, like the title says. There should be a separate ticket for %-formatting, since it seems to be an almost wholly unrelated task. While I'm sympathetic to Mercurial's issues, they're somewhat different from Twisted's, in that we're willing to adopt the one new way to do things in order to achieve compatibility whereas that would be too hard for Mercurial. Yeah, my bad too. I suppose I should add a new bug for %-formatting on bytes objects? Note that for hg, we can't drop Python 2.6 or so (we'll only drop *2.4* if we can do 2.6 and some 3.x from a single source tree) for a while, due to supporting the system interpreter on a variety of LTS platforms. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Augie Fackler added the comment: On Oct 8, 2013, at 6:28 PM, Terry J. Reedy rep...@bugs.python.org wrote: http://www.python.org/dev/peps/pep-0383/ One point of the pep is round-trip filenames without loss on all systems, which is just what you say you need. At a quick skim, likely not good enough, because http://en.wikipedia.org/wiki/Shift_JIS isn't completely ASCII-compatible, and we've got a fair number of users on weird Shift-JIS using platforms. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Augie Fackler added the comment: I'd like to put a nudge towards supporting the __mod__ interface on bytes - for Mercurial this is the single biggest impediment to even getting our testrunner working, much less starting the porting process. -- nosy: +durin42 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7946] Convoy effect with I/O bound threads and New GIL
Changes by Augie Fackler li...@durin42.com: -- nosy: +durin42 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2770] Subversion 1.5 Working Copies Break Setuptools
New submission from Augie Fackler [EMAIL PROTECTED]: Subversion 1.5 adds some fields to the entries file in the working copy administrative area. As a result of this, the way in which setuptools checks the entries files results in a raised exception. Having read the spec for the entries file, the issue can be fixed simply by looking for version 8 or version 9 in the opening of the entries file. I've attached a patch that does this. I've tested it extensively locally (been using it for months). -- components: Distutils files: setuptools_patch.txt messages: 66271 nosy: durin42 severity: normal status: open title: Subversion 1.5 Working Copies Break Setuptools versions: Python 2.5 Added file: http://bugs.python.org/file10198/setuptools_patch.txt __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2770 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
