This is your periodic reminder that `0xfor....real` is a syntactically-valid AND error-free #Python program
All currently-supported versions of Python optimize this program to an integer constant
@SnoopJ I was trying to work out how it avoided the attribute error, and then realised that entire subexpression was being skipped due to the short circuiting
@SnoopJ how does that get past the parser? And how does it work?
@Atirut it lexes the same as: `0xf or ....real` and the first part of the boolean OR is truthy, so short-circuit returns 15 without ever evaluating the RHS which would lead to an `AttributeError` if evaluated
@SnoopJ ahhhh, I think that's what happens when the lexing logic is "consume until no hex characters" and not "consume until no hex characters AND check if it's a proper token boundary".
@Atirut yep. Modern versions of the runtime emit a SyntaxWarning for this kind of implicit boundary, perhaps it will become an error in the future

@SnoopJ @Atirut
`0xf or ....real` surely?

the first three dots are Ellipsis, so it's equivalent to `0xf or Ellipsis.real`

@sabik @Atirut oops, yes, I transposed those, thanks for the correction
@SnoopJ twenty years ago this would absolutely have become my screen name in something. I’m fighting the urge right now.

@SnoopJ Ha, nice one!

You can also turn it into a function `0xfor` which accepts an arbitrary number of positional arguments (including 0, but no keyword arguments), and always return 15.

```
>>> 0xfor(123, "asdf", {})
15
```

@SnoopJ "bruh" feels like the appropriate response to this
@SnoopJ The 0xf0rd Real

@SnoopJ

% python3
Python 3.11.0 (v3.11.0:deaf509e8f, Oct 24 2022, 14:43:23) [Clang 13.0.0 (clang-1300.0.29.30)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0xfor....real
<stdin>:1: SyntaxWarning: invalid hexadecimal literal
15

So... sort of the Python equivalent of DO10I=1.10 except not?