on this fast tip, excerpted from useful python, stuart seems to be at methods to manage the home windows os with python.

the home windows registry

home windows is totally controllable from code utilizing the win32 api, and microsoft offers intensive documentation at microsoft docs for every little thing that home windows can programmatically do. all of that is accessible from python as properly, though it may possibly appear a bit impenetrable if we’re not already accustomed to the win32 api’s explicit means of working. fortuitously, there are numerous wrappers for these low-level apis to make code simpler to write down for python programmers.

a easy instance is to work together with the home windows registry. python really contains the winreg module for doing this out of the field, so no additional set up is required. for an instance, let’s examine the place the program information folder really lives:

>>> import winreg
>>> hive = winreg.connectregistry(none, winreg.hkey_local_machine)
>>> key = winreg.openkey(hive, r"softwaremicrosoftwindowscurrentversion")
>>> worth, kind = winreg.queryvalueex(key, "programfilesdir")
>>> worth
'c:program information'

uncooked strings

within the code above, we’re utilizing “uncooked strings” to specify the important thing identify:


strings handed to the win32 api usually embody the backslash character (), as a result of home windows makes use of it in file paths and registry paths to divide one listing from the subsequent.

nonetheless, python makes use of a backslash as an escape character to permit including particular, untypeable characters to a string. for instance, the python string "first linensecond line" is a string with a newline character in it, in order that the textual content is unfold over two strains. this may battle with the home windows path character: a file path similar to "c:newdirmyfile.txt" would have the n interpreted as a newline.

uncooked strings avert this: prefixing a python string with r removes the particular which means of a backslash, in order that r"c:newdirmyfile.txt" is interpreted as meant. we are able to see that backslashes are handled specifically by the worth we get again for the folder location: it’s printed as 'c:program information'—with the backslash doubled to take away its particular which means—however that is how python prints it quite than the precise worth. python might have printed that as r'c:program information' as an alternative.

the home windows api

studying the registry (and much more so, writing to it) is the supply of a thousand hacks on internet pages (a lot of that are outdated, shouldn’t be linked to, and use the traditional regedt32.exe), but it surely’s higher to truly use the api for this. (raymond chen has written many long sad stories about why we should always use the api and never the registry.) how would we use the win32 api from python to work this out?

the win32 python api is offered within the pywin32 module, which may be obtained with python -m pip set up pywin32. the documentation for the module is quite sparse, however the core concept is that many of the home windows shell api (that’s involved with how the home windows os is about up) is offered within the win32com.shell package deal. to search out out the situation of the program information folder, msdn reveals that we want the shgetknownfolderpath function, to which is handed a knownfolderid fixed and a flag set to 0. shell constants can be found to python in win32com.shell.shellcon (for “shell constants”), which implies that discovering the program information folder requires only one (admittedly advanced) line:

>>> from win32com.shell import shell, shellcon
>>> shell.shgetknownfolderpath(shellcon.folderid_programfiles, 0)
"c:program information"

digging round within the depths of the win32 api offers us entry to something we could need to entry in home windows (together with home windows!), however as we’ve seen, it may be fairly sophisticated to learn how to do what we have to, after which to translate that want into python. fortuitously, there are wrapper libraries for most of the capabilities generally used. one good instance is pygetwindow, which permits us to enumerate and management on-screen home windows. (it claims to be cross-platform, but it surely really solely works on home windows. however that’s all we want right here.)

we are able to set up pygetwindow with python -m pip set up pygetwindow, after which checklist all of the home windows on display and manipulate them:

>>> import pygetwindow as gw
>>> allmsedgewindows = gw.getwindowswithtitle("edge")
>>> allmsedgewindows
[win32window(hwnd=197414), win32window(hwnd=524986)]
>>> allmsedgewindows[0].title
'pywin32 · pypi - microsoft edge'
>>> allmsedgewindows[1].title
'welcome to python.org - microsoft edge'

these home windows may be managed. a window object may be minimized and restored, or resized and moved across the display, and centered and dropped at the entrance:

>>> pythonedgewindow = allmsedgewindows[1]
>>> pythonedgewindow.reduce()
>>> pythonedgewindow.restore()
>>> pythonedgewindow.dimension
measurement(width=1050, top=708)
>>> pythonedgewindow.topleft
level(x=218, y=5)
>>> pythonedgewindow.resizeto(800, 600)

it’s at all times price wanting on pypi for wrapper modules that present a extra handy api for no matter we’re attempting to do with home windows or with home windows. but when want be, we have now entry to the entire win32 api from python, and that can allow us to do something we will consider.

this text is excerpted from useful python, accessible on Pylogix premium and from book retailers.