Is it possible to set the date/time of a directory in windows with Python? If so how?
I'm trying to set any of the dates (create, modification, access) of a directory under windows with python. I'm trying to do this as I'm trying to write a unittest for a directory cleaning script I'm writing (ie I need the test to set the create/mod time for some of the directories so that I can be sure that the script works properly - as it picks dirs based upon their age). I've tried using the utime( path, times). That doesn't work as the doco states Whether a directory can be given for path depends on whether the operating system implements directories as files (for example, Windows does not). So that doesn't work. So I tried mark hammonds win32 extensions with something like this import win32file, win32con, pywintypes filehandle = win32file.CreateFile(file, win32file.GENERIC_WRITE,win32file.FILE_SHARE_WRITE, None,win32con.OPEN_ALWAYS, 0, None) nowWin32=pywintypes.Time(theTime) win32file.SetFileTime(filehandle, nowWin32, nowWin32, nowWin32) which works fine for files but fails with Access Denied when I invoke the CreateFile with a directory. This seems to occur no matter the combination of READ or WRITE I choose for the parameters. So does anyone have any useful suggestions (other than not using windows)? I've thought of a couple of reallly nasty solutions: 1. Temporarily alter the underlying system clock back to the required time and create the directory then resetting it back again afterwards. 2. Create the required directory in some form of virtual filesystem - eg Zip file, rar archive, tar etc. Then extract it to the real filesystem and hope windows honors the timestamps (untested at this point). None of those is particularly appealing. Thanks for listening. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to set the date/time of a directory in windows with Python? If so how?
Thanks very much for that roger :-) I changed my code to filehandle = win32file.CreateFile(file, win32file.GENERIC_WRITE, win32file.FILE_SHARE_WRITE, None, win32con.OPEN_ALWAYS, win32con.FILE_FLAG_BACKUP_SEMANTICS, None) nowWin32=pywintypes.Time(theTime) win32file.SetFileTime(filehandle, nowWin32, nowWin32, nowWin32) ie FILE_FLAG_BACKUP_SEMANTICS and everything works fine Just for the sake of completeness ... I'd just thought of another solution ... to have python determine the modification date for the directory based upon the oldest contained file (I'm guessing windows does the opposite - ie the newest file mod) to give me the effect of having a directory with an older date. The virtual file system idea didn't work either ... files had the correct dates but the dirs didn't as doing the extraction with python libs is subject to the same constraints ... and I didn't think that altering the ZipInfo time entries would have any affect as they appear to only represent files and not directories. I could have spawned a command line to do the extraction but I lost interest at that point. thanks again -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for resources for making the jump from Java to Python easier and more productive
Thanks for those ... just by looking at the colour of the links in my browser I'd only found 4 of those already so I appreciate the heads up :- ) -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for resources for making the jump from Java to Python easier and more productive
I've actually managed to find some other links by backtracking through some of the links that you provided. The most comprehensive so far is this one http://www.razorvine.net/python/PythonForJavaProgrammers and a summary version (on the same site) http://www.razorvine.net/python/PythonComparedToJava The site owner (Irmen de Jong) appears to be be compiling a decent migration path from Java to Python on a Moin-Moin Wiki so perhaps he'll be harvesting more useful information from here and other places in the near future as the pages only appears a few days ago. There was also a follow up to http://naeblis.cx/rtomayko/2004/12/15/the-static-method-thing with http://naeblis.cx/rtomayko/2005/01/20/getters-setters-fuxors Hopefully this will prove helpful to some other folks :- ) I'm still working my way up to the practice sites (python and math challenge) ... I want to do a bit more reading first :- ) ciao thanks Todd -- http://mail.python.org/mailman/listinfo/python-list
Looking for resources for making the jump from Java to Python easier and more productive
I'm just starting out with python, after having a long history with Java. I was wondering if there were any resources or tips from anyone out there in Python-land that can help me make the transition as successfully as possible? Perhaps you've made the transition yourself or just have experience with folks who have made the transition. I'm looking for the common types of mistakes that say a Java/C# or even C++ developer may commonly make. More examples like those highlighted here http://dirtsimple.org/2004/12/python-is-not-java.html would be particularly useful. I've already made the static class method mistake, and been thoroughly confused by packages and imports/froms and extremely frustrated with attempting to call super constructors etc. I'm getting the hang of passing around functions (ala the command pattern), customising the operators and extending inbuilt classes. All of these concepts I've done before so there nothing really great and wonderful about using them in another language. Some of the really powerful ideas of python (eg as suggested in the link) about creating one function containing a template function that can cater to all possible implementations sounds really cool and alien to me at the same time. That's the sort of stuff I'm interested in. At this point in time I'd say my python code is more coding Java in python than doing it in a pythonic way. Perhaps there some good/great examples of Python scripts or projects that I could look at to get inspired or learn pythonic implementation ideas? I just don't know of any. Are there python specific equivalents to the common Patterns, Anti-Patterns and Refactoring books that are so prevalent as reccomended reading in C++ and Java? If so what? Given the rising popularity of Python these days there has got to be a few of you out there who've made the transition successfully and have some pearls-of-wisdom to share that you'd wished you'd known about earlier. Thanks Todd -- http://mail.python.org/mailman/listinfo/python-list
Re: How should multiple (related) projects be arranged (structured) and configured so that they can share code, have a related package structure and enable proper unittesting, and ensuring no namespac
Thanks everyone for their assistance. I have managed to achieve all that I set out to do: - separation between src and test folders - now successfully sharing code between projects - running unittest s and suites - avoiding namespace collisions The solution involved the following (if anyone else is interested) - ammending all my __init__.py packages so that they included the following: from pkgutil import extend_path __path__ = extend_path(__path__, __name__) as per Peter Otten's suggestion - refactoring all the code so that the imports and froms conformed to the new package structure (a.b.c.common, a.b.c.app1 etc) and physically moving all the required files - ammending the PYTHONPATH so that the src and test directories for each project is included at the time of running ie PYTHONPATH=COMMON/src;COMMON/test;APP1/src;APP1/test;APP2/src;APP2/test Of course the /test entries are only required for testing and not runtime but you get the idea. I understand that flatter package structures are apparently the python way (http://dirtsimple.org/2004/12/python-is-not-java.html) but I like a nice little small little related package of functionality when I am l carving up a complex problem so I'm happy to incur any extra performance penalty in dict lookups. thanks again Todd -- http://mail.python.org/mailman/listinfo/python-list
How should multiple (related) projects be arranged (structured) and configured so that they can share code, have a related package structure and enable proper unittesting, and ensuring no namespace co
Summary: How should multiple (related) projects be arranged (structured) and configured so that the following is possible: o Sharing common code (one of the projects would be a common project referenced by all others and likely the others would share at least the common project and possibly more as times goes on) o Clear separation of production code and test code (ie to readily ship source and test as separate components. Usually I'd do that with separate hierarchies (src vs test folders) o Enabling the running of individual unittests and aggregated testsuites o Avoiding namespace collisions - whilst still ensuring commonality (or ownership) of the projects (ie common base package) The longer version is detailed below which outlines my specific problem. I was hoping that someone could help me out with my python programming dilemma.I am having a huge problem organising my python projects so that the imports and from s to work correctly. I'm a Java/J2EE developer by trade so I have a reasonable grasp of the fundamentals regarding computer programming in general, but obviously not-so-good in python. I have noted from my reading on the web that my Java skills may actually be more of a hinderance - so feel free to tell me if I am making any programming java in python mistakes. I'm working on a few projects concurrently so I have tried to arranged my projects like this: COMMON src a.b.c.common test a.b.c.common APP1 src a.b.c.app1 test a.b.c.app1 APP2 src a.b.c.app2 test a.b.c.app2 But it has not worked due to import/from issues. It appears that using a common base package hierarchy (as is standard practice in the java world) caused issues. Ie not able to use a.b.c as the base package for all my projects, in order to avoid namespace collisions. I attempted to resolve this by altering the packages to make the project name as the base package. Ie the new packages were · common.a.b.c.common · app1.a.b.c.app1 · app2.a.b.c.app2 My final problem is that I am not able to run my tests (unittest) as I can't seem to find the right imports or froms to use that will work for both from an aggregate (suite) test and the individual tests. I have an individual AllTests.py at the root of the test folder and all the appropriate __init__.pys in all the folders (to make them package loaders). It appears to be that the directory from which the AllTests.py is run is subverting the path/package hierarchy as it is loaded first and is conflicting with my PYTHONPATH env variables (or I am getting the python packaging and path totally wrong - which is entirely possible). So how should a project to be structured and configured to enable all of these requirements? Any special requirements for the __init__.py, PYTHONPATH, or other configuration tricks? Thanks Todd -- http://mail.python.org/mailman/listinfo/python-list
Re: How should multiple (related) projects be arranged (structured) and configured so that they can share code, have a related package structure and enable proper unittesting, and ensuring no namespac
Thanks for all the prompt helpful responses :- ) I have read and reread section 6.4 - of the python docs and it doesn't really help me. Just a couple of clarifications. I am already using a VCS (Version Control System) - subversion actually. When I mentioned a clear separation of production and test code I was more referring to this sort of arrangement: src a.b.c.common a.b.c.common.test which I believe is bad versus the clearer physical separation test a.b.c.commom.test The first option has the testing code within the same folder hierarchy which makes it harder to separate the two physically at release time without writing some complicated scripts to selectively exclude items. In the Java world the second option is the standard, and my preference if it's possible. I suspect that some of my import / from problems stem from the fact that I want to use a standard base package for all my projects to avoid namespace issues. ie all my projects use packages of the form a.b.c.projectName where a.b.c is my namespace (dns address actually) a.b.c.common a.b.c.project1 a.b.c.project2 Is this not the way python projects should be packaged? Is there a problem with having a common base package name like this? ie does the first instance of the package a.b.c effectively mask out the others so that if a.b.c.common occurs first in the PYTHONPATH then a.b.c.project1 will never be found as the a.b.c package is only loaded from the a.b.c.common folder? Does anyone else have any issues with running a master test suite and indvidual tests. It seems that if I set up the imports/froms for the master testsuite then I can't run the tests individuallly and vice versa ... unless I remove all packages and have a single flat directory. There has got to be big projects written in python that need to separate out their testing code according to some logical grouping. thanks Todd -- http://mail.python.org/mailman/listinfo/python-list
