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
