On Fri, 25 Mar 2022 at 04:15, Avi Gross via Python-list <python-list@python.org> wrote: > Python made lots of choices early on and then tried to graft on ever more > features, sometimes well and sometimes not optimally. The same is true > for so many other languages. A carefully designed new language built now > might analyze and make changes.
This is technically true, but it's important to keep in mind that it's very difficult to understand the reasons behind all the choices in a language, so if you were to craft your own language now, you would run the risk of throwing away *good* decisions too. > I would even argue that a new language might deliberately include a > pre-processor that works more like Paul first assumed, perhaps as > something that could be turned on and off so it only operated on designated > sections or only when some command-line switch asked for it. Some might > use that, especially if migrating code from a language that had used similar > constructs. But preprocessors work best in compiled code where it is > reasonable > to make multiple passes across a changing text but not so much in an > interpreted environment that tries to read and parse things once or in small > defined chunks dynamically evaluated. No, I would say that a preprocessor of that sort isn't necessary to a Python-like language. If you really want one, it's honestly not that hard to do; remember, "preprocessor" means that it processes the source code before the main language sees it, so you can do that even with Python as it currently is. But I suggest that a naive preprocessor like C's wouldn't be of much benefit. Much more interesting is the possibility of designing a language with a proper grammar, which you then compile to Python code and execute. (Part of the reason that a naive preprocessor wouldn't work well is that it would play very badly with dynamic lookups. Good luck making those work with a source-code transformation.) > But Languages, human as well as computer, can differ widely and yet seem > natural enough to most humans who grew up with them. One of my first human > languages is not big on "gender" and many sentences are exactly the same no > matter if it was being done by a male or female or anything else. So when I > later > learned German with tons of grammar that included three genders, that was > annoying. > Later I learned English and it seemed more civilized to me but in some ways > not. > Is there really a right way to say put verbs first versus last or place > adjectives > before versus after what they modify? Well every darn language I learn has > differences in these ways including exceptions and special cases galore. And > even the choice of genders for words like "ship" or "road" vary widely across > languages. You either memorize or give up, or more likely, make lots of small > mistakes that mark you as a non-native speaker. Yes, and despite what some people try to claim, they're not just all the same thing with different symbols :) Languages ARE different, different in real ways that make them good at different things. > Languages like Python are actually a bit more of a challenge. Like many modern > languages that have been overhauled to support multiple programming > methods/styles > (like object-oriented and functional programming) and that have been extended > with > endless add-ons with names like modules and packages, it seems anything you > learn > may turn out to be "wrong" in the sense that others write code completely > differently > than you first expected. You may learn base Python and think you use lists > for all > kinds of things and maybe even lists of lists to emulate matrices, for > example. > > Then one day someone shows you a program done almost completely using modules > like numpy and pandas and scipy and so on with bits and pieces of what looks > like > python to glue it together. Some add-ons define entirely new mini-languages > whose > rules only make sense within narrow areas and do not generalize. To a very large degree, the rules are and must be the same regardless of the library/module. > It is very common > to have half a dozen ways to do anything, like formatting stuff to print even > within the > base language. That's because formatting things into strings is such an incredibly broad subject that it's best handled in multiple ways :) You could equally say that there are half a dozen ways to do arithmetic, which there are (or even more, in fact). > This reminds me too much of a recent debate here on whether the word "ELSE" > means one > thing versus another in a new context and I think we had to agree to > disagree. Clearly > some of us are primed to see it one way and some the other and neither of > them is right > but also there is NOW a right way to view the construct within Python because > it is what it > is so get over it! I think "if/else" and "try/else" are close enough that nobody should have any concerns about it, and that "for/else" is only confusing because people have an expectation that isn't supported by *any language I have ever used*. If people said "hey, I don't know what for/else should do", that would be fine, but since people say "why doesn't for/else do what I expect it to", it's very hard to explain, since it's nearly impossible to figure out people's preconceptions, since they can't even be explained by other languages' semantics. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
