I've coded in python for >10 years and C# for ~half of that. I prefer indentation-based control flow purely because it condenses code vertically and creates consistent indentation with actual purpose (many of the devs on C# projects I've dealt with have had inconsistent tab/space settings and no linting).

If anything, the one thing I hate about Python3 is dynamic typing - inferring datatypes in function bodies is great but strongly typed (and _enforced_) parameters and return values would clean up a lot of the problems I have seen, and created in the past.

Python does have a lot of problems, but it's so far the most flexible language like English.

High level programming language is meant to communicate, not to dictate the computation. Python happens to be easy to understand by humans.

I don't disagree with anything you've said, but in my opinion strongly typed function definitions/returns are about communication rather than dictation - I'd rather the compiler tell me that I'm passing an unexpected argument type rather than the runtime executor.

But to contradict your point, there's also a fair amount of Python which is a dictation - Guido even called his job role 'Benevolent dictator for life'. I really hated some of the guidelines as a new programmer but after dealing with them for some time I understand that consistency is far more important than preference in many/most/all cases.

Ruby rates much higher on the Englishness scale.

Hmm, I'm not really a fan of indentation based control flow, but I see the appeal of condensing code vertically.

I primarily work with C#, but I've gradually come to like the "K&R"/Javascript style (where the 1st brace is at the end of the first line), precisely because it helps condense code vertically.

1. forget python 2.7 exists

2. can't help with the whitespace, sorry; also take care handling Makefiles

I have worked at places where they insisted on 2 space indention, which made it much much harder to read the code and follow indention levels. It was just stupid of course. That's what really turned me off of python. I know there are bad formatting options for c style languages, and the editor should make it clear. but 2 spaces is too little, too late.

> 1. forget python 2.7 exists

But it doesn't work this way. You don't work strictly with the language itself, you work with the whole ecosystem. Libraries, tools, snippets, SO questions, etc. And many of those are still in 2.7 or at least need to specify different solutions for 2.7... It is still a pain.

> Libraries, tools, snippets, SO questions, etc. And many of those are still in 2.7 or at least need to specify different solutions for 2.7... It is still a pain.

Admittedly there were some libraries that took a long time to switch, but at this point there is no serious library left, that did not make the switch.

Exactly. I've gone farther even, and this is my motto now:

    Python 3.6+ or burn it to the ground

I mself still have to port a few projects yet, but those that got stuck in 2.7-3.5 land are en route to dying a fiery death, and being reborn in 3.6+ (3.8 where applicable, 3.6 as the lowest I'm willing to accept).

Maya is still embedding Python 2.x. Soon (tm)...

Makefiles are half the reason I enable visible whitespace in my editors.

With the new walrus operator you dont need indents anymore. You can write everything in one line in an array:

e.g.

  y=0
  for i in range(10):
      x=i+1
      y=y+x*2
      

can be written as:

  [y:=0] + [[x:=i+1, y:y+x*2] for i in range(10)]

The square brackets are the new curly brackets.

That is evil and wonderful. another reason to love/hate python. I'm working on a project for fun over the holidays and of course I wrote it in python 2.7, and it needs to process unicode so I inflicted double punishment on myself ;-)

My work project just happens to use python 2.7, causing pain for everyone.

As others mentioned, using lambdas this has been possible for ages. There's even a too to auto convert pre walrus code to a single line.

It's just that no one does it.

Braces in Python would have issues, e.g. ambiguity with set/dict literals. Most similar languages (except JavaScript) seem to use begin/end instead. Would that be more acceptable than significant indentation?

Unicode had been the default for 13 years. 2.7 reaches End of Life in less than 2 weeks.

And as for curly braces, try typing:

    python -c "from __future__ import braces" 

In a terminal :)

That wasn't what I expected. I thought it would say all is well! Funny.

When you write in a language which uses curly braces for statement grouping, do you indent your code? ...? I thought so.

Generally not; emacs or VSCode or IntelliJ or whatever does for me.

Does for python, too.

That would have literally made me never look into it in the first place. I would have went with Ruby instead.

UTF-8 is the current default.

It uses unicode but it doesn’t use UTF-8 by default as external encoding and never as internal encoding except for an optional secondary buffer.

What do you mean by "external encoding", "internal encoding", "secondary buffer"?

External encoding: what it reads and writes from and to files

Internal encoding: what the strings are encoded in memory (latin1/UCS2/UCS4 in python)

Secondary buffer: python strings can be encoded twice. They can hold a secondary encoded version if themselves as utf-8.

Encoding strings internally as UTF-8 is a bad idea, since you can't do efficient constant time access (utf-8 isn't fixed width).

Encoding strings internally as UTF-8 is a fine idea, usually you don't need constant-time access to individual code points. E.g. PyPy (faster Python, with JIT) does so. Many other languages also save strings as UTF-8.

And then you have to either re-train them to use string cursors or you have lots of people writing inefficient string code.

Not really, no. PyPy demonstrates that.

Sure it does. Where CPython does byte inflation to make sure random access works, PyPy makes you use an extra indexing structure for cases where you can't just advance one char at a time.

I must say it is a rather elegant way, but it still fits firmly within "a new way or inefficient code".