From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16489 invoked by alias); 10 Jul 2014 04:59:22 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 16452 invoked by uid 48); 10 Jul 2014 04:59:20 -0000 From: "b.r.longbons at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug python/17138] C strings, gdb.Value.__str__, and Python 3 Date: Thu, 10 Jul 2014 04:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: python X-Bugzilla-Version: 7.7 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: b.r.longbons at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q3/txt/msg00035.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17138 Ben Longbons changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |b.r.longbons at gmail dot com --- Comment #1 from Ben Longbons --- Having done a lot, there are only a couple of solutions for dealing with strings: 1. Avoid unicode strings entirely, use 'bytes', avoid operations that differ (particularly, indexing, which returns an integer in python3). Disadvantage: lots of operations are not available on 'bytes' in python3. 2. Use unicode everywhere, with errors='surrogateescape'. Disadvantages: have to put up with lots of whining from the Python community about how you don't understand strings; has no C implementation in python2 and you have to bundle the python version. 3. Use unicode in python3, bytes in python2. Advantage: avoids most of the language-feature problems. Disadvantage: *lots* of opportunities for subtle bugs, such as the ones mentioned in this bug report. You'll note that all the real difficulties occur only in Python3, since it *insists* that you have absolute knowledge about and control over your users (this has caused no end of pain for people writing webservers). 3 is what programs do if you don't pay any attention. 2 is feasible if you are developing new code with python3 as your primary target (from __future__ import unicode_literals). 1 is the most correct for the kind of work gdb is doing, but can be painful without a. But that leads us to: 4. Invent an entire new string type that just DTRT in both python2 and python3. This *should* be possible as long as everyone duck types. It probably *is* safe to assume that any unicode string you get (mostly, from python string literals) is safe to treat as utf-8 (most of them will be ascii anyway), but for the vast majority of your code, you can just deal with byte strings in whatever encoding the inferior wants. In approach 4, all functions that take strings, just need to feed them through the new string factory, so there's not a lot of pain on callers. There is, however, a problem that you can't use *builtin* functions on strings, particularly you can't write: '%s %s' % (a, b), you have to write bstring('%s %s') % (a, b). The best we can do for this case is try to see if it's possible to make that always throw an exception, so at least they will fail quickly. Unless maybe we hook in an AST rewriter like py.test does ... If all this seems too complicated: 5. Just stick with python2 forever, and acheive ultimate success by simply ignoring python3 and unicode. -- You are receiving this mail because: You are on the CC list for the bug.