We Keep Coding

Block someone access from my software if he is using 32bit PC

How does softwares block access when they identify a 32bit PC, and how can I perform this with Python ?

I haven't used it, but the cpuinfo module looks like it should work. Maybe try installing that module from pip and then test cpuinfo.get_cpu_info()["bits"] == 32

Python for .NET "unable to find assembly" error

I'm using CPython and I have a C# dll. I'm trying to use Python for .NET to make them talk. I can't use IronPython because I need to integrate this into an existing CPython system.
I'm completely new to Python for .NET, and I actually have very little experience with Python and no experience with C#. So please forgive me if my question seems very basic.
I'm using Python 2.7.3, and I downloaded
pythonnet-2.0-alpha2-clr2.0_131_py27_UCS2 and unzipped it into a folder named pyfornet_test, which also contains the dll I'm trying to use (called DotNet4Class.dll)
Then I run this:
import sys
import os
import clr
sys.path.append(r"C:\pyfornet_test")
clr.AddReference("DotNet4Class.dll")
Which gives me this error:
System.IO.FileNotFoundException: Unable to find assembly 'DotNet4Class.dll'.
at Python.Runtime.CLRModule.AddReference(String name) in C:\Users\Barton\Documents\Visual Studio 2008\Projects\PyShar
p\trunk\pythonnet\src\runtime\moduleobject.cs:line 375
Any advice would be much appreciated. Thank you!

One reason can be Windows was not enabling it to load from "external sources". To fix this:
Right-click on the .dll
"Properties"
Under "General", click "Unblock"

Try this (without extension .dll):
clr.AddReference(r"C:\pyfornet_test\DotNet4Class")

Is DotNet4Class.dll built against .NET 4? I assume so based on the naming of the dll.
Note the issue here: http://sourceforge.net/tracker/?func=detail&aid=3293169&group_id=162464&atid=823891
clr.AddReference fails when assembly is built with .NET 4.0 - ID: 3293169
I'd read the solution, but essentially, you need to rebuild and recompile the python for .NET project under .NET 4.
I'll also mention that projects like this, that aren't actively developed and used by lots of people, generally have subtle idiosyncrasies that make knowledge of the platform essential to work around problems such as this. It sounds like you're trying to hack this solution in without understanding much about python or .NET which is always going to be fraught with problems.

Did you try clr.FindAssembly?
import clr
import sys
assemblydir = r"C:\pyfornet_test"
assemblypath = r"C:\pyfornet_test\DotNet4Class.dll"
sys.path.append(assemblydir)
clr.FindAssembly(assemblypath)
I don't know why it works, but this code works on my computer (Python 2.7, .NET4)

I have code like this (I copied MyRightClickMenuService.dll to the same directory as my script.py). It is built against .Net 4.0.
# script.py
import clr
import os
import sys
sys.path.append(os.path.dirname(__file__))
clr.AddReference('MyRightClickMenuService')
clr.AddReference('System')
clr.AddReference('System.Security')
from MyRightClickMenuService import (
AclSecuredNamedPipeBinding,
MyMenuItem,
MyContextMenuService,
etc
)

Checklist
The folder(s) containing the DLL(s) is/are added to sys.path before loading. You may append, or sys.path.insert(0, dll_folder) to put it first on the list.
You call clr.AddReference('my_dll') without the dll extension (for my_dll.dll), after adding the folder to sys.path
The DLL Target Architecture is the same as the CPython version bitness. That is, if Architecture is x64, use 64-bit python, and if Architecture is x86, use 32-bit python. (instructions for this below)
How to check target Architecture for DLL?
I Used ILSpy (free and open source) -> Open DLL -> Check the output. Below example output.

What worked for me was to Unblock the dll file.
if u download the dll file or took it from different computer it might be blocked. So unblocked solved the issue for me.
To unblock right click on the properties if the dll file and check the Unblock box at the bottom

Simulating keystrokes in python using pywin32

I am looking to simulate keystrokes in python 3.2 in windows 7 to be sent to a GUI.I have python win32 module installed on my pc.The order is alt+t+r+name+enter.What would be the best way of sending these keystrokes to the active window?any sample code would be of a great help.
Thanking you.
(I have seen some module called sendkeys but can that be used with pywin32?i am not allowed to install any other modules)

I know this may not be perfect. We have a testing application using python 2.7. We leverage the windows scripting host to send keys. I have not had time to port anything over to python 3, but this might get you in the right direction. It should be pretty similar.
import win32api
import win32com.client
shell = win32com.client.Dispatch("WScript.Shell")
shell.Run("app")
win32api.Sleep(100)
shell.AppActivate("myApp")
win32api.Sleep(100)
shell.SendKeys("%")
win32api.Sleep(500)
shell.SendKeys("t")
win32api.Sleep(500)
shell.SendKeys("r")
win32api.Sleep(500)
shell.SendKeys("name")
win32api.Sleep(500)
shell.SendKeys("{ENTER}")
win32api.Sleep(2500)
Here is a list of the send key commands for Windows Scripting Host.
Update
This uses pywin32. It is installed by default in the ActiveState version of python (which is the one I am using). I am not sure, but I do not believe, that it is installed by default in the plain vanilla version of python.

How can I get the correct case when calling Python's os.getcwd()?

When I call os.getcwd() on my Mac under OS X 10.6.4 from my home directory, the path is converted to lowercase. I get
/users/myusername
instead of
/Users/myusername
On another Mac I get the correct uppercase string. How can I configure this? Is there a (hidden) Python setting?
Reason for asking:
On OS X all user directories are in "/Users". This is always uppercase. When using Mercurial, it gets sometimes confused with this strange and incorrect normalization of my current directory.
In reply to the suggested solutions:
(1)
DiskUtil says that my drive has a format of "Mac OS Extended (Journaled)". I bought my computer some month ago and it's still the original drive, never reformatted.
(2) Another python console session log:
$>>> os.system('pwd')
/Users/klaas
0
$>>> os.getcwd()"
'/users/klaas'
$>>> os.path.normcase('/Users/klaas')
'/Users/klaas'
$>>> os.chdir('/UsErS/klaas')
$>>> os.getcwd()
'/users/klaas'
$>>> os.chdir('/UsErS/klaas')
$>>> os.getcwd()
'/users/klaas'
Update 2:
Thanks for all the replies. I created a test case in Objective-C and it has the same lowercase folder name:
NSFileManager *filemgr;
NSString *currentpath;
filemgr = [NSFileManager defaultManager];
currentpath = [filemgr currentDirectoryPath];
NSLog (#"Current directory is %#", currentpath);

The "HFS plus" filesystem, which has been Apple's filesystem of choice since the days of Mac OS 8, is normally not case-sensitive.
Mac OS X version 10.4, or "Tiger" as it's more commonly known, introduced the ability to create an HFS plus filesystem which is case-sensitive.
Could one of them be using a case-sensitive FS?

The problem seems to be a problem with your particular Python install on your particular Mac. I haven't been able to turn up anyone else who has the same problem.
It's likely that your Mac has a problem with its installation of Python. AFAIK, there isn't a configuration option to make Python represent getcwd() with the proper case (this behavior should be enabled by default). If it's an option, I'd try reinstalling Python. If that doesn't work, you should report a bug to the Python bug tracker.

Two uneducated guesses:
First, apparently OSX is usually case-insensitive, which usually means case-preserving: the name of the current directory either comes from how it's capitalized on disk, or how it was capitalized when you changed into it. If you run os.system('pwd'), does it show it lowercased or not? If so, then that's what the OS is reporting and Python isn't doing anything wrong. Does it change if you os.chdir('/UsErS/username') first?
Second, there's one function that does lowercase or not selectively based on the OS: os.path.normcase. The macpath version does lowercase. I'm pretty sure os.getcwd does not automatically run the results through this; just mentioning it as a place to check.

In the end it was an issue with the Mercurial installation. I ran into it again tonight.
https://www.mercurial-scm.org/wiki/Download gives you different options how to install Mercurial. If I choose the first one (the Mac OS X packages) the "/Users" directory will be reported as "/users" (even when accessing it with Objective C). This can be solved by installing Mercurial via the macports option. This fixes the issue and the "/Users" directory is returned again with an uppercase "U".
Any hints why this is happening are still welcome.
But a least there is a solution.

Problem opening registry key on Windows 7

This code used to work on Vista (and Windows XP) but after an upgrade to Windows 7 it now fails with the error shown:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32
>>> import _winreg
>>> h1 = _winreg.ConnectRegistry(None, _winreg.HKEY_LOCAL_MACHINE)
>>> key = r'SOFTWARE\Python\PythonCore\2.6\InstallPath'
>>> h2 = _winreg.OpenKey(h1, key, 0, _winreg.KEY_ALL_ACCESS)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
WindowsError: [Error 5] Access is denied
I'm fairly sure this is the result of changes in the security model in Windows 7, but various searches I tried have turned up nothing I can use as an answer so far.
(Not that it should be relevant, but to stave off "why would you do that?" responses, this is for a developer's utility which can switch the registry between multiple installations of Python, for use in a multi-project environment where we need more control over which version of Python is in use, and what packages are available, than things like virtualenv can provide.)
Edit: The logged-in user is an Administrator. Also, I've turned off the UAC (User Access Control) stuff as completely as one can (not true... see next edit), as was previously the case before the upgrade from Vista to Windows 7.
Edit 2: As noted in my own answer below, I hadn't rebooted after turning off UAC, so it was still set to the default. Apparently this results in the Access denied error (as I confirmed by testing with UAC set to Default and to Never).

This was a user mistake, compounded or triggered by changes in Windows 7 to how the UAC feature is implemented.
In Vista, the much-detested User Access Control feature was binary, either on or off. On Windows 7 that has been changed to provide four levels of granularity:
Always Notify (when either programs or user tries to change settings)
Default (notify only when programs try to make changes, and dim screen)
Notify without dimming (same as default but don't dim screen when notifying)
Never notify (for either programs or user changes)
My mistake was in not rebooting after dropping the UAC feature down to the Never Notify level. (Vista was aggressive about requesting that you reboot, while Windows 7 seems to be slightly more passive.)

I think you have an access right problem.
Try to open the key with a less demanding access right (e.g. KEY_QUERY_VALUE) and check if it works.
Of course, with that change you will not be able to change the registry, but it would be only for pinpointing the issue.
As an alternative, try to execute the utility from a user with higher privileges - and by the way this would be the only solution I could see for a problem involving access rights.