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
--
https://mail.python.org/mailman/listinfo/python-list
