ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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)
-----------------------------------------------------------------------------------------------------
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?
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.
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.'"
Last edited by sundialsvcs; 05-14-2024 at 07:32 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.'"
Request if there was a pointer to the source code of overloaded '+' operator, in order to see how the bug appeared.
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.
@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.
Last edited by sundialsvcs; 05-15-2024 at 04:30 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.
Yes, I know that. It is called: do not assume anything (but read the documentation).
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.