I am working on cross platform utility which involves drive scanning and the automagical creation of shell/batch files for the OSs upon which it runs. Unfortunately I cannot find one simple answer.
As stated in these links:
When to use os.name, sys.platform, or platform.system?
Reliably detect Windows in Python
Extract file name from path, no matter what the os/path format
Python: What OS am I running on?
and at http://docs.python.org/library/platform.html#module-platform
The various platform.system(), platform.platform(), sys.platform, os.name() etc. etc. all suffer the problem of not necessarily being future perfect. That is if an OS developer changes things a little, these may not work (at least until patched or revised). So obviously the best solution is to try a small part of each of the above, along with targeting some OS specific executable file with a call().
Which leaves my question:
Since the best way to determine this involves platform.system, sys.platform, and os.name (assuming only generalized recognition is needed), what are the various possible outputs for those programs? The docs.python.org sections on each of these modules only lists a few, and the pages are not exactly current. Specifically I would like to know the possible output on the last three mac OS's, Win XP- Win 8, and just knowing Linux covers my needs there. Any one know what the outputs are or where i can find them?
Thanks in advance.
Clarification:
What I am looking for here is the currently known values so that I can incorporate them into an existing project, with an eye towards future code revision being made easier on my end. So the CURRENT return values are what I am seeking (Last 3 gens of Mac OS* and Win * since beyond that probably isn't much used any more)
Edit: For the specific question of all possible return values:
Related stackoverflow answer for Possible values from sys.platform?
Post with the answers pointed to above:
aix3 aix4 atheos beos5 darwin freebsd2 freebsd3 freebsd4 freebsd5
freebsd6 freebsd7 generic irix5 irix6 linux2 mac netbsd1 next3 os2emx
riscos sunos5 unixware7
Also:
linux3, freebsd8, win32, dos, os2
and others.
(They were asking the same question in Aug 2006.)
Note:
As others have indicated, sys.platform is derived from the name that
the system vendor gives their system.
/Edit.
Not sure it's possible to have something so future-perfect. If you only want to know the OS (mac/win/linux) then see the examples for sys.platform.
Also, keeping things in a separate function like get_os_name lets you control or map the input-output if you see a lot of changes in the future - once a year per OS? Also convenient to combine with the other functions you've mentioned. So you can return a tuple based on (os_name, 32/64bit, variant) (where variant is things like XP, Win8, Darwin, etc.) depending on how it affects your script.
The docs.python.org sections on each of these modules only lists a few, and the pages are not exactly current.
Unfortunately true. But again, it's impossible to account for environments or platforms in the future or even all current ones. The logical thing to do is make sure it works on the current platforms that you have tested/developed for.
Related
The title basically explains the problem. I don't know a way to use GetLogicalDriveStrings() for os's besides windows, so it would be very helpful if someone could tell me what to use, and how. I need this so I can search all drives on a computer for a file, on the 3 main os's. There was a similar question to this one, but it had only one answer, which had a check mark, and it basically restated the problem. Plus, I couldn't comment cause I didn't have enough reputation since I mostly only read from stack exchange. Edit: I want my program to search the entire computer for a file, and run it, on the 3 main os's. That's all I want. I know windows has partitions that are treated as singular drives, and usb drives, so I want to find out how to search it all, and all of the partitions.
I sometimes use emojis in programs to highlight certain parts of the code (in open source libraries). I rarely use more than say 5-6 per script and I find they really stand out due to their colors in a text editor.
Typically, they are transient markers and will be removed when whatever issue they are associated with is closed.
My question is: are emojis liable to cause any issues in the general Python toolchain? This includes, but is not limited to: git, github, pypi, editors, linters, interpreter, CI/CD pipelines, command line usage...
I haven't seen any, but then again I rarely see emojis in code. This is a Python 3 only question, so Python 2 unicode aspects are out.
(This question is not about whether this looks professional or not. That's a valid, but entirely separate consideration.)
Some examples:
# ⚙️ this is where you configure foo
foo.max_cntr = 10
foo.tolerate_duplicates = False
# 🧟♂️🧟♂️🧟♂️ to indicate code to be removed
some dead code
# 👇 very important, don't forget to do this!
bar.deactivate_before_call()
In terms of risks, there aren't really any real ones. If you use them in comments they'll be removed/ignored at runtime anyway so performance-wise there's no issues.
The main issue that you could run into is that some Linux distributions (distros) DONT support emojis, so they'd fallback to some standard unicode character (generically a white rectangle with a cross through the middle), so this could make comments hard to understand.
But in personal use: no not really, there's no issues.
TLDR: Probably not, but maybe.
I recently installed Python 3.7 and at the end of the setup, there is the option to "Disable path length limit". I don't know whether or not I should do this.
What are the pros and cons of doing this? Just from the sound of it you should always disable it.
I recommend selecting that option and thereby removing the path length limit. It will potentially save you time in future on debugging an avoidable issue.
Here is an anecdote of how I came to know about it:
During the compilation of my program (C# code on a Windows machine), I started getting the following error:
error MSB3541: Files has invalid value "long\path\filename". The specified path,
file name, or both are too long. The fully qualified file name must be less than
260 characters, and the directory name must be less than 248 characters.
This error was not allowing me to build my project and the only apparent solution to this issue was to shorten my path/file names. Turns out that this bug is a built-in limitation in NTFS (Window's File System): Why does the 260 character path length limit exist in Windows?
After a couple of decades with the limitation built into the NTFS file system, it has finally been fixed (Unix based system did not have it) in Windows 10 (https://learn.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation), but it is not enabled automatically, and needs registry (or group policy) settings to do this. The Python option allows you to disable it for Python libraries, saving you a lot of headache.
Do note that enabling this option will,
a) break compatibility of your programs on systems using older versions of Windows 10 and lower, when using long file/directory names and paths.
b) break programs on Windows 10 machines not having this option enabled, when using long file/directory names and paths.
to answer both of your questions:
Should you disable this?
The quick answer is that it doesn't matter that much, since this only matters when working with paths longer than 260 characters, not something most people do.
What are the pros and cons of disabling the path length limit?
Pros
you won't get an error when working with filepaths longer than 260 characters, so there's less worry about the path length
it can make debugging easier
Cons
disabling it has no negative technical side effects
if you work in a team, it might introduce bugs where code works on your machine, but not on their machine. because you have the path-limit disabled, but they don't.
disabling it can have negative human behaviour side effects.
Enabling long paths could promote bad naming-behaviour in your team
regarding pathnames and folderstructure. A limit forces people to
shorten their paths.
E.g. I've worked in teams with paths like this, and allowing them longer names would have resulted in less readable filepaths:
c:/project_name/unity/files/assets/UI/UI_2.0/levelname/season2_levelname/release_season2_levelname_ui_2/PROJECT_S2_MENU_UI/PROJECT_S2_hover_button_shadow_ui/PROJECT_S2_hover_button_shadow_ui_blue/PROJECT_S2_hover_button_shadow_ui_blue.asset
Explanation
To understand the pros and cons, it helps to understand what the path length limit is.
windows path length
You probably already know that a Windows path is a string, that represents where to find a file or folder.
e.g. C:\Program Files\7-Zip
longer folder or file names result in a longer string.
e.g. C:\Program Files\Microsoft Update Health Tools
more folders inside other folders also result in a longer string
e.g. C:\Program Files\Microsoft Update Health Tools\Logs
file path length errors
If you have a lot of folders inside each other, with long names, you might run into an error when trying to use this path in your code.
This is because Windows has a path length limit. An update in windows 10 allows you to disable this limitation. but it doesn't do so by default.
Disabling this limitation allows your computer to use longer paths without errors.
Why does this happen?
The old windows API promised that if you wrote your application correctly, it'd continue to work in the future.
If Windows were to allow filenames longer than 260 characters then your existing application (which used the windows API correctly) would fail.
Microsoft did create a way to use the full 32,768 path names; but they had to create a new API contract to do it. This is the update on windows 10.
read more on why
I am keeping this simple and straight forward
The "Disable path length limit" option refers to the maximum length of the file paths that Windows can handle. Disabling this limit can allow for longer file paths, which can be useful if you are working with files that have very long names or are stored in deeply nested directories. However, it can also cause compatibility issues with some programs, particularly older ones that may not designed to support long file paths.
In general, it's usually not necessary to disable the path length limit unless you have a specific need for it. If you're not sure whether you need it or not, it's probably best to leave it enabled.
Generally, it's not a good idea to disable it, especially if you have programs that could potentially break upon disabling it.
I have a lot of older programs, and potentially forgetting that I disabled it, and the fact that re-enabling it (being that finding out how to) and the fact that doing that could potentially break any program that uses long file paths in its scripts, makes having it off unhelpful, and moreover possibly a waste of time and debugging.
But to defend its existence, in certain environments it can be helpful, especially in environments where making subfolders upon subfolders is key. Particularly, this is helpful when making a game with a lot of assets. But again, there are many ways to shorten subfolders (and files), and doing that makes it generally easier to type out the path if you aren't copy-and-pasting everywhere. (For example, C:\my_game\assts\01\plyr\walk_01.png is easier to type than C:\my_epic_game_featuring_my_awesome_character\assets\…)
If you have a virtual machine or just another OS to try this on where you do not have to worry about specific programs breaking upon disabling the path limit, it'd probably be useful to have this off, but for everything else, just be wary of it's probability to make more bugs than to fix.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to concatenate multiple Python source files into a single file?
Is there a Python “pre-interpreter” to take as input a .py module containing imports and expand it so it can be run inline in an interpreter session on the command line or Telnet session? Imports of built-ins or installed modules are OK to keep, but I’d like the pre-interpreter to expand my own modules. This way, I can avoid an install while still employing modular programming techniques. For example, if I write these two modules:
myprint.py:
from math import pi
def print_pi():
print "{0:6f}".format(pi)
main.py:
from myprint import print_pi
print_pi()
Running the pre-interpreter on main.py, the output would be:
from math import pi
def print_pi():
print "{0:6f}".format(pi)
print_pi()
Update October 10 2012 22:36 Eastern USA:
Thanks to everyone who responded! My program's runtime host is permanently installed on board a locomotive, from where my program will query and monitor that computer and many other onboard systems. You can correctly predict that this computing environment is safety and mission critical (thus the need for my team’s monitoring software). Installing software in such an environment requires privileges, consumes resources, and imposes a small but real risk to the system. Thus, prudent but weeks-consuming checks have been implemented by the railroad to scrutinize software to be installed, including sign-off by a change-control board. This is the route we had planned for. But if we can eliminate this risk and thereby lessen the formality by running without any installation, that could be an advantage to at least consider. However, we do not want our architecture to be restricted by the non-install requirement, i.e., we don't want to have to write the whole program in one module. From your answers it seems my notion is not possible.
Your example assumes that Python imports are something like C macros. That's not the case. Pythons import is much more powerful and complex. Therefore an import cannot be replaced by copying a few lines of code. The the answer is: No there is no such preprocessor. But if you specify more detailed what problem you really would like to solve, we might be help you to solve it in python.
I've seen numerous ways of retrieving installed programs on WinXP+ in python. What is the proper and most robust way of doing this?
Currently I'm accessing HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall and reading each of the keys from there to get a list. (I've been told this isn't the proper way of doing things) I've seen examples of using WMI/Win32com to do this as well but have seen comments along with those implementations that WMI might be turned off on certain machines and that it's not a very reliable solution.
Is there a method which is both proper, and reliable to get a list of installed programs? None of the WMI examples I've seen have worked on this machine (hence my reluctance to use it, I'm only running WinFLP; which is a stripped vers of XP.)
I seem to have also found the TechNet article which my searches have turned up which is provided to a similar answer on my question: http://gallery.technet.microsoft.com/ScriptCenter/en-us/154dcae0-57a1-4c6e-8f9f-b215904485b7 Note that Vista/7 listed under Platforms very clearly says "Nope"...won't work. So the WMI deal seems like it's a no-go...
Being able to retrieve the installed path would be an upside as well, as right now my current code does not account for someone installing on another drive, or in a non-default directory.
The technet script you refer to perfectly works under Win 7 (with Python 2.5 32bits), and I really cannot see why it shouldn't.
Actually, the real weakness of the WMI approach is that it only lists products installed through the Windows Installer. So it's will not give you the full list. Many programs use different installers. Just compare the results between the (Select * from Win32_Product) and what is displayed in the Control Panel. So, unless you are sure that the program that interset you in your listing are installed with MSI, WMI is definitely not an answer.
So it may be not very pythonic, but the best way, as far as I know, is to use the registry as you've done. This is actually how the control panel works, so at least Windows considers it to be the most robust way to do it.
WMI is the correct way to look for installed programs as it will work across different versions of the OS and will be supported going forward. Looking for specific regkeys may work fine for specific versions of Windows but is not guaranteed to work in the future. Here is some simple python code to check for Box Sync which I just tried on Windows 7. Note that not all fields will be available for every product so be aware these will be 'None.'
import wmi
w = wmi.WMI()
for p in w.Win32_Product():
if 'Box, Inc.' == p.Vendor and p.Caption and 'Box Sync' in p.Caption:
print 'Installed {}'.format(p.Version)
The downside I have seen with WMI is it is very slow to start up.