Re: Python
On 12/16/25 1:12 AM, 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. Well the fact is an editor that does not automate indenting blocks to one degree or another will make Python much more difficult to learn and use, and his experience with Python will not be positive. The editor not making Python indenting easy to manage is in reality the problem the original poster appears to be having. Since Python uses white space as structure, there's no real good way around this, other than using an editor that makes that easier. Thus it's totally appropriate to suggest a better tool. I feel that Python requires at some some form of programmer's editor. Fancy code completion, while useful, is completely optional and not required. Having said all this, I have a feeling Python is not be a good fit for the original poster. -- https://mail.python.org/mailman3//lists/python-list.python.org
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
Re: Python
> Well the fact is an editor that does not automate indenting blocks to > one degree or another will make Python much more difficult to learn and > use, and his experience with Python will not be positive. The editor > not making Python indenting easy to manage is in reality the problem the > original poster appears to be having. Since Python uses white space as > structure, there's no real good way around this, other than using an > editor that makes that easier. Thus it's totally appropriate to suggest > a better tool. No. Again. This is not your place. Not anyone else's to suggest users switch their editor to anything else. What you do is just being a jerk by not admitting the problem with Python and blaming it on the user. It's Python designers that made bad choices that made Python difficult to use in a simple text editor. The authors of the simple text editor have done the right thing by making it simple. Perhaps you are too used to the way Python looks, and see "nothing wrong" with it. But to an outsider this thread reads similar to how a corporate "customer satisfaction" department would try to dismiss customer's complaints by blaming them on the customer misusing the product, while it was obviously the product's fault. The right thing to say is that, unfortunately, Python is this way and due to technical problems will not be fixed. No fixes are planned. If the user prefers to use their editor, they may choose a different language (I mentioned Prolog earlier as an example, but there are plenty more languages with more palatable grammar), or they will have to learn to live with the problem. The user or their equipment is not the cause of the problem. -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Python
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. 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". 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. 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. 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. On Tue, Dec 16, 2025 at 5:58 AM Greg Ewing via Python-list 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 -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Python
On Tue, 16 Dec 2025 17:51:26 +1300, Greg Ewing 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 det. > :-) :.,'as/^/#/ assuming you've marked a. -- https://mail.python.org/mailman3//lists/python-list.python.org
Issues compiling Python 3.14.2 on Rhel 8.10
Hi. I am currently facing issues compiling Python 3.14.2 on my RHEL 8 server. It seems to relate to the --enable-optimizations argument. If I build with out the --enable-optimizations it is finalizing the build, but with the argument, it segfaults during the "test_functools" ./configure not working: ./configure --prefix=/home/easybuild/Python-3.14.2-GCCcore-14.3.0 --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --enable-shared --with-lto --enable-optimizations --with-ensurepip=upgrade Error output: 0:01:04 load avg: 1.61 [17/43] test_fstring passed 0:01:04 load avg: 1.61 [18/43] test_functools Fatal Python error: Segmentation fault Current thread 0x1553af80 [python] (most recent call first): File "/home/easybuild/Python-3.14.2/Lib/test/test_functools.py", line 451 in test_recursive_pickle File "/home/easybuild/Python-3.14.2/Lib/unittest/case.py", line 615 in _callTestMethod File "/home/easybuild/Python-3.14.2/Lib/unittest/case.py", line 669 in run File "/home/easybuild/Python-3.14.2/Lib/unittest/case.py", line 725 in __call__ File "/home/easybuild/Python-3.14.2/Lib/unittest/suite.py", line 122 in run File "/home/easybuild/Python-3.14.2/Lib/unittest/suite.py", line 84 in __call__ File "/home/easybuild/Python-3.14.2/Lib/unittest/suite.py", line 122 in run File "/home/easybuild/Python-3.14.2/Lib/unittest/suite.py", line 84 in __call__ File "/home/easybuild/Python-3.14.2/Lib/unittest/runner.py", line 257 in run File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/single.py", line 84 in _run_suite File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/single.py", line 42 in run_unittest File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/single.py", line 162 in test_func File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/single.py", line 118 in regrtest_runner File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/single.py", line 165 in _load_run_test File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/single.py", line 210 in _runtest_env_changed_exc File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/single.py", line 304 in _runtest File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/single.py", line 348 in run_single_test File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/main.py", line 393 in run_test File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/main.py", line 423 in run_tests_sequentially File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/main.py", line 563 in _run_tests File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/main.py", line 598 in run_tests File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/main.py", line 779 in main File "/home/easybuild/Python-3.14.2/Lib/test/libregrtest/main.py", line 787 in main File "/home/easybuild/Python-3.14.2/Lib/test/__main__.py", line 2 in File "", line 88 in _run_code File "", line 198 in _run_module_as_main Current thread's C stack trace (most recent call first): Binary file "/home/easybuild/Python-3.14.2/libpython3.14.so.1.0", at _Py_DumpStack+0xa3 [0x14c11883] Binary file "/home/easybuild/Python-3.14.2/libpython3.14.so.1.0", at +0x68adaa [0x14c40daa] Binary file "/lib64/libpthread.so.0", at +0x12990 [0x143a8990] Binary file "/lib64/libc.so.6", at _IO_vfprintf+0x1b [0x1389b44b] Binary file "/lib64/libc.so.6", at vsnprintf+0x94 [0x138c3aa4] Binary file "/home/easybuild/Python-3.14.2/libpython3.14.so.1.0", at PyOS_snprintf+0xea [0x14bb058a] Binary file "/home/easybuild/Python-3.14.2/build/lib.linux-x86_64-3.14/_pickle.cpython-314-x86_64-linux-gnu.so", at +0x13084 [0x133a8084] Binary file "/home/easybuild/Python-3.14.2/build/lib.linux-x86_64-3.14/_pickle.cpython-314-x86_64-linux-gnu.so", at +0x1586f [0x133aa86f] Binary file "/home/easybuild/Python-3.14.2/build/lib.linux-x86_64-3.14/_pickle.cpython-314-x86_64-linux-gnu.so", at +0x1ba59 [0x133b0a59] Binary file "/home/easybuild/Python-3.14.2/build/lib.linux-x86_64-3.14/_pickle.cpython-314-x86_64-linux-gnu.so", at +0x15679 [0x133aa679] Binary file "/home/easybuild/Python-3.14.2/build/lib.linux-x86_64-3.14/_pickle.cpython-314-x86_64-linux-gnu.so", at +0x178f7 [0x133ac8f7] Binary file "/home/easybuild/Python-3.14.2/build/lib.linux-x86_64-3.14/_pickle.cpython-314-x86_64-linux-gnu.so", at +0x16820 [0x133ab820] Binary file "/home/easybuild/Python-3.14.2/build/lib.linux-x86_64-3.14/_pickle.cpython-314-x86_64-linux-gnu.so", at +0x1ba7c [0x133b0a7c] Binary file "/home/easybuild/Python-3.14.2/build/lib.linux-x86_64-3.14/_pickle.cpython-314-x86_64-linux-gnu.so", at +0x15679 [0x133aa679] Binary file "/home/easybuild/Python-3.14.2/build/lib.linux-x86_64-3.14/_pickle.cpython-314-x86_64-linux-gnu.so", at +0x178f7 [0x133ac8f7] Binary file "/home/easybuild/Python-3.14.2/build/lib.linux-x86_64-3.14/_pickle.cpython-314-x86_64-linux-gnu.so", at +0x16820 [0x
Re: Python
On Wed, 17 Dec 2025 at 10:33, Left Right via Python-list wrote: > No. Again. This is not your place. Not anyone else's to suggest users > switch their editor to anything else. What you do is just being a jerk > by not admitting the problem with Python and blaming it on the user. > It's Python designers that made bad choices that made Python difficult > to use in a simple text editor. The authors of the simple text editor > have done the right thing by making it simple. Nice of you to accuse someone ELSE of being a jerk. Admins, is there value in continuing to carry this anonymous guy's traffic any more? I don't really see it, personally. ChrisA -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Python
On Tue, 16 Dec 2025 21:45:42 - (UTC), Lawrence D’Oliveiro wrote: > On Mon, 15 Dec 2025 12:57:57 +, mm0fmf wrote: > >> On 14 Dec 2025 11:56:42 GMT, Stéphane CARPENTIER wrote: >> >>> My issues with python are: >>> - It's using indentations, so when I comment a block of code to see >> >> ''' and ''' are your friend > > Unless the block has triply-quoted strings inside it ... Yeah, well. I've been burned more than once by someone who added /* stupid comment */ someplace west of the 80th column in the code. -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Python
On 12/16/25 14:19, Left Right via Python-list wrote: > No. Again. This is not your place. Not anyone else's to suggest users > switch their editor to anything else. This is a mailing list, where advice may be freely given, including about which text editor to use. -- ~Ethan~ Moderator -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Python
> On Dec 16, 2025, at 5:19 PM, Left Right via Python-list
> wrote:
>
>> Well the fact is an editor that does not automate indenting blocks to
>> one degree or another will make Python much more difficult to learn and
>> use, and his experience with Python will not be positive. The editor
>> not making Python indenting easy to manage is in reality the problem the
>> original poster appears to be having. Since Python uses white space as
>> structure, there's no real good way around this, other than using an
>> editor that makes that easier. Thus it's totally appropriate to suggest
>> a better tool.
>
> No. Again. This is not your place. Not anyone else's to suggest users
> switch their editor to anything else. What you do is just being a jerk
> by not admitting the problem with Python and blaming it on the user.
> It's Python designers that made bad choices that made Python difficult
> to use in a simple text editor. The authors of the simple text editor
> have done the right thing by making it simple.
I fully admit that I have not been paying attention to this thread….
But this has been debated to death.
Every Programming language has some sort of structure, it can be {} blocks, the
use of line delimiters, or a thousand other syntax nitpicks that drive people
crazy.
Does that “pardon” python’s? No not really. But it does mean that if you want
to use python, then you either need to get comfortable with it, or use tools
that’ll help prevent a headache.
Unless you are going to convince the python steering council to reverse 20+
years of syntax history, then nothing is going to change.
Some other languages, use white space for structure, just like python. Once
again, that’s not good, nor is that bad.
Any language *has* to have structuring structures to give it structure. That’s
just the way languages are built to convey meaning.
(and yes, that was on purpose).
While not ideal, python using whitespace, is generally fairly easy to
understand. There’s a reason that it hasn’t changed in any
significant manner over the 20+ years.
So, I doubt that anyone is going to be very supportive of your viewpoint
regarding the white space structuring / usage.
As other people have stated, there are plenty of IDE’s, and tools that support
python friendly structuring. Heck even BBEdit, Notepad++, and more have one
button setups that make the editor significantly more python friendly.
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Python
On 16/12/2025 22:19, Left Right via Python-list wrote:
Well the fact is an editor that does not automate indenting blocks to
one degree or another will make Python much more difficult to learn and
use, and his experience with Python will not be positive. The editor
not making Python indenting easy to manage is in reality the problem the
original poster appears to be having. Since Python uses white space as
structure, there's no real good way around this, other than using an
editor that makes that easier. Thus it's totally appropriate to suggest
a better tool.
No. Again. This is not your place. Not anyone else's to suggest users
switch their editor to anything else. What you do is just being a jerk
by not admitting the problem with Python and blaming it on the user.
It's Python designers that made bad choices that made Python difficult
to use in a simple text editor. The authors of the simple text editor
have done the right thing by making it simple.
Perhaps you are too used to the way Python looks, and see "nothing
wrong" with it. But to an outsider this thread reads similar to how a
corporate "customer satisfaction" department would try to dismiss
customer's complaints by blaming them on the customer misusing the
product, while it was obviously the product's fault.
The right thing to say is that, unfortunately, Python is this way and
due to technical problems will not be fixed. No fixes are planned. If
the user prefers to use their editor, they may choose a different
language (I mentioned Prolog earlier as an example, but there are
plenty more languages with more palatable grammar), or they will have
to learn to live with the problem. The user or their equipment is not
the cause of the problem.
Some programming languages use braces {...}, others use words begin...end, and
so on.
However, even in those languages, indentation is still recommended to make the
structure of the code clearer.
No-one's stopping you from using a simple text editor. It's just that an editor
that can auto-indent and has syntax colouring will make your life easier and
let you spot mistakes quicker.
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Python
On 12/16/2025 5:19 PM, Left Right via Python-list wrote: Well the fact is an editor that does not automate indenting blocks to one degree or another will make Python much more difficult to learn and use, and his experience with Python will not be positive. The editor not making Python indenting easy to manage is in reality the problem the original poster appears to be having. Since Python uses white space as structure, there's no real good way around this, other than using an editor that makes that easier. Thus it's totally appropriate to suggest a better tool. No. Again. This is not your place. Not anyone else's to suggest users switch their editor to anything else. What you do is just being a jerk by not admitting the problem with Python and blaming it on the user. It's Python designers that made bad choices that made Python difficult to use in a simple text editor. The authors of the simple text editor have done the right thing by making it simple. Of course one should be able to suggest a change of editor. It's not necessarily being a jerk, it's about trying to be helpful. The OP can say no, and even perhaps say why they don't want to make a change. What *would* be jerk-like would to ignore the OP's reasons for resisting a change and continue to insist that they should be willing. Two helpful abilities for a Python editor are 1) to indent and unindent blocks easily, and 2) to comment and uncomment blocks easily. Both seem to be in play here. Block commenting helps with many languages, not just Python. Managing block indentation is very helpful for readability even for languages that don't make whitespace significant. If the code has a lot of structure, it can be very hard to work through without correct and consistent indentation, for example. So there are good reasons to want those abilities in any editor to be used for programming for all the common languages, not just Python, even if it is otherwise "simple". There is no purpose to be served by labeling helpful advice with the tag "jerk", and also there is no purpose served by calling Python badly designed. Likewise the OP is entitled to their desire as to their working tools, and to their opinion about the design or suitability of Python. Regular users will have their own ideas about the latter and may not agree. -- https://mail.python.org/mailman3//lists/python-list.python.org
