Code Review
Hello all,
Please review the code pasted below. I am wondering what other ways
there are of performing the same tasks. This was typed using version
3.2. The script is designed to clean up a directory (FTP, Logs, etc.)
Basically you pass two arguments. The first argument is an number of
days old to delete. The second argument is the directory where the
files and folders should be deleted. I imagine one enhancement would
be to create a function out of some of this.
### BEGIN ###
import os
import time
import shutil
import argparse
CurrentTime = time.time()
epocDay = 86400 # seconds
parser = argparse.ArgumentParser(description = "Delete files and
folders in a directory N days old", add_help=False,
prog='directorycleaner', usage='%(prog)s 7 c:\\temp')
parser.add_argument('days', type=int, help="Numeric value: delete
files and folders older then N days")
parser.add_argument('directory', help="delete files and folders in
this directory")
parser.print_help()
args = parser.parse_args()
dictKeys = (vars(args))
HowManyDays = dictKeys['days']
WhatDirectory = dictKeys['directory']
print (HowManyDays)
print (WhatDirectory)
DaysToDelete = HowManyDays * epocDay
dirExists = os.path.exists(WhatDirectory)
if dirExists == False: print ("The directory is missing")
DirListing = os.listdir(WhatDirectory)
for files in DirListing:
# Get the absolute path of the file name
abspath = (os.path.join(WhatDirectory, files))
# Get the current creation time of the file in epoc format
(midnight 1/1/1970)
FileCreationTime = (os.path.getctime(abspath))
# time.ctime converts epoch to a normal date
#print (time.ctime(CurrentTime))
# Get the date from seven days ago
WeekOldFileDate = CurrentTime - DaysToDelete
#print (CurrentTime)
#print (FileCreationTime)
#print (WeekOldFileDate)
#If the file is older than seve days doe something
if FileCreationTime < WeekOldFileDate:
#check if the object is a file
if os.path.isfile(abspath): os.remove(abspath)
# It is not a file it is a directory
elif os.path.isdir(abspath): shutil.rmtree(abspath)
# END
--
http://mail.python.org/mailman/listinfo/python-list
Re: Code Review
On May 25, 4:06 am, Ulrich Eckhardt wrote: > ad wrote: > > Please review the code pasted below. I am wondering what other ways > > there are of performing the same tasks. > > On a unix system, you would call "find" with according arguments and then > handle the found files with "-exec rm ..." or something like that, but I see > you are on MS Windows. > > > args = parser.parse_args() > > > dictKeys = (vars(args)) > > The first of these looks okay, while I don't get the additional brackets in > the second one. Another habit I observe here is the Hungarian notation of > prefixing the type to the name and using camelCaps. PEP 8 (IIRC) has > something to say on the preferred naming. I'm not 100% against encoding the > type in the variable name in Python, since it lacks static type checking, I > would have chosen "key_dict" here though, or, due to the small size of the > overall program just "keys". > > > print (HowManyDays) > > This puzzled me at first, again the useless additional brackets I thought. > However, in Python 3, "print" is a function, so that is correct. Still, it > should be "print(foo)" not "print (foo)". > > > for files in DirListing: > > > # Get the absolute path of the file name > > abspath = (os.path.join(WhatDirectory, files)) > > "files" is just the name of a single file, right? In that case the name is a > bit confusing. > > > # Get the date from seven days ago > > WeekOldFileDate = CurrentTime - DaysToDelete > > You are repeating this calculation for every file in the loop. > > > if FileCreationTime < WeekOldFileDate: > > #check if the object is a file > > if os.path.isfile(abspath): os.remove(abspath) > > # It is not a file it is a directory > > elif os.path.isdir(abspath): shutil.rmtree(abspath) > > I'm not sure, but I believe you could use shutil.rmtree() for both files and > directories. In any case, be prepared for the file still being open or > otherwise read-only, i.e. for having to handle errors. > > Also, what if a directory is old but the content is new? Would this cause > the non-old content to be deleted? > > Cheers! > > Uli > > -- > Domino Laser GmbH > Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 Thank you guys very much for the excellent points. I will use this information as a reference as I write more code and fix up the existing script. Chris, thank you for putting so much time into your post! Until we type again... -- http://mail.python.org/mailman/listinfo/python-list
Re: Man Bites Python
On Apr 17, 11:11 pm, Aaron Brady wrote: > Man bites python. > Python bites dog. > Dog bites man. or just: man,python bites python,man No need for the temporary value in Python. -- Cheers Anton -- http://mail.python.org/mailman/listinfo/python-list
Re: IDLE: A cornicopia of mediocrity and obfuscation.
On Feb 2, 4:14 am, rantingrick wrote: > On Feb 1, 8:27 am, Jean-Michel Pichavant > wrote: > > > In a more serious way, just count the people who second your > > prosposition. It's around 0. It is usually a good sign that you're > > wrong. This rule kinda applies to anyone, don't take it personnaly. > > Well your statment completely ignores the silent majority. Are you > telling me that this sloth of trolls, minions, and flamers that have > so far replied are represetative of this fine community. As a member of this silent majority - we care less about IDLEs code quality than all the others that did actually care enough to even reply to you. Now stop your annoying trolling and either start working on your IDLE fork or shut up. Nobody else who agrees with you (there might be someone out there) has been ever been motivated enough to initiate this work by themselves, so unless YOU start it - it probably is never going to happen. Once it is underway you might attract some other people interested in helping to refactor or recode IDLE - but you won't know that unless you start work on it. But I think we all know exactly what you are actually going to keep doing though. -- Cheers Anton -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 7, 10:55 am, ant wrote: > My concern is simple: I think that Python is doomed to remain a minor > language unless we crack this problem. I'm curious why you think fragmented GUI choices is a particular problem for Python compared to other languages? Or why this is the main issue holding Python back? As far as I can tell, most of the other cross platform dynamic open source languages (eg Perl, Ruby, PHP, Javascript) face the same problem or don't even include a GUI toolkit. The one exception I can think of that has a non-fragmented native GUI option is Tcl (which being Tk is slightly ironic here), but it hasn't stopped Tcl being doomed to be a much more minor language than Python is. .NET/C# has had preferred GUI APIs come and go and isn't exactly what I'd call crossplatform, Java has had (and still does?) multiple toolkits, C/C++ never included any to begin with. Objective C has an obvious native GUI choice, but it's not at all crossplatform and is about as 'minor' a language as Python is anyway. Legacy VB and Delphi had built in GUIs but they weren't really cross platform and seem to be slipping out of relevance. Looking at the state of other languages and their GUI toolkit landscape, someone might even come to the conclusion that having one true GUI toolkit is potentially a bad thing for a language. I don't do any GUI coding so I don't have any toolkit preferences myself, but I think the only sane way to address your concerns is to incrementally improve Tkinter. Coming up with a new toolkit from scratch is insanity, and switching the toolkit to something else doesn't actually help much (ie you don't think any are currently suitable anyway) and is just as likely to annoy other people. -- Cheers Anton -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 14, 2:34 am, Stephen Hansen wrote:
> HTML+CSS have some very strong advantages. Simplicity is not one of
> them. Precision web design these days is a dark art. (Go center an image
> vertically and horizontally in an arbitrary sized field!)
I agree, and I know that's a rhetorical question, but here goes
(I have no idea whether this works in IE though)
div {
position: absolute;
border: 1px solid blue;
margin: 10px;
}
#one {
top: 50px;
width: 300px;
height: 300px;
}
#two {
top: 400px;
width: 200px;
height: 200px;
}
img {
position: absolute;
width:100px;
height: 100px;
margin: auto;
top: 0;
bottom: 0;
left: 0;
right: 0;
border: 1px solid red;
}
--
Cheers
Anton
--
http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 15, 11:59 am, Ed Keith wrote:
> But that is in a fixed size field,
That's why I used the same image definition in two different sized
divs to show that the images position wasn't determined by the divs
size.
> can you make the height change based on the height of the browser window, and
> still keep it centered?
Like this? The div is sized according to the browser window and
centered. The image is a fixed size, but still centered within the
div.
div {
position: absolute;
border: 1px solid blue;
margin: auto;
top: 10%;
bottom: 10%;
left: 10%;
right: 10%;
}
img {
position: absolute;
width:100px;
height: 100px;
margin: auto;
top: 0;
bottom: 0;
left: 0;
right: 0;
border: 1px solid red;
}
--
Cheers
Anton
--
http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 15, 12:06 pm, Stephen Hansen wrote:
> "Arbitrarily sized" was the key point ;-) In that, you set the sizes of
> the div's explicitly.
As I said to Ed, I think you missed why I included the exact same
image in two divs of different sizes. That was to show it was still
centered no matter what size the container was. It is even easier to
fit it to the browser window.
> I wasn't clear in my rhetorical question; the size
> is arbitrary because you have no control over it. You can do horizontal
> center easy; just set margin-left and margin-right to auto (and be sure
> to set display: block if you're not sure which mode you'll end up).
> Vertical centering outside of a table cell is a right pain in the ass.
>
> Like so: Create an HTML single image that sits dead in the center of
> your screen when your browser is maximized. Then if you adjust your
> browser to be half as wide, its still in the center. Just the new center.
Even easier than the first example:
(Yeah I know these are trivial and quickly get out of hand on a real
UI)
img {
position: absolute;
width:100px;
height: 100px;
margin: auto;
top: 0;
bottom: 0;
left: 0;
right: 0;
border: 1px solid red;
}
Anyway, wasn't this supposed to be about Python :)
--
Cheers
Anton
--
http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 15, 1:03 pm, Ed Keith wrote: > Nice! I've been looking for that trick for some time. > > Thank you, A lot of people (including pro web designers even) aren't really aware of what CSS can actually do. Part of the problem is that everyone only learnt the semi working subset that wouldn't fall to pieces in Internet Explorer. Don't get too excited though, while these proof of concept examples are easy once you put that into real world usage you'll notice that the absolutely positioned items are outside the normal flow and won't hold open containers - especially those that use a different positioning model etc. I reckon the main limitation with CSS is that it doesn't let you mix it's different positioning models together very easily. Now, back to talking about Python GUIs... :) -- Cheers Anton -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 15, 1:21 pm, pyt...@bdurham.com wrote: > Anton, > > Very nice. > > As an aside: I don't think you need to explicitly set your image size, Yeah, I only did that because I was assuming the image path would actually be broken (and it was for me too) - it was just to 'simulate' a 100x100 image :) -- Cheers Anton -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 15, 1:58 pm, Stephen Hansen wrote: > Very nice. And interesting. "position: absolute" there is a mystery to > me and seems to be key, I'm not sure entirely what it is doing to the > layout manager in that scenario, but it seems to do the trick. The Cliff Notes: position: absolute allows different combos/subsets of left,right,top,bottom,width,height to define where each edge is in relation to the edges of its closest parent that has also been positioned that way or the browser window if there is none. But it does take that element out of the normal flow (like a float does), which means all the statically positioned stuff won't interact with it at all - that can be enough to negate the usefulness of it all. position: relative is similar, but the edge offsets apply to where the element would normally have sat rather than the edges of an explicitly positioned parent element. > > Much, much, much Googling led me to try many things to get it just > right, and all bemoaned the lack of a solid way to vertically center: > all the while using essentially similar methods to horizontally center. I'd recommend the book "Pro CSS and HTML Design Patterns" from Apress for anyone who wants to get a more formal understanding of these different models etc. -- Cheers Anton -- http://mail.python.org/mailman/listinfo/python-list
Re: Python documentation too difficult for beginners
On Nov 3, 7:43 am, Tim Harig wrote: > On 2010-11-02, jk wrote: > > > As for the 9 paragraphs statement, there's a usability book that > > applies here - it's called "Don't make me think". I shouldn't have to > > Anything that promotes a lack of thinking sends up red flags in my head. > We want to recruit smart people who think, not idiots. "Don't make me think" is the UI equivalent of "There should be one and preferably only one obvious way to do it". Not about advocating no thinking, but about reducing the amount of unimportant decisions you require your users to make. But I don't think the book specifically addresses Dutch users though. Back on topic - I do like the Python docs overall. Especially compared to the PHP docs. I like the overall look and format of the new Sphinx generated ones too. My only criticism is that the content can sometimes be a little too terse/concise. It's fine for experienced developers, but in some places a little more explanation and/or examples would help out the less experienced. I can usually figure out how to do something eventually, but the docs for some modules take more deciphering than others. -- Cheers Anton -- http://mail.python.org/mailman/listinfo/python-list
zipfile handling
is there a rename utility for zipfile that can rename a directory inside a zipfile? also what's the best way to change the a file content inside a zip? So if i have the following file in the zip file: A/a1.txt A/a2.txt B/b1.txt I want to rename A to be A1, and B to be B1, as well as changing the content of a1.txt and b1.txt. I can certainly extract them to filesystem then rezip, but there might be a better way to do this? thanks. -- http://mail.python.org/mailman/listinfo/python-list
