On Sunday, April 3, 2016 at 9:56:24 PM UTC+5:30, Dan Sommers wrote: > On Sun, 03 Apr 2016 08:39:02 -0700, Rustom Mody wrote: > > > On Sunday, April 3, 2016 at 8:58:59 PM UTC+5:30, Dan Sommers wrote: > >> On Sun, 03 Apr 2016 07:30:47 -0700, Rustom Mody wrote: > >> > >> > So here are some examples to illustrate what I am saying: > >> > >> [A vs a, A vs A, flag vs flag, etc.] > > <snip> > >> I understand that in some use cases, flag and flag represent the same > >> English word, but please don't extend that to identifiers in my > >> software. > > > I wonder once again if you are getting my point opposite to the one I > > am making. With ASCII there were problems like O vs 0 -- niggling but > > small. > > > > With Unicode its a gigantic pandora box. Python by allowing unicode > > identifiers without restraint has made grief for unsuspecting > > programmers. > > What about the A vs a case, which comes up even with ASCII-only > characters? If those are the same, then I, as a reader of Python code, > have to understand all the rules about ß (which I think have changed > over time), and potentially þ and others.
Dont get your point. If you know German then these rules should be clear enough to you If not youve probably got bigger problems reading that code anyway As illustration, here is Marko's code few posts back: for oppilas in luokka: if oppilas.hylätty(): oppilas.ilmoita(oppilas.koetulokset) Does it make sense to you? > > > That is why my original suggestion that there should have been alongside > > this > > 'brave new world', a pragma wherein a programmer can EXPLICITLY declare > > #language Greek > > Then he is knowingly opting into possible clashes between A and Α > > But not between A and А. > > If I declared #language Greek, then I'd expect an identifier like A to > be rejected by the compiler. That said, I don't know if that sort of > distinction is as clear cut in every language supported by Unicode. > > And just to cause trouble (because that's the way I feel today), can I > declare > > #γλώσσα Ελληνική > > ;-) > > > [And if you think the above is a philosophical disquisition on > > Aristotle's law of identity: "A is A" you just proved my point that > > unconstrained Unicode identifiers is a mess] > > Can we take a "we're all adults here" approach? Who's the 'we' we are talking about? > For the same reason > that adults don't use identifiers like xl0, x10, xlO, and xl0 anywhere > near each other, shouldn't we also not use A and A anywhere near each > other? I certainly don't want the language itself to [try to] reject > x10 and xIO because they look too much alike in many fonts. When Kernighan and Ritchie wrote C there was no problem with gets. Then suddenly, decades later the problem exploded. What happened? Here's an analysis: Security means two almost completely unrelated concepts - protection against shooting oneself in the foot (remember the 'protected' keyword of C++ ?) - protection against intelligent, capable, motivated criminals Lets call them security-s (against stupidity) and security-c (against criminals) Security-c didnt figure because computers were anyway physically secured and there was no much internet to speak of. gets was provided exactly on your principle of 'consenting-adults' -- if you use it you know what you are using. Then suddenly computers became net-facing and their servers could be written by 'consenting' (to whom?) adults using gets. Voila -- Security has just become a lucrative profession! I believe python's situation of laissez-faire unicode is similarly trouble-inviting. While I personally dont know enough about security to be able to demonstrate a full sequence of events, here's a little fun I had with Chris: https://mail.python.org/pipermail/python-list/2014-May/672413.html Do you not think this could be tailored into something more sinister and dangerous? -- https://mail.python.org/mailman/listinfo/python-list