On Tue, Sep 04, 2012 at 11:57:48AM +1000, Garry Willgoose wrote: > I want to put a shortcut onto the desktop in windows (XP and later) in > Python 2.6 or later. In Unix its easy using os.symlink but I can't > find anything equivalent for windows. My searches on the web led me to > the code below but the code returns the error > > AttributeError: function 'CreateSymbolicLinkW' not found
If you expect us to actually debug the error, you need to give the right debugging information. That means you have to show the FULL traceback printed, not just the final error message without any context. Do not retype the error from memory, or summarise it, do a copy and paste of the entire traceback, starting with the line Traceback (most recent call last): all the way to the end. And then make sure that the code you are giving us is the same as the code you are running. I say this because I believe that the code you sent us is not the code you are running. I cannot see any possible way for the code you gave to raise AttributeError. But in this case, I recommend against using ctypes. Here are some better ways to manage Windows shortcuts: http://www.blog.pythonlibrary.org/2010/01/23/using-python-to-create-shortcuts/ http://mail.python.org/pipermail/python-win32/2003-March/000862.html > __CSL = None > > def create_alias(source, linkname): > """ > Each operating system has a different way of creating an alias. > This is the windows version > """ That's technically incorrect. *Alias* (MacOS), *shortcut* (Windows) and *symlink* (Linux, Unix, MacOS, and others) are all slightly different things, although they all solve more-or-less the same problem. In principle you could have a single OS offer all three. MacOS offers both aliases and symlinks. (And even more pedantically: it isn't the *operating system* which matters, but the file system. So Windows with a Linux file system could have symlinks.) > import os > try: [...] > except: > print('#### Error creating a file alias from '+str(source)+' to > '+str(linkname)) Please never, ever, ever do that. Every time somebody writes an except block that catches everything like that, god kills a kitten. Catch-all exceptions like that are one of the worst bad-ideas in Python ever. The problems include: * They catch too much -- not only do they catch legitimate errors that should be caught, but they catch non-errors like KeyboardInterrupt which *don't* indicate an error. * They mask programming bugs -- because they catch too much, they hide programming bugs which should be exposed with a traceback so that you can fix them. * They give you no way to access the exception caught. * They tempt beginners into thinking that they have to *hide problems* by catching the exception and just printing a message, instead of *fixing problems* so no exception happens in the first place. There are exceptions (pun not intended) to the rule "never use a bare except", but they're rare. In general, a try...except block should: * always explicitly state the exception(s) you want to catch; * cover only the minimum amount of code necessary. > return() That line is wrong -- it returns an empty tuple (). To return nothing, just say "return" on its own, or better still, don't say anything and the function will return nothing when it is finished. (To be precise: it will return the None object.) -- Steven _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
