At the beginning of the script, I use platform.system and platform.release to determine which OS and version the script is running on (so it knows it's data is in Application Support on Mac, home on unix-like and non-mac unix, appdata on windows <= XP, and appdata/roaming on windows >= Vista). I'd like to test my series of ifs, elifs, and elses what determine the os and release, but I only have access to Mac 10.6.7, some unknown release of Linux, and Windows 7. Is there a way to feed platform fake system and release information so I can be sure XP, Solaris, etc, would handle the script properly without having an installation?
Maybe something like
>>> platform.system = lambda: "whatever"
>>> platform.system()
'whatever'
you could create your initialization functions to take those variables as parameters so it is easy to spoof them in testing
You probably want to explore mocking platform for your testing. Alternatively, you could directly monkey patch platform, or even mess with sys.modules directly to override the default platform module, but mock is already designed to be self contained and also has the benefit of pretty clearly showing in your code what is and is not test instrumentation, so you don't accidentally get test functionality released in your production code.
For me, directly patching platform.system with pytest-mock did not work. A simple trick though is to abstract the retrieval of this information in a utility function of your own (which you can successfully patch with pytest-mock this time).
Hence, in your implementation module/class:
def _get_system() -> str:
return platform.system().lower()
def _is_windows() -> bool:
return _get_system() == 'windows'
And in your test, here using pytest + pytest-mock:
def test_win_no_pad_code():
with patch('module_name._get_system', MagicMock(return_value='windows')):
assert module_name._is_windows()
This is one way of doing using module, but you can do the equivalent using a class instead.
Related
I have a simple python class that I am trying to make com-accessible (e.g., to VBA):
class Foo(object):
_reg_progid_ = 'Foo.Application'
_reg_clsid_ = '{602462c5-e750-4d1c-879b-a0465bebb526}'
_public_methods_ = ['say_hello']
def __init__(self):
pass
def say_hello(self, name):
return f'Hello, {name}'
if __name__=='__main__':
print("Registering COM server")
import win32com.server.register
win32com.server.register.UseCommandLine(Foo)
Several examples indicate this is a pretty standard approach (see here and here).
From python, this appears to be com-accessible. No errors raise, and the output appears as expected:
from comtypes.client import CreateObject
f = CreateObject('Foo.Application')
f.say_hello('David')
When trying to instantiate a Foo from VBA, however, there is an error (Run-time error -2147024770 (8007007e) Automation error The specified module could not be found).
Dim f As Object
Set f = CreateObject("Foo.Application")
I am actually able to resolve this error using the method described in this answer (and this one), specifically doing:
_reg_clsctx_ = pythoncom.CLSCTX_LOCAL_SERVER
And then localserver.serve('{602462c5-e750-4d1c-879b-a0465bebb526}') in the name guard function.
However, in some past applications development work (a long time ago using python 2.7) I know we did not do this part -- instead we used Innosetup to compile an installer from a foo.exe and foo.dll (derived from foo.py probably from py2exe or similar) and other dependencies.
I'm happy (for now) with the solution, but I guess my question is whether this is necessary (as several examples don't do these things) or if there's something else I'm missing (e.g., the installer that I used in a past life actually handled this bit behind-the-scenes with the DLL instead of a .py file?)?
Additional information: OS is 64-bit Windows, running Excel 2013 (32-bit) and python 3.7.4 (32-bit).
Via
import win32com.client
wordapp = win32com.client.gencache.EnsureDispatch('Word.Application')
I can get a Word Application object documented e.g. here. However, ipython's autocompletion is not aware of that API, is there any way to add that?
Quick solution
Perhaps the simplest way to achieve code completion in IPython (tested with 6.2.1, see the answer below for a snippet that works with 7.1) and Jupyter is to run the following snippet:
from IPython.utils.generics import complete_object
import win32com.client
#complete_object.when_type(win32com.client.DispatchBaseClass)
def complete_dispatch_base_class(obj, prev_completions):
try:
ole_props = set(obj._prop_map_get_).union(set(obj._prop_map_put_))
return list(ole_props) + prev_completions
except AttributeError:
pass
Short story long
With some more details being outlined in this guide, win32com ships with a script, makepy.py for generating Python types corresponding to the type library of a given COM object.
In the case of Word 2016, we would proceed as follows:
C:\Users\username\AppData\Local\Continuum\Anaconda3\pkgs\pywin32-221-py36h9c10281_0\Lib\site-packages\win32com\client>python makepy.py -i "Microsoft Word 16.0 Object Library"
Microsoft Word 16.0 Object Library
{00020905-0000-0000-C000-000000000046}, lcid=0, major=8, minor=7
>>> # Use these commands in Python code to auto generate .py support
>>> from win32com.client import gencache
>>> gencache.EnsureModule('{00020905-0000-0000-C000-000000000046}', 0, 8, 7)
The location of makepy.py will of course depend on your Python distribution. The script combrowse.py, available in the same directory, can be used to find the names of available type libraries.
With that in place, win32com.client will automatically make use of the generated types, rather than the raw IPyDispatch, and at this point, auto-completion is available in e.g. IPython or Jupyter, given that the COM object of interest actually publishes its available properties and methods (which is not a requirement).
Now, in your case, by invoking EnsureDispatch instead of Dispatch, the makepy part of the process is performed automatically, so you really should be able to obtain code completion in IPython for the published methods:
Note, though, that while this does give code completion for methods, the same will not be true for properties. It is possible to inspect those using the _prop_map_get_ attribute. For example, wordapp.Selection.Range.Font._prop_map_get_ gives all properties available on fonts.
If using IPython is not a strong requirement, note also that the PythonWin shell (located around \pkgs\pywin32\Lib\site-packages\pythonwin\Pythonwin.exe) has built-in code completion support for both properties and methods.
This, by itself, suggests that the same is achievable in IPython.
Concretely, the logic for auto-completion, which in turn relies on _prop_map_get_, can be found in scintilla.view.CScintillaView._AutoComplete. On the other hand, code completion in IPython 6.2.1 is handled by core.completer.IPCompleter. The API for adding custom code completers is provided by IPython.utils.generics.complete_object, as illustrated in the first solution above. One gotcha is that with complete_object being based on simplegeneric, only one completer may be provided for any given type. Luckily, all types generated by makepy will inherit from win32com.client.DispatchBaseClass.
If this turns out to ever be an issue, one can also circumvent complete_object entirely and simply manually patch IPython by adding the following five lines to core.completer.Completion.attr_matches:
try:
ole_props = set(obj._prop_map_get_).union(set(obj._prop_map_put_))
words += list(ole_props)
except AttributeError:
pass
Conversely, IPython bases its code-completion on __dir__, so one could also patch gencache, which is where the code generation ultimately happens, to include something to like
def __dir__(self):
return list(set(self._prop_map_get_).union(set(self._prop_map_put_)))
to each generated DispatchBaseClass.
fuglede's answer is great, just want to update it for the newest versions of IPython (7.1+).
Since IPython.utils.generics has changes from using simplegeneric to using functools, the #complete_object.when_type method should be changed to #complete_object.register. So his initial code should changed to:
from IPython.utils.generics import complete_object
import win32com.client
#complete_object.register(win32com.client.DispatchBaseClass)
def complete_dispatch_base_class(obj, prev_completions):
try:
ole_props = set(obj._prop_map_get_).union(set(obj._prop_map_put_))
return list(ole_props) + prev_completions
except AttributeError:
pass
I want to write a simple unit test with os.path.basename
Example
def test(path):
return os.path.basename(os.path.normpath(title))
...
result = test('/path/foo')
assert result == 'foo'
result = test(r'c:\Users\Foo\Documents\foo')
assert result == 'foo'
Problem
Running on linux the second test (windows path) is failing.
I guess the first test will fail on windows.
This actually makes pretty much sense since there are different os.path modules
Python Documentation
Since different operating systems have different path name conventions, there are several versions of this module in the standard library.
Question
Is there a way to import a specific version of os.path?
I already tried to set sys.platform to win32
Of course I could check the current platform and just run one of both tests - but I was wondering if there is a way to run both tests.
You should always use / as the path separator. Python will translate it to the correct separator for your platform.
\ is used to start escape sequences. Using / will avoid having to use raw strings to disable \ escape sequences (as in the second string in your post).
Using \ in raw strings may also cause os.path methods to behave oddly (and will only work on Windows platforms).
I'm trying to determine if the operating system is Unix-based from a Python script. I can think of two ways to do this but both of them have disadvantages:
Check if platform.system() is in a tuple such as ("Linux", "Darwin"). The problem with this is that I don't want to provide a list of every Unix-like system every made, in particular there are many *BSD varieties.
Check if the function os.fchmod exists, as this function is only available on Unix. This doesn't seem like a clean or "Pythonic" way to do it.
import sys
if 'win' in sys.platform():
#windows
else:
#not windows
or, you can try importing a platform dependent library
try:
import windows_only as generic
except ImportException:
try:
import unix_only as generic
except ImportException:
import stdlib.module as generic
print generic.common_function()
and then there's the always reliable
>>> import os
>>> os.name
nt
The Pythonic way to do it is not to care what platform you are on.
If there are multiple different facilities to accomplish something depending on the platform, then abstract them behind a function or class, which should try a facility and move on to another if that facility is not available on the current platform.
What is the best way to do cross-platform handling of hidden files?
(preferably in Python, but other solutions still appreciated)
Simply checking for a leading '.' works for *nix/Mac, and file attributes work on Windows. However, this seems a little simplistic, and also doesn't account for alternative methods of hiding things (.hidden files, etc.). Is there a standard way to deal with this?
Here's a script that runs on Python 2.5+ and should do what you're looking for:
import ctypes
import os
def is_hidden(filepath):
name = os.path.basename(os.path.abspath(filepath))
return name.startswith('.') or has_hidden_attribute(filepath)
def has_hidden_attribute(filepath):
try:
attrs = ctypes.windll.kernel32.GetFileAttributesW(unicode(filepath))
assert attrs != -1
result = bool(attrs & 2)
except (AttributeError, AssertionError):
result = False
return result
I added something similar to has_hidden_attribute to jaraco.windows. If you have jaraco.windows >= 2.3:
from jaraco.windows import filesystem
def has_hidden_attribute(filepath):
return filesystem.GetFileAttributes(filepath).hidden
As Ben has pointed out, on Python 3.5, you can use the stdlib:
import os, stat
def has_hidden_attribute(filepath):
return bool(os.stat(filepath).st_file_attributes & stat.FILE_ATTRIBUTE_HIDDEN)
Though you may still want to use jaraco.windows for the more Pythonic API.
Jason R. Coombs's answer is sufficient for Windows. And most POSIX GUI file managers/open dialogs/etc. probably follow the same "dot-prefix-means-hidden" convention as ls. But not Mac OS X.
There are at least four ways a file or directory can be hidden in Finder, file open panels, etc.:
Dot prefix.
HFS+ invisible attribute.
Finder Info hidden flag.
Matches a special blacklist built into CoreFoundation (which is different on each OS version—e.g., ~/Library is hidden in 10.7+, but not in 10.6).
Trying to write your own code to handle all of that is not going to be easy. And you'll have to keep it up-to-date, as I'm willing to bet the blacklist will change with most OS versions, Finder Info will eventually go from deprecated to completely unsupported, extended attributes may be supported more broadly than HFS+, …
But if you can require pyobjc (which is already included with recent Apple-supplied Python, and can be installed via pip otherwise), you can just call Apple's code:
import Foundation
def is_hidden(path):
url = Foundation.NSURL.fileURLWithPath_(path)
return url.getResourceValue_forKey_error_(None, Foundation.NSURLIsHiddenKey, None)[0]
def listdir_skipping_hidden(path):
url = Foundation.NSURL.fileURLWithPath_(path)
fm = Foundation.NSFileManager.defaultManager()
urls = fm.contentsOfDirectoryAtURL_includingPropertiesForKeys_options_error_(
url, [], Foundation.NSDirectoryEnumerationSkipsHiddenFiles, None)[0]
return [u.path() for u in urls]
This should work on any Python that pyobjc supports, on OS X 10.6+. If you want 10.5 or earlier, directory enumeration flags didn't exist yet, so the only option is something like filtering something like contentsOfDirectoryAtPath_error_ (or just os.listdir) on is_hidden.
If you have to get by without pyobjc, you can drop down to the CoreFoundation equivalents, and use ctypes. The key functions are CFURLCopyResourcePropertyForKey for is_hidden and CFURLEnumeratorCreateForDirectoryURL for listing a directory.
See http://pastebin.com/aCUwTumB for an implementation.
I've tested with:
OS X 10.6, 32-bit python.org 3.3.0
OS X 10.8, 32-bit Apple 2.7.2
OS X 10.8, 64-bit Apple 2.7.2
OS X 10.8, 64-bit python.org 3.3.0
It works as appropriate on each (e.g., it skips ~/Library on 10.8, but shows it on 10.6).
It should work on any OS X 10.6+ and any Python 2.6+. If you need OS X 10.5, you need to use the old APIs (or os.listdir) and filter on is_hidden. If you need Python 2.5, change the bytes checks to str checks (which of course breaks 3.x) and the with to an ugly try/finally or manual releasing.
If anyone plans on putting this code into a library, I would strongly suggest checking for pyobjc first (import Foundation and, if you don't get an ImportError you win), and only using the ctypes code if it's not available.
One last note:
Some people looking for this answer are trying to reinvent a wheel they don't need to.
Often, when people are doing something like this, they're building a GUI and want to, e.g., show a file browsers with an option to hide or show hidden files. Many of the popular cross-platform GUI frameworks (Qt, wx, etc.) have this support built in. (Also, many of them are open source, so you can read their code to see how they do it.)
That may not answer your question—e.g., they may just be passing a "filter hidden files" flag to the platform's native file-browser dialog, but you're trying to build a console-mode file-browser and can't do that. But if it does, just use it.
We actually address this in a project we write. What we do is have a number of different "hidden file checkers" that are registered with a main checker. We pass each file through these to see if it should be hidden or not.
These checkers are not only for different OS's etc, but we plug into version control "ignored" files, and optional user overrides by glob or regular expression.
It mostly amounts to what you have done, but in a pluggable, flexible and extensible way.
See source code here: https://bitbucket.org/aafshar/pida-main/src/tip/pida/services/filemanager/filemanager.py
Incorporating my previous answer as well as that from #abarnert, I've released jaraco.path 1.1 with cross-platform support for hidden file detection. With that package installed, to detect the hidden state of any file, simply invoke is_hidden:
from jaraco import path
path.is_hidden(file)
"Is there a standard way to deal with this?" Yes. Use a standard (i.e., POSIX-compliant) OS.
Since Windows is non-standard -- well -- there's no applicable standard. Wouldn't it be great if there was? I feel your pain.
Anything you try to do that's cross-platform like that will have Win32 oddities.
Your solution is -- for the present state of affairs -- excellent. At some point in the future, Microsoft may elect to write a POSIX-compliant OS. Until then, you're coping well with the situation.