[fnands]

They've backed off a little from the Python superset claims and leaned more into "Python family".

> I'd argue that I am not sure what kind of Python programmer is capable of learning things like comptime, borrow checking

One who previously wrote compiled languages ;-). It's not like you forget everything you know once you touch Python.

[amval]

The second part of the sentence is very important ;)

"... but would struggle with different looking syntax"

[oxidi]

I think the point was that Python syntax is simpler than e.g. borrow checking.

Although Python has some seriously PERLesque YOLO moments, like "#"*3 == "###". This is admittedly useful, but funny nonetheless.

[pixelpoet]

I suppose if you accept the innocent-looking "#"+"#"=="##" then your example kind of algebraically follows. Next it's time to define what exp("#") is :)

[mkl]

* does different things depending on the types of the operands, which is Python's strong typing at work, not Perlesque weak typing. Repeating a string is a useful thing to be able to do, and this is a natural choice of syntax for it. The same thing works for lists: [1]*3 == [1, 1, 1].

[int_19h]

It does unfortunately mean that sometimes `*` will work (and produce an incorrect result) rather than immediately failing loudly with a clear error message in the context in which it's actually intended to be numerical.

More broadly this is the same argument as whether overloading `+` for strings is a bad idea or not, and the associated points, e.g. the fact that this makes it non-commutative - the same all applies to `*` as well, and to lists as much as strings. At least Python is consistent here.

Although there is one particular aspect that is IMO just bad design: the way `x += y` and `x = y` work. To remind, for lists these are not equivalent to `x = x + y` and `x = x y` - instead of creating a new list, they mutate the existing one in place, so all the references observe the change. This is very surprising and inconsistent with the same operators for numbers, or indeed for strings and tuples.

[oxidi]

I was referring to the "creative syntax" and it wasn't meant to be an attack on Python.

We cannot deny that Python has some interesting solutions, such as the std lib namedtuple implementation. It's basically a code template & exec().

I don't think these are necessarily bad, but they're definitely funny.