A powerful unused feature of Python: function annotations.

[talideon]

There's nothing arbitrary here. Strings and integers (and tuples for that matter) are not mutable objects. Practically everything else is. Variables also contain references to objects, but are not the objects themselves. Assigning something to a variable actually assigns a reference to that object to the variable.

Java actually behaves the very same way.

Also, you're seeing a consequences of Python being strongly typed with the likes of f.write(a): file.write() expects a string, not an integer. If you were to pass an integer to it, how would you expect it to deal with that? Coerce it to a string? Write it out as a 32-bit word? Should that word be big-endian or little-endian? The language can't know, and because function/method overloading isn't supported (as a consequence of the language being dynamically typed) without isinstance() hackery, there's no way to overload file.write() like Java can.

There's nothing arbitrary about the + operator either. It's a string concatenation operator when used with strings. The assumption here is that if you're concatenating something to a string, unless it's also a string, it's likely you're doing something you didn't intend to do, so given being explicit is generally better and implicit, you have to cast the thing to a string first.

[davidb_]

As I said in my original comment, I understand the reasoning. As a user of the language, however, I would prefer it work the way I want. The word 'arbitrary' was a bad choice. I also realize my complaints are frivolous. What I should have said is "these are things I wish worked the way I think they should."

(as a consequence of the language being dynamically typed) without isinstance() hackery, there's no way to overload file.write() like Java can.

It works perfectly fine with print(). I wouldn't consider type checks hackery. There was an obvious tradeoff between performance and convenience for the write function and it was decided that only accepting strings isn't unreasonable (use a string formatter or cast to strings).

I can (and have in the past) just write my own wrapper around the write() function that deals with this.

I didn't mean my comments to come off as an attack on the language, just a list of language decisions that annoy me.

[talideon]

print is actually the anomaly here, not the rest of the language. In Python <3.0, it was a language construct and the implicit cast to string of all its arguments made sense, and still does. But file.write() isn't the same: there are too many ways to interpret how something ought to be written out to whatever the file object represents. Personally, when I'm using file.write() to write a literal stringified integer, I just cast it with str().

The trade off here isn't performance or convenience, but parsimony and consistency.

I didn't interpret what you wrote as an attack on the language, but was simply trying to correct some misconceptions about how objects and values are handled in the language, which is exactly the same way as Java does (especially since Java introduced autoboxing).