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.