For those who are curious, `...` is a placeholder value in Python called Ellipsis. I don't believe it serves any real purpose other than being a placeholder. But it is an object and it implements `__eq__`, and is considered equal to itself. So `...==...` evaluates to `True`. When you prefix a `True` with `-`, it is interpreted as a prefix negation operator and implicitly converts the `True` to a `1`, so `-(...==...)` is equal to `-1`. Then, you add another prefix `-` to turn the `-1` back into `1`.
`--(...==...)--(...==...)` evaluates to `2` because the first block evaluates to 1, as previously mentioned, and then the next `-` is interpreted as an infix subtraction operator. The second `-(...==...)` evaluates to `-1`, so you get `1 - -1` or `2`.
When chaining multiple together, you can leave off the initial `--`, because booleans will be implicitly converted to integers if inserted into an arithmetic expression, e.g. `True - -1` -> `1 - -1` -> `2`.
> There should be one-- and preferably only one --obvious way to do it.
This article is obviously completely tongue-in-cheek, but I feel the need to point out that this sentence is not meant to be a complete inversion of the Perl philosophy of TIMTOWTDI. The word "obvious" is crucial here - there can be more than one way, but ideally only one of the ways is obvious.
pletnes 11 days ago [-]
Numpy actively uses … to make slicing multidimensional arrays less verbose. There are also uses in FastAPI along the lines of «go with the default».
nomel 11 days ago [-]
Expanding on this a little, I will be replacing all occurrences of 2 with two blobs fighting, with shields:
>>> 0^((...==...)--++--(...==...))^0
2
abuckenheimer 11 days ago [-]
excellent explanation, to add to this since I was curious about the composition, '%c' is an integer presentation type that tells python to format numbers as their corresponding unicode characters[1] so
is the expression being evaluated here after you collapse all of the 1s + math formatting each number in the tuple as a unicode char for each '%c' escape in the string corresponding to its place in the tuple.
>> There should be one-- and preferably only one --obvious way to do it.
Except for package management, of course. There, we need lots and lots of ways.
blooalien 11 days ago [-]
And apparently string formatting which should have an ever growing number of ways to handle it. :shrug:
maxloh 11 days ago [-]
You can do this on JavaScript too.
alert(1)
// equals to:
[][(![]+[])[+!+[]]+(!![]+[])[+[]]][([][(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+([][(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[+!+[]+[+!+[]]]+[+!+[]]+([]+[]+[][(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[!+[]+!+[]]])()
If you're curious, the code in ellipsis results in executing:
print('hello, world')
mturmon 11 days ago [-]
Thank you!
I noticed some ** and * in the thing sent to eval(), which (given that the building blocks are small integers) seemed related to prime factorizations.
The initial %c is duplicated 21 times (3*7, if I read correctly), and then string-interpolated (%c%c%c...) against a long tuple of integers. These integers themselves are composed of products of factors combined using * and **.
There is also one tuple "multiplication" embedded within that long tuple of integers -- (a,b)*2 = (a,b,a,b). That is for the 'l' 'l' in "hello".
It's all very clever and amusingly mathy, with a winking allusion to the construction of natural numbers using sets. It made me Godel.
MadVikingGod 11 days ago [-]
This behavior can be replicated with any class that has two special methods:
__neg__ that returns -1 and __sub__ that accepts ints and returns 1-other.
It's not a python thing.
1-(-2), distribute the negative.
qsort 11 days ago [-]
In most C-like languages that would be a syntax error. E.g. in C and C++ as a rule you tokenize "greedily", "1--2" would be tokenized as "1", "unary decrement operator", "2", which is illegal because you're trying to decerment an rvalue.
Python doesn't have "--", which allows the tokenizer to do something else.
nyrikki 11 days ago [-]
In C, that is really because Unary minus (negation) has precedence over binary operations.
+a - b; // equivalent to (+a) - b, NOT +(a - b)
-c + d; // equivalent to (-c) + d, NOT -(c + d)
+-e; // equivalent to +(-e), the unary + is a no-op if “e” is a built-in type
// because any possible promotion is performed during negation already
The same doesn't apply to, !! Which is applied as iterated binary operations (IIRC)
I am pretty sure the decriment operator came around well after that quirk was established.
seanhunter 11 days ago [-]
Peter van der Linden’s book “Expert C Programming” (which is awesome btw) says that one of them (Kernighan, Richie or maybe Ken Thompson I forget) realised early on that the c compiler had the wrong operator precedence for bit twiddling and unary and boolean operators but “at that stage we had a few thousand lines of C code and thought it would be too disruptive to change it”
j2kun 11 days ago [-]
Also worth noting that `1 - -2` works and produces 3 in C because the space breaks the operator.
`--(...==...)--(...==...)` evaluates to `2` because the first block evaluates to 1, as previously mentioned, and then the next `-` is interpreted as an infix subtraction operator. The second `-(...==...)` evaluates to `-1`, so you get `1 - -1` or `2`.
When chaining multiple together, you can leave off the initial `--`, because booleans will be implicitly converted to integers if inserted into an arithmetic expression, e.g. `True - -1` -> `1 - -1` -> `2`.
> There should be one-- and preferably only one --obvious way to do it.
This article is obviously completely tongue-in-cheek, but I feel the need to point out that this sentence is not meant to be a complete inversion of the Perl philosophy of TIMTOWTDI. The word "obvious" is crucial here - there can be more than one way, but ideally only one of the ways is obvious.
'%c' * (length_of_string_to_format) % (number, number, ..., length_of_string_to_format_numbers_later)
is the expression being evaluated here after you collapse all of the 1s + math formatting each number in the tuple as a unicode char for each '%c' escape in the string corresponding to its place in the tuple.
[1] https://docs.python.org/3/library/string.html#format-specifi...
Except for package management, of course. There, we need lots and lots of ways.
I noticed some ** and * in the thing sent to eval(), which (given that the building blocks are small integers) seemed related to prime factorizations.
The initial %c is duplicated 21 times (3*7, if I read correctly), and then string-interpolated (%c%c%c...) against a long tuple of integers. These integers themselves are composed of products of factors combined using * and **.
There is also one tuple "multiplication" embedded within that long tuple of integers -- (a,b)*2 = (a,b,a,b). That is for the 'l' 'l' in "hello".
It's all very clever and amusingly mathy, with a winking allusion to the construction of natural numbers using sets. It made me Godel.
For example if you make this class:
You get similar behavior: Fun python for everyone.Python doesn't have "--", which allows the tokenizer to do something else.
I am pretty sure the decriment operator came around well after that quirk was established.