On Aug 24, 2012 6:17 PM, "Paul Moore" <p.f.moore@gmail.com> wrote:
On 24 August 2012 21:21, Daniel Holth <dholth@gmail.com> wrote:
Hi Paul! You could probably guess that this is the wheel digital signatures package. All the string formatting arguments (I hope) are now passed to binary() or native() string conversion functions that do less on Python 2.7 than on Python 3.
One point that this raises. Any such "string-only" format spec would only be available in Python 3.4+, and almost certainly only in format(). So if you're interested in something that works across Python 2 and 3, you wouldn't be able to use it anyway (and something like the must_be_str function is probably your best bet). On the other hand, if you're targeting 3.4+ only, the bytes/string code is probably cleaner (that being a lot of the point of the Python 3 exercise :-)) and so the need for a string-only spec may be a lot less.
I dunno. I haven't hit a lot of encoding type issues myself, so I don't have much background in what might help. OTOH, what I *have* found is that the change in thinking that Python 3's approach pushes onto me (encode/decode at the edges and use str consistently internally, plus never gloss over the fact that you have to know an encoding to convert bytes <-> str) fixes a lot of "problems" I thought I was having...
That's the core of it. You can convert bytes to string without knowing the encoding. "%s" % bytes. But instead of failing or converting from ascii it does something totally useless. I argue that this is a bug, and an alternative 'anything except bytes' should be available. Not so hot on the competing only-str idea. On Aug 24, 2012 6:17 PM, "Paul Moore" <p.f.moore@gmail.com> wrote:
On 24 August 2012 21:21, Daniel Holth <dholth@gmail.com> wrote:
Hi Paul! You could probably guess that this is the wheel digital signatures package. All the string formatting arguments (I hope) are now passed to binary() or native() string conversion functions that do less on Python 2.7 than on Python 3.
One point that this raises. Any such "string-only" format spec would only be available in Python 3.4+, and almost certainly only in format(). So if you're interested in something that works across Python 2 and 3, you wouldn't be able to use it anyway (and something like the must_be_str function is probably your best bet). On the other hand, if you're targeting 3.4+ only, the bytes/string code is probably cleaner (that being a lot of the point of the Python 3 exercise :-)) and so the need for a string-only spec may be a lot less.
I dunno. I haven't hit a lot of encoding type issues myself, so I don't have much background in what might help. OTOH, what I *have* found is that the change in thinking that Python 3's approach pushes onto me (encode/decode at the edges and use str consistently internally, plus never gloss over the fact that you have to know an encoding to convert bytes <-> str) fixes a lot of "problems" I thought I was having...
Paul.