"More About Unicode in Python 2 and 3"

[Ned Batchelder]

On 1/6/14 11:01 PM, Steven D'Aprano wrote:
> On Mon, 06 Jan 2014 16:32:01 -0500, Ned Batchelder wrote:
>
>> On 1/6/14 12:50 PM, Steven D'Aprano wrote:
>>> Ned Batchelder wrote:
>>>
>>>> You are still talking about whether Armin is right, and whether he
>>>> writes well, about flaws in his statistics, etc.  I'm talking about
>>>> the fact that an organization (Python core development) has a product
>>>> (Python 3) that is getting bad press.  Popular and vocal customers
>>>> (Armin, Kenneth, and others) are unhappy.  What is being done to make
>>>> them happy?  Who is working with them?  They are not unique, and their
>>>> viewpoints are not outliers.
>>>>
>>>> I'm not talking about the technical details of bytes and Unicode.  I'm
>>>> talking about making customers happy.
>>>
>>> Oh? How much did Armin pay for his Python support? If he didn't pay,
>>> he's not a customer. He's a user.
>>
>> I use the term "customer" in the larger sense of, "someone using your
>> product that you are trying to please."  I'd like to think that an open
>> source project with only users would treat them as customers.  Not in
>> the sense of a legal obligation in exchange for money, but in the sense
>> that the point of the work is to please them.
>
> But isn't the strength of open source that people write software that
> pleases *themselves*, and if others can make use of it, we all win? If GvR
> wrote Python to please others, it would have braces, it would be more
> like Perl and C, and it would probably be a mess.
>
> All else being equal, it's better for open source software if your users
> are happy than if they are unhappy, but at what cost? You can't make
> everyone happy.

Of course, but there has to be a balance.  One of the strengths of 
Python is that the core developers listen to people and will take a 
pragmatic approach that solves real problems.

The change in 3.3 that re-added u"" literals is an interesting case: 
there was strong opposition to the proposal, because it weakened the 
purity of the new approach to Unicode.  It won out because it made it 
easier to port code to 3.3, not because it made it easier to write a 
program that ran on 3.3, but because it made it easier to write a 
program that ran on both 2.7 and 3.3.

> [...]
>> I was only avoiding talking about Unicode vs bytes because I'm not the
>> one who needs a better way to do it, Armin and Kenneth are.  You seem to
>> be arguing from the standpoint of, "I've never had problems, so there
>> are no problems."
>
> Certainly not. I've tried hard not to say, or imply, that Armin is wrong.
> I know he is an extremely competent Python developer, and I don't
> understand his problem domain well enough to categorically say he's
> wrong. I *suspect* he's doing something wrong, or at least sub-optimally,
> and making things more difficult for himself than they need be, but what
> do I know? Maybe that's just my wishful thinking.

I was advocating for people learning more about his problem domain to 
understand where the friction was, and improve the situation.

>> I suspect an undercurrent here is also the difference between writing
>> Python 3 code, and writing code that can run on both Python 2 and 3.
>
> Of course. It's always harder to target multiple versions with
> incompatibilities than a single version.

As I mentioned above, I think one of the under-exposed points of 
disagreement is how much Python 3 needs to make it possible to write 
polyglots, and how much it can focus on pure Python 3 programs.

When the debate comes down to, "It's hard to write my programs!" 
countered with, "But Python 3 does this better than Python 2!", perhaps 
we need to uncover that the first person cares a lot about writing 2+3 
code, and the second person does not.  At least then we could understand 
why we seem to be talking past each other.

>> In my original post, I provided two possible responses, one of which
>> you've omitted: work with Armin to explain the easier way that he has
>> missed.
>
> Isn't that just another way of saying what I said earlier?
>
> "try to educate Armin (and others) so they stop blaming Python for their
> own errors"
>
> Although your version is more diplomatic.
>
>
>> It sounds like you think there isn't an easier way, and that's
>> OK? I would love to see a Python 3 advocate work with Armin or Kenneth
>> on the code that's caused them such pain, and find a way to make it
>> good.
>
> Is it a good think that there's code that's hard to write in Python 3?
> Not in isolation. But sometimes when you design a language, you
> implicitly or explicitly decide that certain types of code will not be a
> good fit for that language: you can't write an efficient operating system
> kernel in Python. Maybe you can't easily do the sort of low-level network
> stuff that Armin is trying to do in Python 3. But I doubt it. I expect
> that probably half the problem is that he's missing something, or doing
> something wrong, and the other half is that Python 3 genuinely makes it
> harder than it should be. But again, what do I know?

I appreciate the allowance for the possibility that Python 3 still has 
changes to make to improve the situation.

>> It's clear from other discussions happening elsewhere that there is the
>> possibility of improving the situation, for example PEP 460 proposing
>> "bytes % args" and "bytes.format(args)".  That's good.
>
>
> I don't know... if byte formatting ends up encouraging people to use
> bytes when they ought to use strings, maybe it will be an attractive
> nuisance and in the long-term do more harm than good. But I'm keeping an
> open mind.

Eh, there are lots of things that have narrow uses and get mis-applied, 
and Python is better for having them available.  Practicality beats purity.

In all this, I've been very impressed (as usual!) with Nick Coghlan's 
responses (https://twitter.com/jubiweb/status/419812396085960704):

"'tis healthy criticism - a change of this magnitude *deserves* to be 
challenged to make sure we articulate our motives."

"I still learn more from Armin's disagreement than if he instead chose 
to just walk away."


-- 
Ned Batchelder, http://nedbatchelder.com