Steve Dower <steve.do...@python.org> added the comment:
> The current situation is that 100% of the windows includes are lowercase and > allow cross compilation. Please be precise with what you are saying - the "current situation" is only so because you proposed changes and got them merged without proper discussion, and "allow cross compilation" with only one alternate toolset. Pretending this is the status quo is dishonest, so please don't insult me like that. > if mingw-w64 would change to camelcase headers, it would break backwards > compatibility I'm not recommending camel case - I'm recommending matching the casing used for each file in the official SDK (which I agree is a weird mix, but there are certainly compatibility reasons involved in keeping them this way). And yes, it would be a compatibility break for the clones of the SDK, but to a large extent that is their fault for choosing different casing in the first place, so I'm only a little bit sympathetic to that argument. What I'm mostly opposed to is the very weak bug report and the random selection of changes that came with it. Failing to compile on an unsupported toolset is not an immediate "must-fix" issue, and it really ought to go through the affected platform experts so they can confirm acceptable impact on developers who are using the supported tools. There also needs to be this central point so that, assuming we decide to keep them this way, the next person who comes in and complains that the casing doesn't match the actual files is given the correct explanation - otherwise we'll keep switching them back and forth forever. You're also likely to face a maintenance burden for this change, since there is currently no rule or validation that will prevent people from adding properly cased includes in the future (as I hinted, most IDEs on Windows will autocorrect filename casing for headers). If you want one, propose a change to PEP 7 on python-dev, and if it's approved then you can add a build step to validate. Otherwise, you'll have to track changes that are made and fix them as necessary. Without an explicit rule, our default position is "whatever the native target platform/tools prefer". I hope that explains the position a bit better, and why I push back against changes with insufficient justification being provided. At this point, I'm not going to revert these particular changes, as the cases where they will affect native developers are startlingly few these days, but I'm also explicitly saying that this does not mean open-season for all the fixes required for mingw to be happy. Each one will be taken on its merits (primarily compatibility and maintainability), at least until someone has committed to fully support the toolset. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34217> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
