Chris: > To a very large degree, the rules are and must be the same regardless > of the library/module.
I may not have been clear. I am aware of all kinds of mini-languages such as various forms of regular expressions where some string contains a fairly complex program using existing symbols like [~* and so on with no real relationship to the language being employed. You can often write code using an identical regular expression and use it with functions in Python, Perl, R, C++ and lots of other languages. Similarly, the printf() family has a guiding string that uses symbols like % and : and others as a sort of mini language that is often independent of the language it is being used in. Yes, some languages contain functions that only support a subset of functionality or a superset. For example, some allow you to specify an argument that you want Perl-style matching enhancements. So, no, I do not think what I was talking about is necessarily completely the same as what the main language uses. And another example is how you can sometimes change the underlying language at run time by all kinds of techniques such as replacing built-in functions, and in languages like R, creating all kinds of new functionality as in the pipes I mentioned including brand new top-level operators or back in Python, tricks like making a new class inherit from a standard class that then over-rides and augments or even plays games with multiple inheritance. I will agree that fundamentally the overall infrastructure seems the same. But in my view, some changes step out of the original language. As I have also mentioned, there are ways to get a program to perform calculations in a shared way with two or more languages with data moving back and forth as needed. Definitely that example, which I sometimes use in my programming, literally jumps out of the initial language. -----Original Message----- From: Chris Angelico <ros...@gmail.com> To: python-list@python.org <python-list@python.org> Sent: Thu, Mar 24, 2022 1:37 pm Subject: Re: for convenience 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 -- https://mail.python.org/mailman/listinfo/python-list
