I think that I disagree. In general (not all the time, but often), things that look different should be different; allowing them to be treated the same is offering beginners a short-time advantage, while preventing them from making, or even understanding, distinctions that they may want to make in the long term. Imagine, for example, a car where both pedals behave the same, and where the actual function is determined by smart traffic-analysis sensors in the car. It would certainly be easier for beginners, but I imagine that it would produce worse drivers; for example, you couldn't drive anyone else's car.
> would you really want to have two different variables called VariableName and variable_name in scope?
Yes, sometimes! (Not that particular example, but there have definitely been cases when I have wanted variables with the same letters in their names but different capitalisations.)
Case-sensitivity is the opposite though: it's making two things that look the same be different. I could maybe support a rule (or even just a linter) that each variable had to be written in a consistent case throughout the project, but two different variables that differ only in case should definitely be disallowed, IMO.
> It would certainly be easier for beginners, but I imagine that it would produce worse drivers; for example, you couldn't drive anyone else's car.
I don't think people buy their cars on the basis of how easy they make it to drive someone else's car, and nor should they.
No it isn't. fooBar and foo_bar have the same words in them, but they look very different.
I can see why you would say that, but (as my comment suggests) I'm with wtetzner (https://news.ycombinator.com/item?id=10932471) on this one: I think that `variable` and `VARIABLE` look different. I am willing to believe, though, that this may just be a result of my training (as a mathematician); my students often genuinely see no difference between `h` and `H` (as variables), for example, and will interconvert freely.
> I don't think people buy their cars on the basis of how easy they make it to drive someone else's car, and nor should they.
I agree, but people often learn to drive with someone else's car, and I think that's the relevant analogy here.
By the way, it occurred to me several hours later that this sounds a lot like HFS's "case preserving" approach, where case is ignored when matching (so that you cannot have a directory with separate files `a` and `A`), but preserved when displaying (so that a file created as `a` will never display as `A`, and vice versa). I don't want to speak for everyone, but my understanding is that this behaviour is regarded as a wart.
That behaviour's very surprising because it means you can e.g. open a file by name, then check its name, and get a different name from the one you opened it under.
What I'm suggesting is equivalent to: variable names are case-sensitive, but it's an error to ever have two variables in scope that differ only in case (maybe only applied when you actually access one - depends on your views on wildcard imports).
Personally I believe code is harder to read than to write, so I favor languages that are easier to read.
Oddly enough, the "we are all consenting adults" attitude works in Python. Most patterns and interfaces are by convention instead of being enforced.
People don't abuse Pythons permissive nature very often, and when they do they are frowned upon by the community. I think such deviations are easier to spot in Python compared to other languages, don't really know why.
I actually would appreciate if someone could provide me one.