Python slang

[Chris Angelico]

On Sat, Aug 6, 2016 at 8:00 AM, Marco Sulla via Python-list
<python-list at python.org> wrote:
> I have a simple curiosity: why Python has much keywords, and some
> builtin types and methods, that are different from the other
> languages? What is the rationale?

This isn't slang; it's jargon, perhaps, but "slang" implies an
unofficial form of use. "Python slang" might include the myriad
references to "spam" throughout the code and docs, and other Monty
Pythonisms. But that aside, these are great questions to ask. As some
people put it: "Why is it so?".

> I'm referring to:
> * `except` instead of `catch`

Not sure. Python does seem to be roughly unique in this.

> * `raise` instead of `throw`

Quite a few other languages talk about raising exceptions rather than
throwing them. Those would be the two most common terms, I think.

> * `self` instead of `this` (I know, it's not enforced, but it's a de
> facto standard and some IDEs like PyDev gives you an error if you
> declare a non-static method without `self` as first parameter)

Smalltalk and friends also use "self", so again, this would be the
other common word for the parameter.

> * `dict` instead of `map`

"map" has many other meanings (most notably the action wherein you
call a function on every member of a collection to produce another
collection).

> * `list.append()` instead of `list.push()`

Better description of what it does, IMO. It's adding something to the
end of the list - appending to the list.

> * `str.strip()` instead of `str.trim()`

Another case where both words are in common use.

> * `True`, `False` and None instead of `true`, `false` and `none` (they
> seems classes)

This one, I've no idea about. Why have "bool" as the type, and "True"
and "False" as the instances? I think the built-in types have their
names grandfathered in from when they were factory functions, but that
doesn't explain the capitalized instances. (And the type of None is
NoneType, just to confuse the matter further.)

> * and furthermore much abbreviation, like `str` instead of `string`
> and `len()` instead of `length()`, that seems to contrast with the
> readability goal of Python.

Brevity can improve clarity, if it is obtained without the expense of
accuracy. In the same vein, Python has one-character symbols instead
of "add" and "divide". There's a balance to be struck; bitwise Or has
a symbol, but short-circuiting boolean Or has a word.

> I don't ask about `None` instead of `null` because I suppose here it's
> a matter of disambiguation (null, in many languages, is not equal to
> null).

None isn't really like null, but it sometimes does the job that null
does in other languages. It isn't a "non-object"; it's an object, same
as any other, that happens to be a falsey singleton. Given that C's
NULL pointer isn't the same as SQL's NULL nor ASCII's NUL, having a
Python null that's different again wouldn't help. So yes, it's
disambiguation; this is not the same thing as null.

Hope that helps a bit!

ChrisA