On Fri, Aug 19, 2016 at 12:30 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
> So in porting to py3, they would have had to *add* that 'b' (and a bunch of
> b'filename') to keep the good old bytes is text interface.
>
> Why would anyone do that?

For a fair amount of *nix-centric code that primarily works with ASCII
data, adding the 'b' prefix is the easiest way to get into the common
subset of Python 2 & 3.

Sure -- but it's entirely unnecessary, yes? If you don't change your code, you'll get py2(bytes) strings as paths in py2, and py3 (Unicode) strings as paths on py3. So different, yes. But wouldn't it all work?

So folks are making an active choice to change their code to get some perceived (real?) performance benefit???

However, as I understand it, py3 string paths did NOT "just work" in place of py2 paths before surrogate pairs were introduced (when was that?) -- so are we dealing with all of this because some (a lot, and important) libraries ported to py3 early in the game?

What I'm getting at is whether there is anything other than inertia that keeps folks using bytes paths in py3 code? Maybe it wouldn't be THAT hard to get folks to make the switch: it's EASIER to port your code to py3 this way!

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov