It is Good that you have the book because i have a few questions concerning
the books again. This book by M. Zelle is getting really difficult shortly
after that section (also as i see the examples are getting fewer) but it was
easy till that part, so the question is: is it to me or is the rest of the
book indeed explained not well(not like the beginning parts)?. Having heard
the recommendations on books for beginners i have ordered the book "Core
Python Programming" by Wesley Chun, so comparing those two books which one
is more suitable (recommended) for a beginner to both python and
programming?
Here in our local library, the first edition of "Core python programming"
is available so i guess i will use it till I receive the second edition, but
i think it might take like a month, if not more till it gets to where i
live. Is there much difference between the first and second editions? And
also one more book, i haven't ordered it yet, is the "Python from novice to
professional" by Magnus Lie Hetland, is it worth ordering and studying for a
complete noob?
thanks for your answers.
On 8/13/07, Kent Johnson <[EMAIL PROTECTED]> wrote:
>
> bhaaluu wrote:
>
> > The original poster posted a post with the following function:
> > def dec():
> > import string
> > message=raw_input("Enter the message to decode: ")
> > result=''
> > for x in string.split(message):
> > result=result+chr(eval(x))
> > return result
> >
> > print dec()
> > which is from the book:
> > "Python programming: An introduction to CS" by John M. Zelle.
> >
> > As a Python Noob, I'm obviously ignorant of most of the Python
> > language, but I wonder why the author of a book would include
> > a function that is a "gaping security hole," when the int() function
> > would do the job just as nicely, and without the security concerns?
>
> I can't answer for Mr Zelle. Looking at the book, he introduces int(),
> float() and long() shortly after the section containing the above example.
> >
> > Of course, I don't know what context the snippet is in because I
> > don't have a copy of the book in question. But as a Python Noob,
> > I really do appreciate your heads-up about eval(), and I have it
> > red-flagged as a 'gaping security' concern, and will use it with
> > extreme caution in the future. =)
>
> Good. There is almost always a better way to accomplish a task than to
> use eval().
>
> > Now for MY question: Besides eval(), are there other functions that
> > should be 'red-flagged' as well? I just haven't been around Python
> > long enough yet to become familiar with all of the Standard Library.
> > Correct me if I'm wrong, but with 29 keywords, and over 176 library
> > functions, Python weighs-in at over 200 Standard "objects"?
>
> Anything where user input is executed as code is a security hole and
> should never be opened to untrusted users.
> eval()
> exec
> execfile()
>
> come to mind.
>
> Kent
> _______________________________________________
> Tutor maillist - Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor
>
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
