>>> import ctypes.wintypes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/ctypes/wintypes.py", line 20, in <module>
    class VARIANT_BOOL(ctypes._SimpleCData):
ValueError: _type_ 'v' not supported
>>> 

Shouldn't it just import silently without failing? Or if it's destined to fail, explain how to make a cross-platform import?

Perhaps the patch already there - see http://www.themacaque.com/?p=826

Found only this "patch" [1] :) I think is possible to change VARIANT_BOOL._type_ to any of short types [2] for non-"nt" platforms?

[1] https://code.launchpad.net/~mandel/python-distutils-extra/import_issues/+merge/53519
[2] http://msdn.microsoft.com/en-us/library/cc237864.aspx

That patch is more a workaround than an actual fix. Lib/ctypes/wintypes.py should either fail with an ImportError or be importable. For the former it's possible to catch the ValueError and turn it into an ImportError, or perhaps raise it if some precondition is missing; for the latter, either the creation of that signle class is skipped if _type_ 'v' is not supported, or a way to define it that works on other platforms too should be found instead.

The fix is trivial:

• define VARIANT_FALSE and VARIANT_BOOL according to specs
• enable 'v' on non-Windows systems
• enable tests for vbool

Done

Looks good to me. Ben, any objections to applying this to 2.7?

RM, please decide. :)

Smells like a new feature to me.

Even if the patch is applied only on 3.4, I would still like to see the ValueError turned into ImportError for 2.7/3.3.

My sense on the issue is that wintypes was added to the library and was never intended to raise a ValueError on import. By that logic, the behavior is a bug, not a new feature. I agree with Ezio that raising a ValueError on import is a bug. And since the patch not only addresses the ValueError on import, but simply addresses the underlying cause, it seems to me the most obvious solution.

I think it's the opposite: when Unix support was added to ctypes, 'import ctypes.wintypes' was not considered. By that logic, the patch is a new feature.
IMO "historical" arguments are moot :-)

I agree with the conclusion tough: the patch will not break code that carefully catches ValueError, and so it suitable for 2.7.

On Mon, Aug 12, 2013 at 7:11 AM, Ezio Melotti <report@bugs.python.org>wrote:

Even if the patch is applied only on 3.4, I would still like to see the
ValueError turned into ImportError for 2.7/3.3.

Why not raise an ImportError for all versions? I don't see how
'ctypes.wintypes' is ever actually useful on anything but Windows.
Allowing it to successfully import on non-Windows systems seems misleading.

We can argue about whether it's a bugfix or not. But I don't see how having this patch in 2.7 helps anyone, since ctypes.wintypes is useless on non-Windows platforms.

The first thing it helps is that it eliminates a ValueError on import. Without it, code must catch both ValueError and ImportError to run portably:

import ctypes

try:
import ctypes.wintypes
except ImportError, ValueError:
# catch ImportError and ValueError due to bpo-16396
pass

...

def code_that_runs_only_on_win():
  ctypes.wintypes.foo

One _could_ cause ctypes.wintypes to always raise an ImportError on non-Windows systems, allowing the import routine to be simpler:

try:
import ctypes.wintypes
except ImportError:
pass

But it would be even nicer if ctypes.wintypes always imported on any platform, such that the statement could be simply:

import ctypes.wintypes

But it's conceivable that certain functionality in wintypes might be useful on other systems. Consider, for example, a routine that works with pickles produced on a Windows system, or simply a comparison of some object in ctypes.wintypes against a value produced on a Windows system.

The argument for that need (esp. on Python 2.7) is not strong, but since the patch to address the ValueError is simple, straightforward, and perhaps even simpler than something that would address the ValueError specifically, it seems worthwhile to accept the patch.

Using 'ctypes.wintypes' on non-Windows systems is most likely a bad idea. Most of the types are defined in terms of the types for the target that the interpreter is built for. Comparing serializations thereof in a cross platform manner doesn't make sense for a lot of cases.

I really think it is only useful for Windows platforms and allowing it to silently import is misleading.

This is not a regression, though, so most people wouldn't be able to simplify their code because they have to support older Python versions.

+1 to getting this patch in. The fact that this raises a ValueError and not an ImportError is really annoying and we definitely see it as a bug.

New changeset 5456e78 by Jason R. Coombs in branch 'master':
bpo-16396: Allow wintypes to be imported on non-Windows systems. (GH-21394)
5456e78

New changeset 6e998fa by Miss Skeleton (bot) in branch '3.8':
bpo-16396: Allow wintypes to be imported on non-Windows systems. (GH-21394)
6e998fa

New changeset 05d52a0 by Miss Skeleton (bot) in branch '3.9':
bpo-16396: Allow wintypes to be imported on non-Windows systems. (GH-21394)
05d52a0

New changeset 7865f51 by Shantanu in branch 'master':
bpo-16396: fix BPO number in changelog (GH-23951)
7865f51

New changeset 71d7390 by Miss Islington (bot) in branch '3.9':
bpo-16396: fix BPO number in changelog (GH-23951) (GH-23956)
71d7390