On Mon, Aug 29, 2016 at 04:24:42PM -0700, Ken Kundert wrote: > > [...] > > Her comment: I did not write it for him. > > [...] > > It has been pointed out to me that the above comes off as being condescending > towards Steven, system administrators and language developers in general. For > this I am profoundly sorry. It was not my intent. My only point was that the > output of these numerical programs are often so highly specialized that only > the > authors and their peers understand it.
No offense taken Ken! I completely understand what your astrophysicist friend means, and I don't expect that she should write code for me. But we have to consider code written for her, and me, and you, and system administrators, children learning their first language, Java gurus, Haskell experts, people whose only other language was BASIC in 1980, animators, scientists, web developers, and many, many other disparate groups of people. We have to do it without breaking backwards compatibility. And some how we have to try to balance all those different needs without compromising the essential "Pythonicity" of the language. The culture of Python is very conservative. I don't know of any features in Python that haven't come from some other language. Sometimes, like significant indentation, it was only a single language at the time that Python copied the feature. Sometimes a feature is not accepted unless it is in widespread use. It's a good sign that unit tracking is (slowly) becoming a language feature, like in F#, but I think you doomed your proposal as soon as you said (paraphrasing) "no other language does this, Python should lead the way and blaze this trail". (That's actually not the case, but when the prior art is niche languages like F# and Frink and calculator languages like RPL, it was always going to be a tough sell.) Sometimes it just means that the time is not right for a new feature. The ternary if operator was resisted for many years until a compelling reason to add it was found, then it was accepted rapidly. Maybe the time will never be right: nearly everyone agrees that there is no reason to actively avoid having multi-statement anonymous lambda functions, if only we can find the right syntax. But nobody has found the right syntax that isn't ambiguous, or goes against the style of Python, or requires changes to the parser that are unacceptible for other reasons. Personally, I think that your proposal has a lot of merit, it's just the details that I don't like. Absent an excellent reason why it MUST be a language feature, it should stay in libraries, where people are free to experiment more freely, or projects like IPython and Sage, that can explore their own interactive interpreters that can add new features that Python the language can't. And maybe, in Python 3.7 or 3.9 or 4.9, somebody will come up with the right proposal, or the right syntax, or notice that (let's imagine) Javascript or C++ has done it and the world didn't end, and Python will get unit tracking and/or multiplicative scaling factors as a language feature and you'll be vindicated. Personally, I hope it does. But it has to be done right, and I'm not convinced your proposal is the right way. So until then, I'm happy to stick to it being in libraries. But most importantly, thanks for caring about this! -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
