Hacker News Reader

Comment by andybak | Hacker News Reader

Sorry to digress - but the comment in the first code example:

> # or if you don't like backslash continuation

got me thinking. I've always felt backslash continuation is a Python wart - but using brackets in this way only feels like a minor improvement.

It's nearly always this scenario that makes me want to break a line - i.e. splitting a long chained method call on a "."

Now - starting a line of code with a "." is not valid Python as far as I'm aware and therefore allowing it would not introduce any ambiguity or significantly complicate Python's parsing rules. "If a line begins with whitespace followed by "." then consider it as a continuation of the previous line.

Can anyone comment on whether this is a terrible idea or not?

View on HN

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.

Line continuations could be treated by the Lexer.

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.

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.

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.

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.

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

Reply on news.ycombinator.com