[Python-Dev] PEP 0404 and VS 2010

[Steve Dower]

> 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