LWN: Comments on "Discussing PEP 572"

K9

ceplm — Sat, 24 Mar 2018 12:45:11 +0000

Your help on https://github.com/k9mail/k-9/issues/2615 and https://github.com/k9mail/k-9/issues/769 would be always welcome, I suppose.

Discussing PEP 572

anselm — Thu, 22 Mar 2018 17:59:48 +0000

Obvious perhaps, but the people in charge of Python are understandably reluctant to introduce new keywords, which is always a problem for backwards compatibility.

Discussing PEP 572

welinder — Thu, 22 Mar 2018 17:13:51 +0000

Is there an official rule that things in Python have to look different than the
same thing in other languages?

It's just a let-expression, so calling it "let" would be the obvious thing.

Discussing PEP 572

ssmith32 — Thu, 22 Mar 2018 05:51:30 +0000

This. Is. Awesome. My product manager has been eagerly looking for examples of bikeshedding, ever since I brought up the term.

And debate about an obscure feature that allows for some optimization devolving into a debate over what tools to use to have the debate. I cannot think of a better example....

K9

cortana — Tue, 20 Mar 2018 12:18:56 +0000

It's a pain that it doesn't understand IMAP subscriptions or keywords though...

Discussing PEP 572

Creideiki — Sat, 17 Mar 2018 18:29:26 +0000

In the interest of staving off potential accusations of unfairness, I seem to recall that, last time I was forced to use Outlook, it was possible to beat it into submission enough that it showed messages in a tree. I doubt it had any concept of tree navigation or filtering, and it actively tried to discourage replying properly (a warning saying "It looks like you're not responding to the latest message in the conversation" or some similar nonsense).

Also, I sometimes wonder what the world would have looked like if LysKOM, the world's best messaging system that nobody has ever heard of, had spread beyond Swedish academic computer societies. E-mail-like threads? Check. Forum-like topics? Check. Rich filtering capabilities? Check. Invitation-based closed groups? Check. Clients for every environment you can think of? Check. Integration with other systems? E-mail and RSS are already available, others would be easy to write if you want them. Time-tested? The first public message is from October 1990, and the system is still in use today.

APIs, collaborative functions and social media

lsl — Fri, 16 Mar 2018 23:34:44 +0000

> Forums do offer some more collaborative features compared to mailinglists like up- or down-voting of good responses or tagging. Then there is editing of posts. As a consequence existing "good" forums are providing a better archive of knowledge, by faster access of a summary and relevant arguments.

An "archive" that vanishes when the forum operator gets bored with it. Editing of posts evolves into a plague as soon as people start to use it for something other than fixing obvious typos. You get discussions that no longer make any sense to the reader because someone thought it was a good idea to delete or edit posts. Even benign amendments to a post (clearly labeling any changes) are broken in 99% of forum software as it doesn't send new mail to users subscribed to the topic.

With email, I can actually trust the archive as it's kept on my machines and not subject to the whims of other people.

APIs, collaborative functions and social media

hkario — Fri, 16 Mar 2018 13:34:12 +0000

sure, everything can be done, but there's limited amount of time to do it

and reimplementing a sane interface for every forum one visits (in the dark times when every ML migrated to a forum) will quickly make one insane

Discussing PEP 572

jag — Fri, 16 Mar 2018 10:59:05 +0000

Out of these three:


  stuff = [ (lambda y: [y, y])(f(x)) for x in range(5) ]

  stuff = [ [(f(x) as y), y] for x in range(5) ]

  stuff = [ f(x) as y in [y, y] for x in range(5) ]

I find the third line the easiest to read and understand, though the "in" bit should be allowed to be omitted:


  #while (sock.read() as data in data):
  while (sock.read() as data):
      print("Received data:", data)

(Bike-shedding is fun!)

APIs, collaborative functions and social media

ber — Fri, 16 Mar 2018 09:15:34 +0000

Some forums offer an API via HTTPS, so building custom clients is possible which would enable customization and scripting. They may or may not be easier to adapt than doing a complex setup of an email client. And of course it stays a problem that there is no common standard.

Additional clients usually are only done for very dominant social media platforms. And those platform usually hinder the building of real client alternatives by either technical or legally restricting the use of the API. Other than this, they have the potential to also replace mailinglists or forums.

Forums do offer some more collaborative features compared to mailinglists like up- or down-voting of good responses or tagging. Then there is editing of posts. As a consequence existing "good" forums are providing a better archive of knowledge, by faster access of a summary and relevant arguments.

K9

david.a.wheeler — Thu, 15 Mar 2018 17:44:50 +0000

K9 isn't the be-all of email clients, but it understands threads and PGP. It's OSS and works on Android. Works for me.

Discussing PEP 572

nybble41 — Thu, 15 Mar 2018 17:44:13 +0000

But Python already has something equally capable:

> stuff = [ (lambda y: [y, y])(f(x)) for x in range(5) ]

In general any non-recursive "let" can be replaced with a call to a lambda function with the variables as parameters and their values as arguments.

The introduction of "statement scope" seems a bit odd. In most languages local bindings like this are scoped over the expression, not the enclosing statement. With expression scope you don't get issues with shadowing variables used elsewhere in the statement ("b = (3 as b)"). Expression scope would also eliminate the possibility of circular references like "[(a as b), (b as a)]".

If a dedicated syntax is desired, I would suggest something like:

> stuff = [ f(x) as y in [y, y] for x in range(5) ]

Compared to the lambda form, this has the advantages of placing the variable name near its value and not requiring parentheses. Compared to the PEP, the scope of the binding seems (subjectively) more intuitive, and it becomes easier to reason about the effect: replacing "x" with "x as y in y" should never affect the overall result, even if "y" is used elsewhere in the statement (including in "x").

Discussing PEP 572

peter-b — Thu, 15 Mar 2018 12:35:07 +0000

let, I think

(setq stuff
      (map (lambda (x) (let v (f x) (list v v)))
           (range 5)))

Discussing PEP 572

karkhaz — Thu, 15 Mar 2018 00:43:45 +0000

Thanks for your comment, I'm always interested to read about people's email setups. When you ignore a (sub-)thread with mutt, does that really persist between invocations of mutt? I use mutt and I can't see how this would be true.

After years of fighting clients to make them do what I want, I gave up and now do everything through mailbox manipulation. If I want to ignore a thread, I manually move the message at the root of that thread to a mailbox called "hell". Whenever I get new mail, if that email's References header contains the Message-ID of an email in hell, then a script moves that email to a mailbox called "damned", which I never read. (hell and damned are distinct so that I can keep only a single message of a thread in hell, thus keeping the list of threads to check small). (I also have mailboxes called "purgatory," "blessed," and "heaven" for various other things, and "hell" is also where I mentally consign anybody that suggests that communication should be done over anything other than email or IRC).

This has the advantage that I don't depend on clients to organise my email. I use mutt as a fairly dumb viewer of my mailboxes. If mutt ever stops being maintained, or if I stop being a Luddite and decide to install a mail client on my phone, then I still have the same experience, because my mail sorting is being done on one machine with the scripts that I wrote, and saved back to the IMAP server.

Discussing PEP 572

zblaxell — Wed, 14 Mar 2018 23:54:05 +0000

Most email clients that I don't use have no concept of threads as trees: no way to display an inbox summary as a tree, no way to select branches of the tree for future notification, no way to ignore branches of the tree, no way to navigate the tree (i.e. "read parent", "read replies", "read next sibling"). This makes them useless for technical work. Unfortunately something like 95% of email users use these email clients. After decades of Outlook and GMail, most users are unaware that better email clients even _exist_, so nobody is bothered with trying to improve the incumbents.

Disturbingly, many web forums also lack the tree concept, so even if you interact with one through an email client, you lose the tree structure when someone replies through the forum (or vice versa) because the thread tree metadata is lost every time a message goes through the forum. It turns any issue that has more than a few dozen comments into a useless mass of text with no metadata. People using that kind of forum are quickly forced to split topics up into top-level issues just to work around the forum software, but then the problem morphs into "too many top-level issues to navigate through" instead of "no thread tree metadata to organize discussion" and the root cause of the problem remains unsolved.

Smartphone email clients suck. If the phone can't selectively notify based on arbitrary header fields then it's going to be silent all the time or buzzing continuously. I do participate in mailing lists on my smartphone but I implement the notification filtering at my mail host (and wow the mangling of headers I have to do to get GMail to work with that).

Thunderbird has support for thread trees, but Thunderbird's mail filter language is not able to express rules like "show only new mail that is not ignored by thread and has none of the following three subject lines." It implements a set of non-orthogonal boolean operators that cannot be combined to form a NOR gate, an asymmetric set of message mutation operators that cannot invert the effect of a boolean OR expression, and no support for regular expressions, let alone Perl-compatible ones that could select all three subjects without using the boolean operators. Mutt's search pattern expressions have exactly none of those problems. Thunderbird maintainers did extra work to create them.

Discussing PEP 572

k3ninho — Wed, 14 Mar 2018 23:00:22 +0000

From here, away from this effort, just which part of Common Lisp are they re-implementing?

:-P
K3n.