Re: Python

On 16/12/2025 21:12, Left Right via Python-list wrote:
> Nobody should be encouraged to change their editor. Neither do you
> know why the person chose the editor they chose, nor do you actually
> help in solving the problem the person has.

Yes, starting from what the Learner knows, and moving forward is the 
better approach - than throwing-out random advice or a solution which is 
far more sophisticated than the Learner is able to absorb. (to say 
nothing of 'do what I do' or 'please validate my choice by doing the same')


We re-visit the question of 'which editor?' on a fairly regular basis. 
Learning Python (HTML, Haskell, or whatever...) imposes 'cognitive load' 
ie consumes all of one's attention. Accordingly, utilising existing 
(editor) skills enables the Learner to focus on his/her specific, 
stated, aim.

Contrarily, being handed an unfamiliar sophisticated-IDE distracts the 
Learner, who must devote attention to the 'how do I type/correct 
this...' level of thought - in addition to the 'how do I format a 
for-loop?' question which is the important content.

Accordingly, introducing Python Beginners to a simple or no-frills 
editor reduces the extra effort demanded of each.

Sadly, (and you're way-ahead of me here) it also adds a 'technical 
debt', because there comes a time when we all realise that the simple 
editor is probably not 'the best tool for the job'! Thus, following that 
course would result in a pause to the Python-learning whilst the Learner 
turns attention to the 'new' tool. However, if the Learner has come to 
this realisation, then (s)he is motivated to tackle the task (at that 
time) with due attention, and happily justified as part of necessary 
progress!


Is such a plan a bad thing?
Is it a net-positive or a net-negative?
Should we teach tool-skills in the same way as we do Python?
How many professionals do you know who haven't learned (habituated) the 
use of their IDE's facilities despite the powers at their finger-tips?


NB not trying to start a debate between editors and IDEs, or whether 
neovim is better the VS-Codium is better than PyCharm is ...

  > To try to answer to the substance of the complaint about
> indentation-driven structure: when Python was created, the trend in
> formatting of structured text was to eliminate punctuation as much as
> possible. It was (naively) believed that punctuation makes code harder
> to read (it was also the time when various languages with abundant
> (eg. C) or very monotonous (Common Lisp) punctuation were mocked for
> these specific qualities. Some, like in the ALGOL family of languages
> chose to replace punctuation with words (eg. begin procedure X ... end
> procedure), but this was seen as not satisfactory because it drowned
> the important identifiers in the sea of syntactical "noise".

This question is an FAQ. It's a bit like asking 'why aren't we able to 
use French words when speaking Swahili?' or 'why can't I drive on the 
other side of the road?'.

The mistake is not asking the question (if a question, and not a 
statement or demand), but is in failing to realise that this person is 
an individual and new to the thought - whereas we have dealt with many 
others and group them all together.


Given that something like 20% of us are disabled in some way, and many 
involve sight-limitations, perhaps there is another factor? Certainly, 
as I slide into advanced decrepitude, it become more difficult to 
distinguish between square- and curly-brackets, commas and full-stops, 
etc. (and don't get me started on cell-phone apps that won't allow 
enlargement).

Please go for eye-tests on a regular basis!

Perhaps the speed-/touch-typist amongst us don't really notice a 
difference between typing ";" or "end"?


> Python, as well as eg. YAML chose to rely on indentation. This created
> its own set of problems: the more levels of indentation there is, the
> harder it is for a programmer to recognize the structure. This also
> made parsing programs unnecessarily more difficult, since the
> languages were no longer context-free. Moving structural pieces of
> code around became more difficult. At the time, the counter-argument
> was that this restriction also enforces good taste: compelling
> programmers to write shorter functions or other control structures. I
> don't buy this argument because, in practice, a programmer will often
> deal with the code written by another programmer, who didn't
> necessarily want to write short low-complexity bits of code, and will
> suffer the consequences.

Agreeing with (sympathising with) 'the consequences' - but were they 
caused by the language itself, or an architectural/design choice by our 
predecessor?

Per comment, self-contained (SRP) functions with well-chosen and thus 
descriptive-names improve understanding (there's no need to look beyond 
the call - we've read and understood as much as we need). So, perhaps 
they will improve comprehension and shorten the time-needed?

- oh, but we're probably back to 'typing'* if descriptive names involve 
more characters...
* keyboard, not Type Hints

Thoroughly agree that excessive indentation complicates structure. It 
also complicates testing (and debugging). Accordingly, if our esteemed 
predecessor has served up such and we're expected to fix some fault; 
perhaps in order to locate and reproduce, the first thing to do will be 
to untangle the complexity into testable units?

NB no universal rules, situations vary, YMMV, ...


Readers unfamiliar with indentation concerns: please see PEP-0008 advice...
(and pretty much every organisation's Style Guide)


> If there's any conclusion to be drawn from the history of the use of
> punctuation, it seems to me that moderation is more important than the
> selected approach. Selecting multiple approaches at the same time (eg.
> Haskell: both indentation-defined structure and a lot of punctuation)
> gives the worst results overall. Moderate and consistent use of
> punctuation that is still visually diverse enough to identify
> structure (eg. Prolog) is the best, in my view.

+1
This grumpy, ?old, man likes to ask why we are not solving the "=" cf 
"==" issue by utilising one of the Unicode arrows to designate assignment.
(which is answered in the very next paragraph...)


> I believe that the Python creators chose wrong. Was it possible to
> know back in the day? -- I can't tell. From what I know about the
> history of Python, in its early days it wasn't intended for the role
> it plays today. It was more of a teaching aid, not intended for
> serious, large programs. Perhaps its purpose informed the choice. But,
> likely, it was just an accident of following the fashion trends
> without much analysis. You can see this aspect of Python as "technical
> debt", but it's a kind of debt that's unlikely to be ever repaid due
> to a lot of technical difficulties that changing such a decision would
> entail. So, like it or not, the indentation-driven structure will stay
> in Python in the overseeable future.

Yes.
(although maybe not as a teaching aid)

The are web-pages which discuss this. Was there also mention in 'the 
Python video'?

Will leave as an exercise for the (interested) reader...


> On Tue, Dec 16, 2025 at 5:58 AM Greg Ewing via Python-list
> <[email protected]> wrote:
>>
>> Any decent programming editor will have a facility for selecting a group
>> of lines and adding/removing the appropriate commenting characters.
>>
>> (If your editor doesn't have that, then by definition it's not decent. :-)
>> --
>> https://mail.python.org/mailman3//lists/python-list.python.org

--
-- 
Regards,
=dn

-- 
https://mail.python.org/mailman3//lists/python-list.python.org