for convenience

[Avi Gross]

Hopefully, adding to what Dave said, it helps to  understand there often are
choices and tradeoffs in everything and in particular to language design.

And choices propagate so that making choice A and B may box you in so at
some point choice Z is pretty much forced unless you start over and make
other choices.

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.

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.

As it happens, Paul used what is not at all the same thing as what he has
seen elsewhere or that made intuitive sense to him but a Python feature that
can (among many other considerations already discussed) effectively
do something similar enough when used carefully.

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.

At some point, you accept it as it IS and work with it an realize the ones you
are talking to think it works fine and gets the job done. My first approach to French 
was to marvel at the weird spelling and how much of it does not seem to get pronounced.
It seemed worse than some other Romance languages in some regards.
But over time, I got used to it. It started to feel natural, not as in THE
right way but as one of many right ways that was right for the situation.

I approach computer languages similarly albeit most were not designed over
many centuries and influenced by invaders and so on. Features of the language
cannot be assumed to be exactly the same as other languages or even assumed
to be consistent in other ways. People have made many categorizations of
such features such as how memory is managed, whether variables that are
first used will default to zero or NULL or the empty string or just generate an error
if not initialized and on and on. You can build sort of decision trees showing
how several languages keep diverging from others in these abstract ways
as you reach a new decision point in such trees and choose a new path.

And interestingly, one reason there are so many languages out there is that people seem
to have chosen quite widely among alternatives. Some older languages that stop
being used may embody decisions that turned out to be too loose or restrictive or
simply because a new language seemed sexier and took over. Often it may be that 
programmers do not like the way it tries to force them to think about what they are
doing or that it makes it hard to do common things ...

So, in a sense, the learning process is worth studying as many facets of a language
that diverge from expectations are either not obvious or were taken after lots of deep
thought by others and make sense only once the person learning it has both learned 
some new things and sort of let go of old 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. It is very common
to have half a dozen ways to do anything, like formatting stuff to print even within the 
base language.

So for many/most people, intuition from other experiences may not be the best guide.
Lots of reading helps, and especially books that spell out some hidden assumptions
such as books written say for C programmers wanting to learn Python which may also
tell you what stuff from C is not carried over, or what work-around is used instead, and
even try to instill a concept of what is deemed Pythonic thinking.

I have interacted offline with Paul (and others here) a bit. Paul is quite intelligent but
also in a somewhat new arena and is learning. Often the best way to learn is by
asking questions and applying the answers. I have had people who assumed a language
passed values to functions by reference and others by value, and yet others who wondered
if there was a way to specify which in a given circumstance. Others assumed it would get
evaluated before the function is called and yet others that it would only get evaluated later.
There are so many such "choices" in how a language might work and I have seen all the
above and more across languages, but generally within a language, you need to ask
what it DOES and then accept that and work with it.

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!


-----Original Message-----
From: Paul St George <email at paulstgeorge.com>
To: python-list at python.org
Sent: Thu, Mar 24, 2022 6:31 am
Subject: Re: for convenience


On 22/03/2022 18.04, dn wrote:



> and thank you - it is refreshing, if not enervating, to receive feedback

> on efforts-expended!

> 

> You will also notice, that now you understand the id() stuff, the

> tag-team effect between @Chris and I (which we have often played, albeit

> not by-design), now makes sense as an whole (if you didn't quite follow,

> earlier).

> 

> 

> My research-topic is Cognitive Psychology (how we learn - albeit not

> usually in Python). I found this conversation useful, and may well apply

> it as an example (with your permission, and suitably anonymised) - one

> doesn't need to be a 'computer person' to follow the logic and thus

> realise the dissonance!

> 

> While learning (this part of) Python and adding to 'previous

> experience', you formed a "mental-model" of how things work (just as we

> all do). However, when it came time to implement this knowledge:

> 

> - you created a 'situation'

> - (all) things didn't 'work' (which also required realisation)

> - you analysed and rationalised (but noted inconsistency)

> - you asked a question (which many of us quickly understood)

> - you've learned/corrected

> 

> 

> The 'issue' is *not* a fault on your part, nor (necessarily) a lack of

> learning or a lack of effort. So, no criticism from me!

> 

> The (under-lying) lesson, is that we (as trainers, but with application

> to all helpers, pair-programmers, mentors, documentation-writers, et al

> - working with less-experienced colleagues) shouldn't spout a whole load

> of 'facts', 'rules', and formulae/s - which we expect to be committed to

> memory. We need to help form a 'correct' mental-model ("correct" being

> defined by the Python interpreter and 'the Python gods' who build it -

> big "thank you" to them!).

> 

> Accordingly, my criticism of tests/exams which require recitation of

> facts ("parroting"), compared with "mastery" (can you actually DO what

> is being asked). More importantly, and finally getting to the point:

> 'tests' should be defined to reveal these (personal) 'quirks' of

> learning/understanding, which led to a 'faulty' mental-model!

> 

> Your rationale made sense, was logical and understandable. How are you

> to know that Python deems it 'wrong'? (until a 'test' shows you!)

> 

> The 'interest' should not be on the people who, and all the 'answers'

> which, were 'correct'. What is more informative, is why someone (aside

> from guessing, ie intelligent, reasonable, after learning the material,

> exerting effort...) got it 'wrong' - but thought his/her path was true!

> -- 

> Regards,

> =dn





Wow, this is super interesting. You have my permission, and please feel free to contact me offline if you want to ask anything.



Yes, I had noticed the tandem with @Chris. I think I needed both! I already have a folder on my Mac called ‘Cameron’. Perhaps I now need an additional folder. Then I can ask my question about whether Python grows to be more like its programmers, or do programmers learn to think Pythonically?





—

Paul St George



-- 

https://mail.python.org/mailman/listinfo/python-list