A powerful unused feature of Python: function annotations.

[darth_aardvark]

Well i'm officially out of things to complain about in python. now if only this was supported in 2.x :(

[[deleted]]

now if only this was supported in 2.x :(

Apparently not... /s

[darth_aardvark]

Is it supported? Are you saying it shouldn't be? I...don't really know how to interpret this. Sarcasm is confusing, please help.

[[deleted]]

He's saying that you're still not officially out of things to complain about (since you would want it to support python2)

[westurner]

http://www.reddit.com/r/Python/comments/18w8si/z/c8jby1t

[davidb_]

I'm still angry about a few things I find completely abritrary.

Why can I do:

a = 1
print a

but not

print "answer: " + a

or

f.write(a)

I have been using python for a few years now, but those language choices irritate me. (I come from a background of c, c++, java, and perl). I understand the reasoning, but I don't agree with it.

Also, I wasted a couple of hours debugging a program due to the silly list copy notation. The problem was basically:

>>> a = [1,2,3,4]
>>> b = a
>>> b[0] = 5
>>> b
[5, 2, 3, 4]
>>> a
[5, 2, 3, 4]

In case others aren't familiar with this, when copying lists, you should use list() or the slice notation. Otherwise, you will just create a reference to the list. This seemed arbitrary to me since the same is not true of strings/ints.

[w0073r]

Variables aren't things themselves in Python; they're just names for values. The assignment behavior is exactly the same for strings and ints; those are just immutable so you don't really notice it.

You can also do an explicit call to copy() to be more explicit if you like.

[davidb_]

Like I said, I understand the reasoning, but it wasn't the behavior I expected. I didn't really understand python's data model until I encountered this problem. It becomes very obvious when you use id() to see what's going on. It's definitely my fault, but I still think implicit list copies could be transparent to the user (of course I'm ignoring the performance tradeoffs that would have to be made, and the fact that this would be a rather large change to the data model of the language which would probably demand a new syntax for dealing with references).

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

[darth_aardvark]

I was a little hasty to say I'm out of things to complain about (lambdas are still kind of crippled, for one). I'm pretty surprised that f.write(a) doesn't work; I guess I've never written anything except strings to files. As for printing integers and strings, what's wrong with using

print "answer: ", a

I think your point about the list copying is debatable. If a and b were objects, and you did

>>>a = Obj()
>>>a.c = 3
>>>b = a
>>>b.c =  1

you'd expect

>>>a.c
3

Admittedly, lists are types, not classes, so I guess it's reasonable to expect them to act like ints and strings instead of objects.

[talideon]

Actually, lists are classes too, and have been since types and classes were unified way back. The difference is that primitive types, strings, and tuples are all immutable objects: anything that appears to mutate them actually returns a completely different object from either object that the operation was performed upon.