On Wed, 3 Aug 2016 08:16 pm, BartC wrote:
> On 03/08/2016 06:43, Steven D'Aprano wrote:
>
>> Not everything that is done is worth the cognitive burden of memorising a
>> special case.
> ....
>
>> In some ways, Python is a more minimalist language than you like. That's
>> okay, you're allowed to disagree with some design decisions.
>
> Well it's minimalist in some ways, and completely the opposite in others!
>
> It uses minimal basic syntax (missing a couple of loop forms, loop
> controls, switch/case, select-expressions... it's just a handful of
> features).
>
> But then you get to the standard library, and the plethora of different
> data types, methods and options. It's never-ending!
"Never-ending" is a bit of an exaggeration. You should check out the Java
libraries, and how many different kinds of key:value mapping they provide.
They make Python's collection of types look positively anaemic :-)
In general, most types and operations in Python earned their place by
proving their usefulness. They proved that they are useful, hard to program
correctly, easy to get wrong, or some combination of all three. Many of
them have gone through a gruelling process of discussion via a Python
Enhancement Proposal (PEP) before being accepted. Having written two PEPs,
I can tell you that in general the Python core developers attitude to
adding new features, types or operations is to be very conservative and say
No. Most suggestions get rejected even before that point.
For instance, Guido used to reject the idea of having a ternary if operator
for years. Python didn't need it, you can use an if...else statement, or
when you need an if expression, use shortcut bool operators:
result = condition and x or y
gives x if condition is true and y if condition is false.
At least, that's what Guido used to say... until he personally got bitten by
a flaw in the argument. If x is a falsey argument, y is always returned. It
took something in excess of 15 years before anyone publicly noticed this
flaw, and when Guido did, Python pretty quickly got a ternary if operator.
> So the idea that remembering 'repeat N' is a cognitive burden, and the
> myriad string operations for example are not, is ridiculous.
Who says it isn't a cognitive burden? Of course it is.
The difference is that most of the string methods carry their own weight in
usefulness versus burden, and "repeat N" doesn't (according to the core
developers). You have weighed "repeat N" high on the usefulness side and
low on the burden side, and Guido has done the opposite.
This is, of course, a subjective argument. I'm not trying to convince you
that you're wrong and Python is right. I completely accept that different
people have different opinions on the usefulness versus burden of adding a
specific feature. (That's why we have different languages, and some people
like Perl where there are a million ways to do everything and some people
don't.) I'm just trying to get you to understand where Python is coming
from, not necessary to agree with every one of its design decisions, but to
understand why they are the way they are.
Its trivial to perform "repeat N" using the standard "for x in ..." syntax
and built-in range() function, so including a dedicated "repeat N" syntax
doesn't add much to the language. It's a trivial operation easily performed
using a for loop. So the benefit is small. The cost is also small, but
greater than the benefit: there's a new keyword, which means any code
using "repeat" as a variable, function or method will break. Its more code
in the compiler (even if it's only an extra ten bytes, that's still more).
It's another feature that needs to be documented and tested. It's another
decision for users to make, "should I use repeat N, or a for loop?", and
another feature beginners to learn.
Individually these costs are small, but they aren't *zero*. Collectively,
according to the judgement of the people making the decision, they add up
to more cost than the minimal benefit that "repeat N" would bring.
But to take your example of str.encode... if Python didn't provide it, it
would be a dozen kinds of a pain in the arse to provide it yourself.
Especially with any sort of efficiency. Not to mention actually coming up
with the encodings themselves. There are *dozens* of them. Adding one more
string method "encode" to the dozens already there is not much of an
additional burden. It doesn't stop people from using "encode" as a function
name or variable, since the encode method is isolated to the str namespace.
It provides a very important function, one which is critical in the
post-ASCII world, and it is too difficult to expect users to implement
their own. So the benefit is much greater than the cost.
On the other hand, there's also str.swapcase(), which only remains due to a
combination of nostalgia and backwards compatibility. Occasionally people,
including Guido, suggest removing it: its pretty much useless, and hardly
anyone uses it. It isn't hard to write your own version, and its unlikely
to be used in performance-critical code. So removing the feature has very
little cost. But the benefit from removal is also correspondingly tiny.
Even if it only affects ten Python developers in the whole world, forcing
them to write their own swapcase function, that cost is greater than the
benefit from removing it. And so it stays.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
