for convenience

[Chris Angelico]

On Fri, 25 Mar 2022 at 04:15, Avi Gross via Python-list
<python-list at 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