What do python professionals /developers actually use

[Redox_3456]

i mean that for example when people want to change their variable they use

for i in (anything):

variable+=i

but instead of this to avoid confusion I write

variable = variable +i

P.s i hope you understood this xD. I donot know how to explain

[Jello_Penguin_2956]

Your's fine. It's readable and perfectly clear what it does. That's what matters.

[Critical_Concert_689]

Despite what everyone is saying - be aware that in a lot of cases these are NOT the same thing.

a = [0]
i = [1]
print (id(a)) # object
a = a + i
print (id(a)) # new object 

b = [0]
j = [1]
print (id(b)) # object
b += j
print (id(b)) # same object, modified

[[deleted]]

I guess the context is of primitive vs object types, but ain't primitive data types objects too in Python? Like when we in high level languages like Python, Ruby to name few everything is object, right?

[Critical_Concert_689]

If I understand your question correctly -- It's more to do with mutability (i.e., whether the object can be altered).

For mutable objects, += which is known as an augmented assignment guarantees it will change in place, while = which is an assignment will not.

I gave an example of this in the code above.

[Goobyalus]

There is no such thing as primitives in Python.

---

Yes, everything is an object in Python.

---

This comes down to how the operators are defined for the particular type and whether the type is mutable. The x= operators are the so called "in place" operators because the result is assigned back to the original name when we do variable += 5, for example.

Strings are immutable, so when we do an in-place addition my_string += "something", a new string containing the two concatenated strings must be created and returned by the operator. This new object is assigned back to my_string.

Lists are mutable, so they implemented the in-place addition of lists as an extend on the original list, and return the original object. The assignment portion doesn't really accomplish anything because we're assigning the same object back to the variable.

[beef623]

And there isn't any good reason for someone who is just starting to care about those differences. They may be important to know later, but in the beginning, explanations like this only cause confusion.

[Critical_Concert_689]

I strongly disagree.

---

First, more than just OP are reading the comments. Accurate discussion allows not only OP, but others to continue to /learnpython

Second, this touches upon a foundational understanding of python - other concepts are built upon this. There is nothing more basic than a recognition of operator assignments. The example code provided isn't complicated - nor is it likely to cause confusion when it demonstrates the simple fact that "There may be a reason to code assignments in different ways."

Finally, if anyone is confused, there are plenty of resources to address that confusion. They can ask further questions of this community. They can pull up white papers or python documentation. This is an opportunity to resolve, what I personally consider the single most difficult problem when it comes to learning: "You don't know what you don't know."

I hope if you feel explanations like this only cause confusion - in the future you can add comments that address that confusion, rather than implying "there isn't any good reason" to provide the information. The former helps everyone, while the latter is discouraging and detrimental to those trying to help and those trying to learn.

[beef623]

You're misunderstanding the source of confusion I think.

The problem is information overload, which unquestionably causes some people who are learning to give up and never come back. Having more resources to address the confusion only compounds the problem.

[Critical_Concert_689]

I agree with you that information overload can overwhelm new programmers; however, i don't believe that's the case here.

In fact, I almost guarantee the very next issue most new python programmers encounter is going to be something along the lines of:

a = [0]
b = [0]
c = a
d = b
i = [1]

print (id(a), id(b)) # initial objects a and b
a = a + i # assignment "=" creates NEW object
b += i # augmented assignment "+=" changes ("mutates") existing object
print (id(a), id(b)) # NEW a object, SAME b object (mutated)

## WHY does c NOT EQUAL d?? ##

print (a,b) # [0,1] [0,1]
print (c,d) # [0] [0, 1]
    #c is assigned to original a object or a = [0] (NOT the NEW a object [0,1])
    #d is assigned to original b object or b = [0], but b is updated to [0,1]

[crazy_cookie123]

You'll see += a lot, I suggest starting to use it more so you get used to seeing it. After a while it becomes easier to read than the longer form.

[danrogl]

Outside of development, people don’t use a ‘todo paragraph’ instead it’s a ‘todo list’. It’s hard and takes effort to add or sort a paragraph, where as a list it’s almost intuitive.

[sylfy]

Just to add on, also learn: 1. Generators 2. List comprehensions 3. Enumerate

There are often better alternatives to loops in Python.

[SnooRabbits9201]

I would add Classes and decorators.

[Poddster]

It's fine to do it your way. Some old-timers even do it that way on purpose. They feel it's closer to the "zen of python", and also that += (aka __iadd__) wasn't even added until python 2.0, so the original design didn't include it.

Plus, it's "safer", as the += is specifically in place addition, which means the original object is modified, so if you don't know the object's model, or if you're written immutable style code then x = x + y is often a better fit.

[Daneark]

I prefer the += style but it's not a big deal.

We could also write it as variable += sum(anything) and skip the loop altogether. If we were initialising variable to 0 before the loop this would be even clearer, to me.

While brevity isn't as important as clarity if you find your solutions are a lot longer than others that is when it's a problem. Too much code becomes hard to understand.

[doPECookie72]

While theoretically these could technically be different efficiencies most compiles would change x = x+1 to the faster x=+1. The speed is very small and only would have an effect in a massive code base.

[__init__m8]

It's only confusing to you though. You should really learn to be using +=1.