[Python-Dev] PEP 0404 and VS 2010 (original) (raw)

Steve Dower Steve.Dower at microsoft.com
Fri Nov 22 21:39:51 CET 2013

Martin v. Löwis wrote: Am 22.11.13 19:10, schrieb Steve Dower:

I'd really want to update distutils.msvc9compiler to detect later versions as well, since that would make 'pip install' work properly for a large (majority?) of users for a large (majority?) of packages with extension modules. Some may consider this PEP-worthy (or at least worth arguing about), though I'm happy to just contribute a patch. (Not referring to my existing patch for this - I have a far more compatible approach in mind.) A PEP on 2.7 seems questionable - if this would really need a PEP, it would be right out (IMO). A PEP would ask for community input, weighing possibly different design choices.

Good point. Let's keep this as a patch :)

Instead, I think this needs explicit RM approval, such as any other borderline bugfix patch. I'd personally support it, including any distutils change (assuming the changes "look" backwards-compatible) - but it still would be for Benjamin to rule about it.

There's probably also value in making the same changes to Python 3.4. Perhaps. However, Python 3.4 is likely being replaced before VS 2010 ends its life, and people will be more quick to forward-port to 3.5.

True, though people will still need to match VC versions precisely. I guess we can look at the changes to 2.7 and see how easily they can be ported.

I'm also getting in touch with my colleague who currently owns MSVCRT to figure out the full scope of what may happen once we start allowing mismatched versions in the same process. There used to be an MSDN article about it, but I think it was incomplete. It mentioned (IIRC) a) locale, b) malloc, c) struct FILE. Not sure whether it mentioned CRT file handles, and I'm fairly sure that it didn't mention errno. I also don't think that timezone issues were mentioned (although there used to be a separate article about CRT timezones).

That's basically the complete list. All the other concerns relate to mixing C++ and C, which doesn't apply here.

The advice I've been given on FILE* is that there's probably no way to make it work correctly due to its internal buffering. Unfortunately, there are more places where this leaks through than just the APIs using them - extensions that call os.dup(fd), PyNumber_AsSsize_t() and pass the result to _fdopen() (for example, numpy) are simply going to break with mismatched fd's and there's no way to detect it at compile time. It's hard to tell how wide-ranging this sort of issue is going to be, but it certainly has the potential to break badly...

So if you can get somebody to compile a complete list, publishing it as a KB article would certainly be appreciated beyond the Python project.

A patch for this would be appreciated - perhaps you would want to put it into your sandbox on hg.python.org. I don't have a sandbox - how can I get one? You are not a Python committer yet, are you? If you are, go to hg.python.org/cpython, and invoke the server-side clone. If you are not - does your company agree if you would become one?

Not yet, though I've signed a contributor agreement already. And I have explicit permission to make contributions along these lines. It seems I can make a sandbox clone without any authentication, which is very generous :), but I can't push yet.

Cheers, Steve

In any case, patches or a clone on bitbucket would work just as well.

Regards, Martin

More information about the Python-Dev mailing list