This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author brett.cannon
Recipients brett.cannon, eric.snow, mfwitten, ncoghlan, tim.peters
Date 2016-11-15.19:47:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1479239240.64.0.903037321965.issue28670@psf.upfronthosting.co.za>
In-reply-to
Content
So there's no "promised behavior" that's missing in Python 2.7. If you read PEP 235 it's very clear what platforms it was meant for: cygwin, macOS, and Windows. There's no promise of supporting PYTHONCASEOK for POSIX in general so it isn't as if the PEP is not fully implemented. And even if it was promised, this is a potential breaking change as the semantics of Python 2.7 would shift in a rather key way on certain platforms based on the external factor of PYTHONCASEOK simply being set which someone may have carelessly done. In other words while you view this as a fix for breakage on a platform, I view it as adding support for a certain platform configuration on POSIX which is a new feature.

Since you said this doesn't affect Python 3, I'm closing this as rejected. I appreciate the attempt at a patch, but this is considered a new feature for Python 2.7 which is not open to new features.

In case you choose to submit other patches in the future I'll address your other comments you left about how to test and our development workflow.

To test this what you would basically need to do is detect when the test suite was run on a platform that was case-preserving but case-insensitive and then on such a platform make sure imports worked as expected with and without PYTHONCASEOK set (see the tests that already do this on macOS and Windows).

As for your patchset, I understand your intention, but Python's workflow simply doesn't work the way you want it to. The commit messages that go into version control are set by core developers on purpose to make sure they are formatted as expected and contain the appropriate information. For instance, while your commit messages are very detailed, we tend to askew long commit messages and go for succinct messages that explain the "why" something was done (a paragraph of explanation is itself rare). Your commit messages were also not formatted correctly, e.g. we always list the relevant issue that motivated a change first like "Issue #28670: ...". And lastly, we want commits to represent a single unit of semantic change when possible, so if your work made sense to break up into multiple patches then we would need to open multiple issues for each semantic change to be discussed in isolation and on their own merits. It also makes tracking what semantic changes broke something easier when running a bisection on commits to find the change that broke something (and thus easier to also back out instead of searching for every related commit because it spanned more than one).
History
Date User Action Args
2016-11-15 19:47:20brett.cannonsetrecipients: + brett.cannon, tim.peters, ncoghlan, mfwitten, eric.snow
2016-11-15 19:47:20brett.cannonsetmessageid: <1479239240.64.0.903037321965.issue28670@psf.upfronthosting.co.za>
2016-11-15 19:47:20brett.cannonlinkissue28670 messages
2016-11-15 19:47:20brett.cannoncreate