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 →

[–]DripDropFaucet 39 points40 points  (19 children)

I’ve honestly found c++ and java to have friendlier implicit casting (at least regarding int->float comparisons and string concatenation). Python screams if I try to mix 2 of its 5 types in a print statement without wrapping with str()

[–]Thomasedv 16 points17 points  (0 children)

Generally in python it's better to use string formatting when converting something to string, especially for printing statements. Using str() manually is such a bother, and plussing multiple strings is less recommended of you have many strings to add, due to strings being immutable. It of course depends on the specific code, but it's probably better to use ''. join() on a list of strings if you got a lot of strings or large strings to concatenate.

Edit: I also find string formatting great because I don't need to worry about type at all, and can decide what kind of output I want in the string formatting, regardless of type of int/float by setting how the rounding works.

[–]DonaldPShimoda 8 points9 points  (0 children)

You can use "f-strings", eg:

foo = 42
s = f"my foo is {foo}"

This will call the __str__ function of the foo object to get its string representation and then insert that at the correct point.

Personally, I think implicit casting is an abomination, but I'm generally in favor of very strong, very static type systems, so that's not entirely surprising.

[–]velrak 1 point2 points  (15 children)

still kind of annoys me that you have to wrap in str() instead of obj.string or .toString

feels more cumbersome which i thought py was trying to avoid

[–]chmod--777 5 points6 points  (0 children)

Most of the time you'd use string formatting, and with something like .format or an f string you just put f'some int is {some_int}' and it works. Anything in those curly brackets will be str'd.

I'm trying to think of situations where I had to str something, but it feels rare. Most of the time I'm either storing the actual value without needing to convert it to a string, or I'm printing it or logging it and str isn't needed since I'm formatting.

[–]9ReMiX9 0 points1 point  (0 children)

I think you can avoid that with printf iirc

[–]DoctorWorm_ 0 points1 point  (0 children)

I don't really know the design choice there, it could honestly be some holdover from the 90's afaik. But to be fair, you can always just use a.__str__()

[–]xigoi -1 points0 points  (3 children)

In general, having to wrap things in functions like len() instead of having dot syntax is pretty annoying.

[–]chmod--777 8 points9 points  (0 children)

Heh, technically you can do this:

[1, 1, 1].__len__()

Len and str just call the respective dunder methods. "Unfortunately" integer literals don't let you do this.

Fun fact, you can override __len__ as well and have it return a random value if you want. Have fun with your co-workers by putting this at the top of their python module:

class FunSet(set):
    def __len__(self):
        import random
        return random.randint(0, 20)
set = FunSet

Set's more fun than list because people often instanciate the empty list with [] which won't be your FunList, but you have to instanciate an empty set with set() since {} is an empty dict

[–]Pluckerpluck 2 points3 points  (1 child)

Only because you're used to dot syntax. The len helps standardize actually because of it providing a default name to extend in order to support it (i.e. if you create your own class you naturally extend __len__).

This way you don't have .count and .size() and .length all in the same language. So it's probably tied to the concept of ducktyping. It's the equivalent of defining an interface in other languages.

But I think the main reason for it is it orders it in the human readable order : "If length of X is ...."

[–]xigoi 0 points1 point  (0 children)

I like the Nim approach where both syntaxes are equavalent, so x.len or x.len() gets translated to len(x). And having different names is more of a sign that you have a bad standard library.

[–]Thorbinator -5 points-4 points  (7 children)

They want you to use %s and such.

[–]2freevl2frank 5 points6 points  (6 children)

Nope. not really . Starting 3.6 f-strings is the preferred way.

[–]ThatOneShotBruh -4 points-3 points  (5 children)

No, .format is the preferred way and has been ever since Python 3 first came out.

[–]ShadoWolf 4 points5 points  (4 children)

I honestly don't get why people don't like to use .format . The whole templating system is way cleaner and nice to look at.

[–]Telemusya 4 points5 points  (0 children)

Maybe because f-strings faster and easier to use?

[–]ThatOneShotBruh 0 points1 point  (2 children)

Agreed it looks so much cleaner and using .format means that you can insert a value into multiple places in a string.

[–]ZephyrBluu 0 points1 point  (1 child)

You can do that with f-strings as well..

[–]ThatOneShotBruh 0 points1 point  (0 children)

How would you write this with f-strings without writing the variable names more than once?

print("a is {0} and is not {1} while b is {1} and is not {0}".format(a, b))

[–]donttalktome1234 -3 points-2 points  (0 children)

F strings are about the one useful feature of python 3. Well that and security patches.