This is a peeve of mine, and one of the reasons that I find myself preferring to write javascript these days rather than python. Never would have thought I'd say that.

I'm not up to snuff on my compiler theory, but I think at the least this would require upgrading to a two-token lookahead parser, and it might also upgrade the python grammar from context-free to context-sensitive. Accordingly, I wouldn't expect this to get implemented -- IIRC ease of parsing was/is one of the big design goals.

In python line continuations are a pre-processing step as far as I'm aware (together with inserting INDENT and DEDENT tokens). In the same vein you could just do a simple loop over the token list and remove the appropriate NEWLINE tokens before going to the actual parsing.

Whitespace-sensitive blocks aren't easily parsed either.

Line continuations could be treated by the Lexer.

You can omit the leading 0 before the dot when writing float literals so just a '.1' or any other such sub-1 float literal with no leading 0 is technically a valid but useless line of code starting with a dot (you could use it instead of pass I guess..). I can't think of a real use of a line starting with a dot off the top of my head.

Probably nothing remotely resembling this belongs in anything remotely resembling production code, but:

  In [1]: class Foo:
     ...:     def __rmul__(self, other):
     ...:         print("%s foos!" % other)
     ...:
  
  In [2]: .42 * Foo()
  0.42 foos!

That's very nice. I tried to go for such an example originally but I only tried __mul__ because I thought it's like in Lua where __mul gets used even if only the second operand has a custom one.

Identifiers can't start with a number, so this should still be unambiguous probably?

Sure, that's the only example of line starting with a dot (I think, I'm not super good at Python, just okay) so anything else that isn't a float should be fine.

Pythonistas usually recommend you not use a backslash for continuation. The approach shown on the page is the recommended way, and I find it roughly about as readable as what you suggest. Does using parentheses for continuation trouble anyone?

> Now - starting a line of code with a "." is not valid Python

Absolutely agree. I really like the multi character piping at the end of lines that would get rid of the .

R has %>%

F# uses |> and for functions >>

I would love to see R and all languages just pick up and use F# |>

I think the %x% style is baked into R to differentiate built in and custom infix operators - %>% comes from Tidyverse IIRC.

Originated in the 'magrittr' package. The early tidyverse used a different pipe before depending on magrittr's version.

I don't think so. `%in%` is built into R (or at least in the base package).

I mean, I don't think there is a way to implement |> in R