Suggestions for good programming practices?

[Carl Banks]

brueckd at tbye.com wrote:
> On 25 Jun 2002, Donn Cave wrote:
> 
>> | So... rather than teaching "avoid W!", let's say "be careful with W 
>> | because of X, Y, and Z". I still wouldn't use eval/exec on code posted 
>> | through a web form, for example, but there are times when they are very 
>> | useful and I can use them in good confidence because I understand their 
>> | risks.
>> 
>> But you weren't going to be deterred by that pronouncement anyway.
>> 
>> "Avoid exec, execfile, eval, and input" is good advice.  Taken at face
>> value, it doesn't necessarily absolutely prohibit their use - if I said
>> "avoid walking in the road", you could reasonably reasonably assume I'm
>> saying something like "walk on the sidewalk when possible".
> 
> If you mean the latter, say the latter. Neither newbies nor veterans have 
> to do any reading between the lines. Even better, say "walk on the 
> sidewalk when possible because ___".

Fair enough.

* Avoid using exec, execfile, eval, and input unless you are
  deliberately asking your user to supply Python code, and take
  serious precautions if the program is running at a higher privledge
  level than the user.  All other uses of them should be thoroughly
  thought out, and the implications understood.


>> Someone whose software engineering skills have been honed by years
>> of wrestling with ugly code monsters will apply a different perspective
>> to that advice.  A 1-week newbie could do worse than to follow that
>> advice religiously.
> 
> I understand your point, but the OP is new to Python, not programming.  
> This isn't a big deal; I was simply pointing out that just saying "don't
> use those!" (Why? Are they broken? Deprecated? What?) isn't as helpful as
> explaining the risks.
> 
> In the specific case of exec/eval, people are quick to strike them down,
> often citing the untrusted input example (what about os.system, .fork,
> etc.?), but that's a pretty narrow and uncommon usage scenario.

I completely disagree.  I've seen at least two potentially
security-compromizing uses of eval posted here in the last few days as
"good" ways to do something.

I imagine most people see eval and think, "what a cool, easy way to
turn a string into a list!" without stopping to consider that it could
also turn a string into a syntax error, or an object that erases your
whole filesystem when its __getitem__ method is called.


> When I
> first learned Python I used them in some of the "forbidden" ways because I
> hadn't learned getattr/setattr yet. So what? My programs worked fine (a
> little slow) and later I learned better ways and now use those instead.

You were lucky that your forbidden uses of eval and exec weren't
dangerous in that case.  (Or maybe you weren't lucky but were already
aware that eval could be dangerous, but that's not the case for all
newbies.)


> If a person is new to programming altogether then what kind of a teacher
> will draw attention to exec/eval in the first place anyway?

A good one.  Realizing that one does not need to call attention to
eval for a newbie to find it, a good teacher explains that it is
dangerous before the newbie has a chance to hurt himself with it.


> Besides, the
> people who understand the potential for problems with something tend to be
> the ones that don't mishandle it (whether it be streets, guns, or Python
> functions).

Which is why it is important to tell people who don't understand the
potential for problems to not use eval until they do.

You seem to have this idea, based on this last paragraph, that a good
way to keep newbies from misusing eval and exec is to keep them in
ignorance.  I think that's absurd.  I don't know if you're just
grasping for arguments, because you previously seemed to think it's
best to explain WHY, as opposed to simply saying, "Don't do it."


-- 
CARL BANKS                                http://www.aerojockey.com
"Nullum mihi placet tamquam provocatio magna.  Hoc ex eis non est."