[Python-Dev] Inconsistent case in directory names for installed Python on Windows
techtonik at gmail.com
Thu May 19 04:33:11 CEST 2011
On Wed, May 18, 2011 at 3:47 PM, Brian Curtin <brian.curtin at gmail.com> wrote:
> On May 18, 2011 7:03 AM, "anatoly techtonik" <techtonik at gmail.com> wrote:
>> While studying `virtualenv` code I've noticed that in Python directory
>> tree `include`, `libs` and `tcl` are lowercased while other dirs are
>> capitalized. It doesn't seem important (especially for developers
>> here), but it still can leave an unpleasant image for people new to
>> Python (and programming in general).
> In theory there are probably a lot of things that might seem unpleasant but
> are actually non-issues. I don't believe there have been any complaints
> about actual unpleasantries with directory case.
Among web folks there are no people who care less about typography
than those who spend most of their time in text terminals. =) I think
that probability of receiving such complaint is very low even if
everybody notices that. "Why should I bother about consistency if
Python developers are not giving damn about it?"
>> │ ├─DLLs
>> │ ├─Doc
>> │ ├─include
>> │ ├─Lib
>> │ ├─libs
>> │ ├─Scripts
>> │ ├─tcl
>> │ └─Tools
>> How about making a consistent lowercased or uppercased scheme? Windows
>> filesystems are case-insensitive, so the change shouldn't affect
> Some Macs have case-sensitive file systems, and some people use
> case-sensitive file systems on various flavors of UNIX. The change would
> probably require a thorough look through the build chain.
But we are speaking only about Windows.
>> Another candidate for
>> normalization is Tools/Scripts dir,
>> which I'd lowercase FWIW:
>> Lowercased dirs on a top level seem to contains files that are
>> relevant to C developers only. However, I can not say for sure. It
>> seems that there could be a better place for them like top level
>> directory named Dev or C-API.
> Overall I think it boils down to a cosmetic change that I'm not sure we need
> to make, which could unnecessarily break people's work. -1
That's right - I started that without cosmetic changes the project
becomes ugly and start to accumulate a lot of garbage. With due
attention to improving an image of Python from perspective of project
layout organization, this change could be made in Python 3. It is
something to keep in mind for the future.
More information about the Python-Dev