[Tutor] Zipfile and File manipulation questions.
Jonathon Sisson
sisson.j at gmail.com
Tue Oct 17 01:14:55 CEST 2006
Yes, I read your code, as well as this entire thread. All I'm saying is
that:
#1) I'm not complaining about your naming conventions.
#2) It would be easier *on you* in the long run if you use more concise
names.
#3) Code how you are comfortable coding...just don't expect "aFile" to
fly in a team setting.
I'm not trying to run you down or "bare my fangs" for bad naming
conventions, seriously, I'm not. This list's intent is to help, and
Kent, Luke, myself, and a whole slew of other programmers have made
suggestions that you simply cast aside. (Again, it is *your* decision,
but don't expect any of us to be much help if we can't read your code
and go "oh, that's what he's trying to do there" without serious
effort). None of us are getting paid to figure out what your code does,
then formulate an answer and post it to this list. We do that because
we're trying to help.
I apologise if the tone of my last post was misunderstood, Chris. I'm
not trying to be "Mr. Enforcer" here or nothing (I'd rather think I'm
far from capable), but don't take constructive criticism wrong.
I'm glad you got the code working. Congrats.
Jonathon
Chris Hengge wrote:
> Have you even read my code to see if you find it cryptic? I'm starting
> to beleive people just read the one comment on possibly using better
> naming conventions and assumed I had picked completely irrelivent names.
>
> On 10/16/06, *Jonathon Sisson* <sisson.j at gmail.com
> <mailto:sisson.j at gmail.com>> wrote:
>
> Chris Hengge wrote:
> > I chose the way I used the names because to me...
> >
> > outFile = open(aFile.lower(), 'w') # Open output buffer for writing.
> > = open a file with lowercase name for writing.
> > it is implied that aFile is from the zip, since it is created in the
> > loop to read the zip..
> >
> > outFile.write(zFile.read(insideZip)) # Write the file.
> > = write what is read from inside the zip file.
> >
> > I guess for declaration it isn't very clear, but thats what
> comments are
> > for?
> > My naming was purely for my ease of mind.. I personally care less
> about
> > what I call it when I declare, as to how it logically flows when
> I go to
> > use it. I'm sure this is considered poor method, but once I declare a
> > method I tend to never need to change the declaration, just how I use
> > the info... I hope that makes sense.
> >
>
> Even if you're the only person that EVER lays eyes on that code (and
> you
> inherited Perl code, so I assume someone will eventually take this code
> over) it's vital to use names that are clear and concise. If you
> disagree, put your code away in a locked box, then re-read it after six
> months and see if it makes perfect sense.
>
> As Kent said, this is quite a minor issue that shouldn't be paraded, but
> I have been on the receiving end of code such as:
>
>
> int a;
>
> if (a == 0)
> {
> /* do something interesting */
> }
> else
> {
> /* do something less interesting */
> }
>
> (Sorry for the Java-ish flair...Java happens to be on my mind at the
> moment...)
>
> Even if I was there when the code was written, how could I know what
> "a"
> means a month later without digging back through to see how it's used?
> (and worse, "a" was used for conditional testing in this specific
> example (i.e. on/off conditions), so a boolean would have done MUCH
> better). Commenting can only help so much...the code must speak for
> itself at some point. (Yes, I know this is an extreme example, but it
> happens all the time).
>
> Something like this is much more readable:
>
>
> boolean fileExists;
>
> if (fileExists)
> {
> /* do something interesting */
> }
> else
> {
> /* do something less interesting */
> }
>
>
> I'm not complaining, because afterall it's up to you to write the code
> you're comfortable with (because you're not working on a team, that is),
> but a friendly suggestion on naming conventions (especially when you can
> refactor in most IDE's today) could go a long ways to helping you build
> readable code that is easier to maintain.
>
> Jonathon
>
>
> > On 10/16/06, *Kent Johnson* <kent37 at tds.net
> <mailto:kent37 at tds.net> <mailto:kent37 at tds.net
> <mailto:kent37 at tds.net> >> wrote:
> >
> > Chris Hengge wrote:
> > > Here is my solution, completed with (I think) all your
> suggestions...
> > >
> > >
> >
> #########################################################################
>
> > > def extractZip(filePathName):
> > > """
> > > This method recieves the zip file name for decompression,
> > placing the
> > > contents of the zip file appropriately.
> > > """
> > > if filePathName == "":
> > > print "No file provided...\n"
> > > else:
> > > try: # Attempt to unzip file.
> > > zFile =
> zipfile.ZipFile(filePathName.strip('"'), "r")
> > > for aFile in zFile.namelist(): # For every file in
> > the zip.
> > > # If the file ends with a needed extension,
> > extract it.
> > > for ext in ['.cap', '.hex', '.fru',
> '.cfg', '.sdr']:
> > > if aFile.lower().endswith(ext):
> > > insideZip = aFile # Copy of Filename.
> > > if "/" in aFile: # Split the
> filename if '/'.
> > > aFile = aFile.rsplit('/', 1)[-1]
> > > elif "\\" in aFile: # Split the
> filename
> > if '\'.
> > > aFile = aFile.rsplit('\\',
> > > 1)[-1]
> > > outfile = open( aFile.lower(),
> 'w') # Open
> > > output buffer for writing.
> > > outfile.write(zFile.read(insideZip)) #
> > Write the
> > > file.
> > > outfile.close() # Close the output
> file
> > buffer.
> > > print "Resource extraction completed
> successfully!\n"
> > > except IOerror, message: # If file creation fails, let
> > the user
> > > know.
> > > print "File could not be written: \n"
> > > print message
> > >
> > >
> >
> #########################################################################
>
> > > Definatly an improvement! Thanks Kent.
> >
> > Yes, that is what I meant. One minor quibble, I think I would
> keep
> > aFile
> > as the name in the zip, since that is what it starts as,
> and use a new
> > name for the external file name. Maybe you could use better
> names, for
> > example zipPath and fileName. I think that would make the
> code a little
> > clearer but it is a very minor point.
> >
> > Kent
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Tutor maillist - Tutor at python.org <mailto:Tutor at python.org>
> > http://mail.python.org/mailman/listinfo/tutor
>
>
More information about the Tutor
mailing list