How is THIS a thing in Python?!

[@sarimbinwaseem]

I'll definitely use (1,)in((1,),) in real world instead of while True....

[@Epinardscaramel]

😊

[@morgengabe1]

pagan

[@herrpez]

"=="=="==" is my go-to for True.

[@innovationsanonymous8841]

Use variables. With single-letter polish prefixes and numeric suffixes. It's better. while t1 in tt1

[@Yvant2000]

Also works with imaginary numbers ! 3jor 1 returns (0 + 3i)

[@MirrorsEdgeGamer01]

Fun fact, the syntax highlining library, that Discords uses, knows about the optional whitespace issue. What this means is that syntax highlighting properly highlights it. I am not sure if this was intentional or not. I am guessing the latter.

[@__Brandon__]

A good follow up video would be about what that guy was doing to get upset over them making it a warning

[@Carberra]

Honestly I was thinking the same thing when I read it! Looks like it's obfuscation work mainly, which I guess is actually a valid, if not bizarre, use case for it. The thread on that issue is pure gold though, reference [5] if you wanna look for yourself!

[@JonnyRobbie]

That guy was upset over a technicality with hilariously linear thinking. He IS technically right that right now, the syntax is supported and I do see his point that you should’n make a warning something that is technically supported. What he failed to realize that the warning has some sort of future (to be made into an error) meaning.

[@Bob-1802]

Reminds me we should read "The zen of Python" few more times 🤗

[@fyellin]

I did a search through a large dictionary of words. There really isn’t anything common except for “decor” and the Russian name “Fedor”.

[@terra_creeper]

I'm not sure why you included the third example here, since I really don't see what is wrong with it. Yes, it's not clean, but it's not any less clean than (1+3)*(2+4) and I haven't seen anybody have issues with that.

[@drdca8263]

1:03 : the third one is just expected behavior? What’s weird about it? 2:48 : ah, ok, yes it is missing the white space, sure

[@TheWarTurkey]

Yea, I thought the 3rd one seemed fine, too.

[@JonathanDenning]

i teach programming languages at university, and i started collecting these a few years ago. i call them coding shenanigans. this is getting added!

[@Carberra]

Care to share a few of your favourites? I'd be interested to know!

[@JonathanDenning]

@Carberra here's one... >>> (False == False) in [False] False >>> False == (False in [False]) False >>> False == False in [False] # what does this print? ???

[@uplink-on-yt]

Fix for shenanigans finds shenanigans in standard library. I'd be angry too.

[@dandyexplorer4252]

Did you write the second example with multiplication symbol instead of 'x'?

[@FN64qHCnbokMG2L]

nope, he's just FaNcY and uses a font with ligatures that prettyprints, so to say, stuff like "0xdeadbeef"

[@Carberra]

I like being FaNcY! But yes, it is ligatures.

[@dandyexplorer4252]

@@Carberra What do you mean? That you wanted people to think it is 'x' and not *?

[@lietpi]

​@@dandyexplorer4252 no, ligatures. A special font feature

[@Nesdac-k1l]

​@@dandyexplorer4252the font they are using has a ligature, which is: when 'x' is in a hexadecimal number, it will be made a little smaller and centred vertically, like '×'. its the same character, the font is just rendering it slightly different. many people (including me) consider this to be a little nicer to read. idk what font it is, but Fira Code does exactly this so it might be that.

[@anon_y_mousse]

That kind of short circuit evaluation annoys me because it does create these weird ambiguities if you're not reading carefully. However, the third example makes perfect sense because (1) will be interpreted as just 1 and (1,) will be evaluated as a tuple containing a single item which is 1. This also really shows the inspiration of early BASIC's in Python's design.

[@phobos.anomaly]

Short circuit evaluation is when B is not evaluated in A or B if A is True. This is not that, it's just some lenient parsing which happens to allow some unfortunate things.

[@anon_y_mousse]

@@phobos.anomaly '0': start of a number; 'x': mode switch to hex number; '_': continuation of a number, used as visual spacing; 'f': hex character, we've now got 15; 'o': not hex, short circuit here, return to normal mode;

[@phobos.anomaly]

@@anon_y_mousse "short circuit evaluation" means a very specific thing in the context of programming languages, and this is not it. Look it up.

[@anon_y_mousse]

@@phobos.anomaly This is one of the contexts in which it is applied.

[@notalakelurk]

​@@phobos.anomaly, this user is complaining about short circuit evaluation, though. Take the first example: `0x_for x in [1, 2, 3]`. There are three parts that python sees here (as you said, leniency): `0x_f`, `or`, and `x in [1, 2, 3]`. Python evaluates `0x_f` to be a non-zero number (i.e. truthy), then it gets to the `or` statement; since it already has a truthy value (0x_f) it short circuits here, never evaluating `x in [1, 2, 3]`.

[@JohanVergeer]

I once had a mathematician in my team that would absolutely love this. It makes the code harder to read and less typing. What more do you want?

[@davidmurphy563]

That thumbnail gave me a headache...

[@andrew_ray]

What happens with `0x_band saw`?

[@Carberra]

It will error unless the variable "saw" is defined as it will check both. If it's defined, it'd be fine though!

[@andrew_ray]

@@Carberra That's wild, because that means Python can't be parsed with a linear parser.

[@zTJq40sl]

@@andrew_ray Evaluating an undefined variable is an error, but not a syntax error. Thus, while I don't know whether Python can be parsed by a linear parser, I don't think the short-circuiting behavior or `and` and `or` has any influence of what parsers can be used, as long as parsing and evaluating are separate steps.

[@andrew_ray]

@@zTJq40sl A linear parser would have no way of knowing that it should stop parsing the hex literal after 0x_b. It would have to tokenize that sequence as "0x_ba/nd/ /saw" which would result in a syntax error since "nd" isn't a valid operator.

[@dandyexplorer4252]

On my PC, when I run it with Python 3.12.0, it gives 'SyntaxError: invalid hexadecimal literal', no matter if 'saw' is defined or not.

[@mage1over137]

So these are basically puns in python

[@isodoublet]

So basically python developers are so traumatized by the 2 -> 3 transition that they're afraid to fix obvious parser bugs

[@Carberra]

Not quite, Python 3.10 introduced features with syntax not possible using LL(1). I think the match statement? Something about the use of soft keywords iirc.

[@isodoublet]

@@Carberra Do any of those changes break previously working code (even if it obviously shouldn't code, as is the case with the examples given in this video)?

[@thisisaplaceholdernamedont6980]

python is clearly not following the zen of python at this point

[@isodoublet]

Never did

[@PixelOutlaw]

Sloppy tokenization.

[@cn-ml]

Sorry, but wtf is a syntax *warning* ?? Either it is correct syntax or it is not. What is going on here?

[@Carberra]

SyntaxWarnings are typically used to warn people of deprecated syntax, and become SyntaxErrors in later versions.

[@phobos.anomaly]

It's syntax that's correct but considered unwanted. What else are C compiler warnings? They're valid constructs that are probably a bad idea and warrant another look.

[@cn-ml]

@phobos.anomaly ah you are right, I totally missed that. In any case I *strongly hoped* that this thing here is unambiguously classified as a syntax error

[@phobos.anomaly]

@@cn-ml Oh I agree, allowing this syntax is bad for everyone (ok except obfuscated code competitions :P). But disallowing it is backwards incompatible, so I get they want to be careful about it. I hope the warning paves the road for turning it into an error in the future.

[@AlexanderVulpes]

SyntaxWarning is a weird concept for a weird situation. It's basically "this syntax is not supposed to be valid, but the interpreter accepts it, and if we make the interpreter raise a SyntaxError like it should, things break"

[@alchenerd]

I don't know what possessed me but here's a funny thing: ``` from warnings import filterwarnings as enemies # We do not overlook enemies enemies('ignore') # Instead, we silence them pledge = bool # Our pledge is resolute pledge(0x_for honor_x0) # The moment of truth: are we people of honor? ```

[@airatvaliullin8420]

Hope this helps :) >>> from pathlib import Path >>> words = Path("common-words.txt").read_text().split(" ") >>> len(words) 5000 >>> HEX_LETTERS = set("abcdef") >>> hex_words = [word for word in words if set(word) >> hex_words ['face', 'feed', 'dead', 'deed']

[@sarimbinwaseem]

Looks cool... need to find common-words.txt file somewhere...

[@airatvaliullin8420]

@sarimbinwaseem Google for "English words txt"!

[@Carberra]

Aah, that's cool! Would be interesting to use that to see how many possible words there actually are (including those that end in "or").

[@aaaaaa2493]

The most memorable for me is 0xCAFEBABE which is first four bytes of the Java class file)

[@desertfish74]

Deadbeef c0dedbad