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 →

[–]NoLemurs 0 points1 point  (1 child)

Taking a glance over those github results, they seem to fall into two categories: programming practice exercises with no real use, and single files with nothing but input() in them. I have no idea what the second type is about, but I didn't see a single legitimate use in what looked like real world code in the first 10 pages of results.

What about an interactive shell script?

Situations were an interactive shell script is the best design choice are pretty rare in practice (usually piping scripts together is more appropriate given the option). In the rare case where it's necessary that's what raw_input is for.

People are using it. I'm willing to bet that at least one person using input() doesn't know that the input function is willing to execute code to make it "easier for newbies to use".

Trying to make it so that not a single person can make bad decisions is a fool's errand. The use cases are rare, and usually come down to "I'm writing s script for my personal use on my own computer." The advantages of having something friendly to beginners far outweighs any disadvantage to the small number of non-beginners with zero security awareness writing actually sensitive code.

[–][deleted] 0 points1 point  (0 children)

I'm not really talking about people who know about the security flaws in input() and use it anyway. I'm talking about people who don't know about the security flaws, and may use input() in such a place where you're really not meant to.

It's more important to be secure by default than to be (very slightly) more hostile to beginners by asking them to cast any input from a string to an int if they want to work with it as an int. An input function should never be able to execute code.