> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com