Python and Windows

About Me

Started with Python back 1993
First port of Python for Windows
pywin32 grew organically
Member of the Python Software Foundation
Live in Melbourne, work for Mozilla.
Grateful to be invited!

Python on Windows is popular

Not just used by you Linux/Mac fans!
Nearly 1,000,000 installer downloads per month - but hard to get direct comparisons.
Python 3 around 1/2 of those.
Plus ActiveState, Enthought, etc

The 2 faces of Python on Windows (pre 2011)

CPython - A native port of Python on Windows.

IronPython - An implementation of Python using the .NET environment

The 2 faces of Python on Windows (post 2011)

CPython - A native port of Python on Windows.

IronPython - An implementation of Python using ~~the .NET environment~~

I'm not dead yet. It's only a flesh-wound

The 2 faces of Python on Windows (post 2011)

CPython - A native port of Python on Windows.

CPython + WinRT??

It's not at all clear how this is going to pan out.

.NET was to be the future

A "managed" virtual machine environment.
Programs compiled to .NET byte-code instead of native machine-language
Fast JIT compilers means things usually are native when it matters

.NET was to be safe

Environment manages "safety" of programs:
Prevents accidental errors such as invalid memory references.
Prevents malicious code by enforcing access control.
Think restricted environments such as your browser (eg, Silverlight)

.NET was to be safe

Environment manages "safety" of programs:
Prevents accidental errors such as invalid memory references.
Prevents malicious code by enforcing access control.
Think restricted environments such as your browser (eg, Silverlight)

Windows 8/Metro

Uses HTML5 apps plus a browser-based API
Internet Explorer only
.NET notable as an omission
Silverlight appears dead.
.NET isn't quite dead yet though.

Watch this space!

Mark's free opinion
- you get what you pay for!

Many apps will be HTML5
Browser-based APIs for most hardware resources
IndexedDB, Session Storage, App Cache, etc
All browsers creating "apps" concept - no "chrome"

Mark's free opinion
... until someone tells me to stop!

Mozilla's Boot2Gecko/Google's Chromium a case in point.
But the HTML-only future is a long way off.
And not for all apps.
Your jobs are safe :)

b2g and chromium are difference shades of the same thing. b2g is designed to run on a different class of hardware and with different hardware accessories, but otherwise the same idea - the web is the app!

CPython on Windows

First-class support for Windows. Eg: Unicode APIs are preferred to offer seamless Unicode experience.
Tends to avoid platform-specific functionality
Native windows functions are used to create a cross-platform environment

CPython on Windows

Not much Windows specific functionality is exposed.
Just Windows specific implementations of cross-platform features.
ctypes or pywin32 is often used to fill in the gaps.

Much of CPython uses unicode windows apis

Python for Windows Extensions (pywin32)

Expose Windows specific features

Broad coverage
native IO, services, networking, COM, UI, etc

stable and mature

Python for Windows Extensions (pywin32)

Leveraged by many other projects;
things like twisted, mercurial etc all take advantage of pywin32 if found.

Downside: fairly large, not easy_install-able

Cross-platform?

Python has rich cross-platform support - so why target Windows specific features?

Provide good experience for administrators.
Provide good experience for users.
Integrate with other languages and development environments.

So if Python is cross-platform, why do I care about Windows specific features?

For administrators

NTLM/Kerberos
admins like the security of not providing passwords to applications.
Integrate with existing user roles
admins use Windows tools to grant access
Implement 'daemon' as a service
give administrators a single control point.
Integrated performance monitoring, event logging, etc

For users

NTLM/Kerberos for convenience
Use native widgets for navigating the file-system and shell namespace
Leverage metadata stored in files
Access printers, USB devices, etc

Integrate with development tools

Some shops have standardized on Windows, not Python
Use Visual Studio as a development environment.
Write reusable components in languages other than Python

Windows Management Instrumentation (WMI)

A (somewhat) consistent interface to common management tasks.
Start a process on a remote computer
Schedule a process
Reboot a computer
Query event log, etc

Windows Management Instrumentation (WMI)

But can't all these be done without WMI?

Yes, but only with various low-level API calls.

Which is the fallback if WMI can't do it...

WMI example

Show all automatic services which are not running

import wmi
c = wmi.WMI()
stopped = c.Win32_Service(StartMode="Auto", 
                          State="Stopped")
for s in stopped:
    print s.Caption, "service is not running"

Non WMI version

    from win32service import (
        OpenSCManager, EnumServicesStatus, QueryServiceConfig, 
        OpenService, CloseServiceHandle, 
        SC_MANAGER_ENUMERATE_SERVICE, SERVICE_WIN32, SERVICE_INACTIVE, 
        SERVICE_ALL_ACCESS, SERVICE_AUTO_START)
    hscm = OpenSCManager(None, None, SC_MANAGER_ENUMERATE_SERVICE)
    for s in EnumServicesStatus(hscm, SERVICE_WIN32, SERVICE_INACTIVE):
        hs = OpenService(hscm, s[0], SERVICE_ALL_ACCESS)
        c = QueryServiceConfig(hs)
        if c[1] == SERVICE_AUTO_START:
            print name, "is not running"
        CloseServiceHandle(hs)

Don't try and understand it, but instead marvel at the amount of domain knowledge needed to even start.

WMI availability

Available on Windows 2000 and later.
A layer on top of pywin32. Technically can be used in pure pywin32, but this isn't advised

Packaging Python apps - py2exe

Supports bundling an app and all dependencies.
A single package - possibly even a single executable.
No need to install Python on the target
Good pywin32 support - COM, services, etc

Python launcher

PEP 397

'Shebang' processing for Windows

Useful from the command-line too.

Installed with Python 3.3 and available separately

Python launcher - why now?

Previously 'last version installed wins'

Not really a problem with 2.x series.

Python 3.x made this a real problem.

Each script is tied to a specific version.

Launcher Shebang processing

Compatible with *nix shebang lines.
#! /usr/bin/python
#! /usr/bin/env python
Windows specific shebang lines.
#! c:\python27\python.exe Minimal shebang lines
#! python3

Version specific shebang lines

Symlinks are often used on Linux to specify a version.
#! /usr/bin/python3

Launcher handles this too
#! /usr/bin/python3
#! /usr/bin/python2.7

Launcher on the command-line

c:\> py script.py
Launches the latest installed Python 2.x - No need for them all to be on the PATH

c:\> py -3.2 script.py
c:\> py -3.3-32 script.py
Launch 3.2, 32bit 3.3

The 64bit version of Python is always preferred if both are found. -32 allows you to override this.

Full Unicode Implementation in 3.x

All use of Windows API by core Python uses Unicode

Implementation detail which is completely invisible, but still nice!

Optionally add Python to the PATH

New installer option to add Python to the PATH.
Off by default - hard to get right with multiple versions.
Less relevant now the launcher exists

os.kill

os.kill does something useful on Windows.

Slightly different semantics and usage than *nix.

RTFM

VirtualEnv

VirtualEnv is a tool to create isolated Python environments.

Now built into Python itself.

Includes support for Windows

Makes an existing useful tool even more useful!

Using new MSVC

3.3 uses Microsoft Visual C++ 2010

End to manifest hell

No visible change.

Extension authors must upgrade compiler

Summary

Extremely popular on Windows.
Continues to follow new innovations on the platform.
Continues to work with older "innovations" too.
Continues to listen to users about what support is necessary.
Makes working with Windows less painful.

Python and Windows

Python on Windows is popular

The 2 faces of Python on Windows (pre 2011)

The 2 faces of Python on Windows (post 2011)

The 2 faces of Python on Windows (post 2011)

A minor digression

.NET was to be the future

.NET was to be safe

.NET was to be safe

Windows 8/Metro

Mark's free opinion - you get what you pay for!

Mark's free opinion... until someone tells me to stop!

Python on Windows

CPython on Windows

CPython on Windows

Python for Windows Extensions (pywin32)

Python for Windows Extensions (pywin32)

Cross-platform?

For administrators

For users

Integrate with development tools

Windows Management Instrumentation (WMI)

Windows Management Instrumentation (WMI)

WMI example

Non WMI version

WMI availability

Packaging Python apps - py2exe

What's new with Python on Windows?

Python Launcher

Python launcher

Python launcher - why now?

Launcher Shebang processing

Version specific shebang lines

Launcher on the command-line

Full Unicode Implementation in 3.x

Optionally add Python to the PATH

Links

os.kill

VirtualEnv

Using new MSVC

Summary

Questions?

Mark's free opinion
- you get what you pay for!

Mark's free opinion
... until someone tells me to stop!