homepage

>>> 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 issue16396
 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 5456e78f4593edc277ab72fb9a9db1ebae7d4c2d by Jason R. Coombs in branch 'master':
bpo-16396: Allow wintypes to be imported on non-Windows systems. (GH-21394)
https://github.com/python/cpython/commit/5456e78f4593edc277ab72fb9a9db1ebae7d4c2d

New changeset 6e998fad1c92aee9c8c23c5887a7023d76bdf6c2 by Miss Skeleton (bot) in branch '3.8':
bpo-16396: Allow wintypes to be imported on non-Windows systems. (GH-21394)
https://github.com/python/cpython/commit/6e998fad1c92aee9c8c23c5887a7023d76bdf6c2

New changeset 05d52a0ad69cbadd4b048f2a97991e4e58d4a922 by Miss Skeleton (bot) in branch '3.9':
bpo-16396: Allow wintypes to be imported on non-Windows systems. (GH-21394)
https://github.com/python/cpython/commit/05d52a0ad69cbadd4b048f2a97991e4e58d4a922

New changeset 7865f516f313bd31ca48ee1fdae2a80add2293b6 by Shantanu in branch 'master':
bpo-16396: fix BPO number in changelog (GH-23951)
https://github.com/python/cpython/commit/7865f516f313bd31ca48ee1fdae2a80add2293b6

New changeset 71d73900ebd4a93a64dae9d2fbef4337fa975e66 by Miss Islington (bot) in branch '3.9':
bpo-16396: fix BPO number in changelog (GH-23951) (GH-23956)
https://github.com/python/cpython/commit/71d73900ebd4a93a64dae9d2fbef4337fa975e66