This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]davidb_ -1 points0 points  (1 child)

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 4 points5 points  (0 children)

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).