http://www.otg-nc.com/python-bootcamp
It's a week long Python Bootcamp. I figured, free class, a week where
I'll not have to actually go to work, AND I'll get paid, sure!
So I was just wondering if any of you have attended this one, or one
like it, and what your impressions were. I've attended a few before,
and found them widely different. The RH300, for example, was
blisteringly fast and really just touches on things, so if you don't
already know Red Hat inside and out, you'll never survive. The VMWare
VCP courses, on the other hand, were fairly languid by contrast and
seemed to flow in a less frantic state.
So I figured this would be the place to ask.
And if it matters, I do have an educational background in programming
(VB, C++, C, Java, etc) but my professional background has mostly been
limited to Bash, OCCASIONAL C, and now a touch of Python, so I am not
new to programming and OO programming, just not as proficient as I
would like to be...
Cheers
Jeff
--
Jonathan Swift - "May you live every day of your life." -
http://www.brainyquote.com/quotes/authors/j/jonathan_swift.html
No opinion, but just wanted to note that this is completely ON-topic for
comp.lang.python.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
The best way to get information on Usenet is not to ask a question, but
to post the wrong information.
I'm surprised they're able to fill out 5 days with intensive training
on Python.
:)
Carl Banks
Well, if it's anything like other similar courses I've taken over the
years, the 10 minute break ever 2 hours will be more like 20 minutes,
the hour lunch more like 1.5 hours, and the 8:30 to 4:00 times will be
more like 8:45 to 3:15
;)
but on a serious note, your comment was why I was asking... I was
trying to figure out just how much python you could teach in an
assumed 40 hours... but it's also supposed to be probably 80%
(arbitrary semi-educated guess) hands on coding, and if that's the
case, each 30 minute project could well be 45 minutes to an hour
depending on how fast people type, how familiar they are with actually
properly formatting code, etc...
--
Pablo Picasso - "Computers are useless. They can only give you
answers." - http://www.brainyquote.com/quotes/authors/p/pablo_picasso.html
I have never been, but it seems like a no-brainer to attend. Even if
the class totally sucks, which I doubt, you will also have the
opportunity to network with people with similar interests.
If your ONLY objective in life was to learn Python, then I would
recommend just hitting the books.
There are a couple of ways you can get benefit out of this even if the
class itself isn't that useful for you:
* Spend time working on Python projects from your job without the
pressure of being at work
* Help the other people in the class learn Python, which will cement your
knowledge
The list of topics seems to cover basic + intermediate issues.
If you do go, perhaps you could review it here.
Same for people who have attended other Python training courses, of course.
> The list of topics seems to cover basic + intermediate issues.
> If you do go, perhaps you could review it here.
> Same for people who have attended other Python training courses, of course.
The last day is tomorrow, so I'll actually try and write something
real then... I just wanted to say that this has been a pretty good
class. Really good, compared to others I've taken (in college and so
forth)...
Anyway, just thought I'd share this:
The difference between me (learning a new language) and the guy
teaching (who knows it inside and out)
My code:
import os
startDir = '/home/student/testdirectory' #raw_input("Enter starting location: ")
searchList=['html','py','jpg']
filenames=[]
report={}
try:
fhtml=open('HTMLFiles','w')
fpy=open('PYFiles','w')
fjpg=open('JPGFiles','w')
except:
assert 0, 'Unable to open file'
for root, dirs, files in os.walk(startDir):
filenames += [os.path.normcase(os.path.join(root,f))
for f in files if f[f.rfind('.')+1:] in searchList]
for file in filenames:
ext=file.split('.')[1]
if report.has_key(ext):
report[ext].extend([file])
else:
report.update({ext:[file]})
for k,v in report.iteritems():
if k == 'html':
for item in v:
fhtml.write("%s\n" % item)
if k == 'py':
for item in v:
fpy.write("%s\n" % item)
if k == 'jpg':
for item in v:
fjpg.write("%s\n" % item)
His code:
import os
def FindFiles(base_dir="/", exten=[]):
results={}
# Initialize results dictionary with blank arrays
for l in exten:
results[l]=[]
for root, dirs, files in os.walk(base_dir):
for e in exten:
results[e] += [os.path.join(root,fn) for fn in files if
fn.endswith(e)]
return results
files=FindFiles('C:/Python26',['exe','html'])
for (exten, list) in files.iteritems():
try:
f=open('extensions-%s.txt' % exten,'w')
f.write('\n'.join(list))
except:
assert 0, 'Unable to create output file extensions-%s.txt.' % exten
Different thought processes, plus experience makes a difference too...
That and while I have an educational background in programming, the
only programming I've been able to do in my professional (read daily)
life is BASH... I think it shows.
Cheers,
Jeff
--
Ted Turner - "Sports is like a war without the killing." -
http://www.brainyquote.com/quotes/authors/t/ted_turner.html
> The difference between me (learning a new language) and the guy teaching
> (who knows it inside and out)
I don't know about that. He's teaching some pretty atrocious habits. See
below.
> His code:
[...]
> for (exten, list) in files.iteritems():
> try:
> f=open('extensions-%s.txt' % exten,'w')
> f.write('\n'.join(list))
> except:
> assert 0, 'Unable to create output file extensions-%s.txt.' %
> exten
Wrong! Bad! Don't do this!!!
There are no less than five errors here. Some people might argue that
given the context (a short script), none of them matter in practice. For
a script you use once then throw away, maybe. I've written sloppy scripts
myself, and lazy can be a virtue. But *teaching* sloppy is a terrible
thing -- even if you disagree that this are the sorts of errors that
matter in this script, they are bad, bad habits that you should avoid.
Error #1: Bare excepts are nearly always wrong. Bare excepts catch
*everything*, including exceptions caused by bugs in your code. Including
the user trying to interrupt the code with ctrl-D. Don't use bare excepts
unless you know what you're doing. Catch the specific exceptions you
actually want instead.
Error #2: Wrapping multiple operations in a single try block. This
conflates errors in four different operations:
generate the file name
open the file
merge strings into a single newline-delimited string
write the strings to the file
The instructor assumes that only the open can fail. That's incorrect. His
try...except will mask coding errors, as well as conflating open errors
and write errors.
Error #3: Throwing away useful debugging information and replacing it
with a generic error message that isn't useful.
If an error occurs, Python will generate a useful exception telling
exactly what error occurred and why. If it happens in a file operation,
it will include the error code. The given code throws that away and
replaces it with a generic error that tells you nothing except that an
assertion failed.
Error #4: Using assert for anything other than what it was designed for.
If you want to break this script, run it with optimizations switched on
and trigger a failure-mode (perhaps by removing write-permission from the
current directory). With optimizations switched on, the assert statement
will be compiled away, and the script will catch the open errors and
ignore them.
Error #5: Failing to close each file after you're done with it. Python
does close files for you, if you don't do it yourself, but when it does
so is implementation dependent. Some versions of Python won't close them
until the very end of the program, as it closes down. That means that if
the list of files is large enough, you will run out of file descriptors
and the program will stop working.
How would I re-write this? Just get rid of the try block and add a close:
for (exten, list) in files.iteritems():
f=open('extensions-%s.txt' % exten,'w')
f.write('\n'.join(list))
f.close()
If an error occurs, Python's normal exception-raising mechanism will halt
the script and print a useful error message.
If you want to mask the traceback from the user (but I'm not sure why you
would want to...) then wrap the entire loop in a single try, catching
keyboard interrupt separately:
try:
for (exten, list) in files.iteritems():
f=open('extensions-%s.txt' % exten,'w')
f.write('\n'.join(list))
f.close()
except KeyboardInterrupt:
print "Interrupted by user."
raise
except Exception:
raise ValueError('failed for some unspecified reason')
That's still not quite "best practice" -- best practice would be to use a
with block, but (to my shame) I'm not entirely familiar with that so I'll
leave it for others.
--
Steven
Ok... I snipped it because I don't know enough really to comment on
any one thing...
I supposed in his defense, I could say that the point of the exercise
had nothing to do with exception handling, and the part that DID
handle exceptions covered a good bit on actually catching individual
exceptions for various things, as well as doing things like writing
extensions to handle things.
Also, consider that this is a "boot camp" that's geared toward getting
you up to speed and writing functional code as quickly as possible.
One week has gone from "This is a string variable and you can iterate
it" to This is file operation, OS and SYS usage, exception handling,
etc... really, just in 4 days. The last day, I think just covers
database access and operations and a brief overview of python web
development and the cgi module.
It's more an intense introduction for people who already know how to
write code (not necessarily, though, ones who know how to write it
properly) than it is a formal "This is how you write code the right
way".
I'm not necessarily trying to make excuses, but, that's my take on it.
All I wanted to get out of it was familiarity with Python, a refresh
of OOP practices, and the ability to get REALLY started on some
projects quickly, making the code pretty and better afterwards...
Thankfully, I've got places like comp.lang.python and various books
and online references to help me take what I know and make it better,
but as a starting point, at least, it's not terrible.
Now, that all being said... how atrocious was my OWN code sample.
I'm a firm believer in constructive criticism, so I'd like to know how
I'm doing so far. I can provide other samples if necessary, because I
DO want to learn to write this cleanly and properly.
Keep in mind that while I DO know how to write programs, the only
thing I've really written in in 3 years now is BASH. It's been ages
since I did anything in any other languages to amount to anything, and
if I did, it was something quick and dirty that got the job done and
that was that, not something I'd really want to give to anyone else to
use... Hackery if you will...
"\n".join is a cute shortcut, but if you use it you must remember
to write the last, trailing '\n' manually.
> That's still not quite "best practice" -- best practice would
> be to use a with block, but (to my shame) I'm not entirely
> familiar with that so I'll leave it for others.
from __future__ import with_statement
# Etc.
for (exten, list) in files.iteritems():
with open('extensions-%s.txt' % exten,'w') as f:
f.write('\n'.join(list))
f.write('\n')
--
Neil Cerutti