Why append to list is not the same as +=

ajiten · 05-14-2024, 12:47 AM

The first method uses list comprehension, and appends the string in the array 'names' satisfying the given criteria.

First code>

Code:

names=['Jerry', 'Kramer', 'Elaine', 'George', 'Newman']
best_list = [name for name in names if len(name)>=6]
print(best_list)

Output:

Code:

['Kramer', 'Elaine', 'George', 'Newman']

----------------------------------------------------------------------
The second method also does the same, as above.

Second code>

Code:

names=['Jerry', 'Kramer', 'Elaine', 'George', 'Newman']
better_list=[]
for name in names:
    if len(name)>5:
        better_list.append(name)
print(better_list)

Output:

Code:

['Kramer', 'Elaine', 'George', 'Newman']

----------------------------------------------------------------------------------
If change the second code to the one below, then the individual characters, are stored:

Third code>

Code:

names=['Jerry', 'Kramer', 'Elaine', 'George', 'Newman']
better_list=[]
for name in names:
    if len(name)>5:
        better_list+=name
print(better_list)

Output:

Code:

['K', 'r', 'a', 'm', 'e', 'r', 'E', 'l', 'a', 'i', 'n', 'e', 'G', 'e', 'o', 'r', 'g', 'e', 'N', 'e', 'w', 'm', 'a', 'n']

-----------------------------------------------------------------------------------------------------
Question: a) Why the third code, saves the individual characters, is unclear.
b) Also, how can the first code be modified to give the same output as the third code?

pan64 · 05-14-2024, 02:52 AM

yes, that looks strange, but actually a string is an array of chars and += will just concatenate the two arrays (left side + right side).
append will add a single item to the list/array, which is the string itself.

sundialsvcs · 05-14-2024, 07:24 AM

And this sort of thing is definitely(!) where "D'oh!" problems come about. And why this web-site has both this built-in emoji and this one:

In many languages, not just Python, there are subtly-different things which, "at first glance," appear to be the same. But they're not. So, when you are "reading the source code, looking for that damned bug," you might fail to see it for a long time. Because of course you "see, at a glance" what you expect to see. Even if the language designer thought that some different behavior was "a fee-chur."

In Python, the "+=" operator was so-called overloaded in this way. But it is not the same as .append(). Even though it looks like it is, or ought to be.

And, worse yet – another language-designer might have made an entirely different choice. (In fact, "I once wrote a programming language of my own"

, and in that project I did.) So, "your experience with other languages" can actually lead to an unexpected and extremely-annoying surprise.

P.S.: This is one reason why I've introduced all of my programming teams to "the five-minute rule." If you don't see what's wrong with a piece of code after five minutes – and, having tried as best you can to zero-in on where "the bug" must be – ask for another pair of eyes. I explicitly tell the team that "anyone who does this is not 'interrupting you.'"

ajiten · 05-14-2024, 11:31 PM

Quote:

Originally Posted by sundialsvcs

And this sort of thing is definitely(!) where "D'oh!" problems come about. And why this web-site has both this built-in emoji and this one:

In many languages, not just Python, there are subtly-different things which, "at first glance," appear to be the same. But they're not. So, when you are "reading the source code, looking for that damned bug," you might fail to see it for a long time. Because of course you "see, at a glance" what you expect to see. Even if the language designer thought that some different behavior was "a fee-chur."

In Python, the "+=" operator was so-called overloaded in this way. But it is not the same as .append(). Even though it looks like it is, or ought to be.

And, worse yet – another language-designer might have made an entirely different choice. (In fact, "I once wrote a programming language of my own"

, and in that project I did.) So, "your experience with other languages" can actually lead to an unexpected and extremely-annoying surprise.

P.S.: This is one reason why I've introduced all of my programming teams to "the five-minute rule." If you don't see what's wrong with a piece of code after five minutes – and, having tried as best you can to zero-in on where "the bug" must be – ask for another pair of eyes. I explicitly tell the team that "anyone who does this is not 'interrupting you.'"

Request if there was a pointer to the source code of overloaded '+' operator, in order to see how the bug appeared.

pan64 · 05-15-2024, 01:01 AM

Quote:

Originally Posted by ajiten

Request if there was a pointer to the source code of overloaded '+' operator, in order to see how the bug appeared.

it is not a bug, it is how it is implemented, designed. It is intentional. You need to check the python source code yourself if you want to go into details. Do not request again python internals.

sundialsvcs · 05-15-2024, 04:29 PM

@pan64: All I am saying is that “different popular programming language [designers …] might do things very differently. So, a source-code statement that you have written before … in a different world … might now behave differently here. But, “no syntax errors!”

I particularly encountered this issue because I took on “existing [legacy?] software,” in whatever language it might be [have been]. (It isn’t pretty …) Many languages do things like “overloading operators,” but they do it in an interpreter context and the meaning is not always what you(!) “intuitively” expect it to be.

dugan · 05-15-2024, 05:00 PM

Quote:

Originally Posted by ajiten

Request if there was a pointer to the source code of overloaded '+' operator, in order to see how the bug appeared.

You don’t need the source code. You have documentation.

https://python-reference.readthedocs...est/docs/list/

rclark · 05-15-2024, 06:21 PM

Yep. Not a bug. Just the way it works. Reference the List document above for working with 'lists'.

pan64 · 05-16-2024, 02:25 AM

Quote:

Originally Posted by sundialsvcs

@pan64: All I am saying is that “different popular programming language [designers …] might do things very differently. So, a source-code statement that you have written before … in a different world … might now behave differently here. But, “no syntax errors!”

I particularly encountered this issue because I took on “existing [legacy?] software,” in whatever language it might be [have been]. (It isn’t pretty …) Many languages do things like “overloading operators,” but they do it in an interpreter context and the meaning is not always what you(!) “intuitively” expect it to be.

Yes, I know that. It is called: do not assume anything (but read the documentation).

EdGr · 05-16-2024, 06:16 AM

Operator overloading is a bad feature, IMO. The available operators are few in number compared to methods. When reading code that uses overloading, one can never be sure what "a+b" does.
Ed

pan64 · 05-16-2024, 07:15 AM

Quote:

Originally Posted by EdGr

Operator overloading is a bad feature, IMO. The available operators are few in number compared to methods. When reading code that uses overloading, one can never be sure what "a+b" does.
Ed

Not really. As any other thing in this world it can be used properly and can be abused. The other wisdom is: (do not assume anything, but) learn the tool you use otherwise it won't work.

NevemTeve · 05-16-2024, 07:22 AM

Off: which one is the right usage of the += operator:

Code:

birthday += 3;         /* 3 days, probably */
rocketLaunchTime += 3; /* 3 hours or 3 sec? */

dugan · 05-16-2024, 10:32 AM

The only thing I see wrong with the above code sample is that birthday should probably be const.