Or at least, if you do reply to the digest, please change the e-mail subject line to something informative. Regards Antoine. On Mon, 23 Apr 2012 05:01:15 -0700 Chris Rebert wrote:

On Mon, Apr 23, 2012 at 4:10 AM, Hobson Lane wrote: <snip>

...

On Mon, Apr 23, 2012 at 6:00 PM, wrote:

...

Send Python-ideas mailing list submissions to        python-ideas@python.org

To subscribe or unsubscribe via the World Wide Web, visit        http://mail.python.org/mailman/listinfo/python-ideas or, via email, send a message with subject or body 'help' to        python-ideas-request@python.org

You can reach the person managing the list at        python-ideas-owner@python.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-ideas digest..."

Please avoid replying to the digest; it breaks conversation threading. Switch to a non-digest mailing list subscription when not lurking.

Cheers, Chris _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

On Tue, 24 Apr 2012 18:42:24 +0300 anatoly techtonik wrote:

On Mon, Apr 23, 2012 at 3:01 PM, Chris Rebert wrote:

...

On Mon, Apr 23, 2012 at 4:10 AM, Hobson Lane wrote: <snip>

...

On Mon, Apr 23, 2012 at 6:00 PM, wrote:

...

Send Python-ideas mailing list submissions to        python-ideas@python.org

To subscribe or unsubscribe via the World Wide Web, visit        http://mail.python.org/mailman/listinfo/python-ideas or, via email, send a message with subject or body 'help' to        python-ideas-request@python.org

You can reach the person managing the list at        python-ideas-owner@python.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-ideas digest..."

Please avoid replying to the digest; it breaks conversation threading. Switch to a non-digest mailing list subscription when not lurking.

But to reply to a non-digest message you need to receive it in non-digest mode, which didn't happen already. The only way it makes sense is when you ask the Mailman to resend message again. I don't know if that's possible.

Your initial statement is - or at least may be - wrong. If the digest is in one of the well-known formats, a good MUA will let you burst a digest into individual messages and reply to them just like any other message to a list. mh, nmh and GUI's built on top them can do this. I haven't subscribed to a digest of any kind in years, so don't even know if any of my current mail readers can do that. The reason I don't is a different solution to same problem: current mail agents are sufficiently power that I can automatically mark/tag/file all messages to a list and then deal with them outside the normal flow of email, just like a digest. There are other, more esoteric solutions (like the formail program), available as well. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Hell! On Fri, Apr 27, 2012 at 08:45:20AM +0300, anatoly techtonik wrote:

won't install some awkward terminal

"awkward" indeed! Trolling as usual, yeah?

Requirement to "use something proper beforehand" was neither a solution nor an alternative.

It was not a requirement, just an advice. But that was an advice to solve a real problem. Replying to digest brings a lot of problems and thus prevents effective communication. Email, mailing lists and archives don't make sense if they don't help to communicate. And it was only AN advice, not THE advice. Another solution for the same problem would be not to reply to digest. I am sure there are other solutions.

I am not sure that `programs` nowadays makes any sense if you can not access your data from all the entrypionts.

Do you believe - those "awkward" terminal programs works remotely quite fine?! Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

On Fri, 27 Apr 2012 21:12:15 +0300 anatoly techtonik wrote:

On Fri, Apr 27, 2012 at 9:25 AM, Oleg Broytman wrote:

...

Hell! Ok. Let's discuss.

Since I made the suggestion, I'll step in here.

...

On Fri, Apr 27, 2012 at 08:45:20AM +0300, anatoly techtonik wrote:

...

won't install some awkward terminal   "awkward" indeed! Trolling as usual, yeah? You won't win this fight. =)

A truism in any web discussion.

"Awkward (Adjective): Causing difficulty; hard to do or deal with." I can't see that's wrong with that. You don't want to say that installing unknown program and learn how to work with the whole terminal toolchain and syncing your mail archive across nodes is as easy as working with GMail in Chrome, do you?

Yes, it is. The setup process is a relatively straight-forward, one-time-per-node thing. If you're willing to do a little research instead of expecting only using the work of others, you also might be able to avoid the terminal toolchain issues. The GMail web client has a number of problems that crop up over and over again. It's mail marking facilities are subpar, making simply reading mail more difficult than it is on other clients *every time you read mail*. It's mail quoting mechanism is fundamentally broken, require hand-editing the quote *every time you reply to mail*. And, of course, GMail can't burst a digest, meaning you either don't reply to digest posts, fix the headers by hand, or piss other people off - all creating unneeded difficulty *every time you reply to a digest message*. So eventually using only GMail in a web browser will cause more difficulty than setting up a proper mail client. Unless you use read very little mail, in which case - why are you getting the digests?

...

...

Requirement to "use something proper beforehand" was neither a solution nor an alternative.   It was not a requirement, just an advice. But that was an advice to solve a real problem. Replying to digest brings a lot of problems and thus prevents effective communication. Email, mailing lists and archives don't make sense if they don't help to communicate. That's why I prefer Google Groups. You can use email, subscribe as a mailing list, read the web, have a searchable archive and reply to any thread you haven't been subscribed to. Everything from a single interface - no need to carry your mail archive around anymore if you want to search it without 3rd party services. That is my definition of effective communication platform. The constructive advice - research a tutorial how to properly integrate full sync between Mailman and Google Groups and ban usage of digests altogether.

Google Groups is nothing more than a web interface to a netnews system. IIUC, one with a broken news<->mail gateway. It doesn't provide anything that the mail list doesn't provide, except the ability to reply from Google Groups. And that's broken because Google Groups is broken. If you really want to use a news or web interface and reply properly, take the time to find one that doesn't have a broken mail gateway.

...

  And it was only AN advice, not THE advice. Another solution for the same problem would be not to reply to digest. I am sure there are other solutions. Well, sorry for my tone. It seems I've entered "that" favorite style again. Of course, I accept the idea that mh (which is Public Domain and that's awesome) can solve the problem with digest reading, but the story is too exotic for me, and I certainly won't sacrifice features of web based mail services to make sure I can properly reply to digests.

Nobody said you had to make that sacrifice. There aren't any features of generic web based mail services that aren't available in proper mail readers. Sure, mh isn't one of those. But it may not be the only mail reader that can burst a digest. So long as you waste effort trying to change the world rather than changing the part you can change, you'll never find out if that's true or not. And of course, you always have the option of only using mh (or a gui wrapper for same) to read digests. Treating a digest as a single message is awkward enough that the difficulty of setting up mh and a GUI wrapper will be lost in the noise if you read enough digests.

I better won't reply to them at all next time, just because my mail agent doesn't allow. That's my personal choice, but it is also the choice that makes people exclude then they faced with such requirements.

If you chose to act in a way that makes you feel excluded, that's your problem. Sure, it's not the one I want people following, but I'm not going to waste time trying to change your behavior. I'll point out your errors to help other people avoid them, but you can do what you want with that information.

...

...

I am not sure that `programs` nowadays makes any sense if you can not access your data from all the entrypionts.   Do you believe - those "awkward" terminal programs works remotely quite fine?! But I can't use them from my (imaginary) tablet version 3. =)

I could, if I really wanted to. But here you're fundamentally correct - the mh mail readers only have one interaction with mail servers: "Load unread mail". That makes using them in an environment where you want to deal with mail from multiple machines problematical, at best. That's why I quit using them. Of course, there are other mail readers besides GMail that don't have that problem. They also don't have the problems that GMail has. They may well have other problems, but only you can figure out what those are and change the things you can control to best deal with them. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On Mon, Apr 23, 2012 at 10:04 PM, Antoine Pitrou wrote:

On Mon, 23 Apr 2012 19:10:27 +0800 Hobson Lane wrote:

...

Formatted and finished Rebert's solution to this issue

http://bugs.python.org/issue3177

But the question of where to put it is still open ( shutil.open vs. shutil.launch vs. os.startfile ):

1. `shutil.open()` will break anyone that does `from shutil import *` or edits the shutil.py file and tries to use the builtin open() after the shutil.open() definition.

2. `shutil.launch()` is better than shutil.open() due to reduced breakage, but not as simple or DRY or reverse-compatible as putting it in os.startfile() in my mind. This fix just implements the functionality of os.startfile() for non-Windows OSes.

3. `shutil.startfile()` was recommended against by a developer or two on this mailing list, but seems appropriate to me. The only upstream "breakage" for an os.startfile() location that I can think of is the failure to raise exceptions on non-Windows OSes. Any legacy (<3.0) code that relies on os.startfile() exceptions in order to detect a non-windows OS is misguided and needs re-factoring anyway, IMHO. Though their only indication of a "problem" in their code would be the successful launching of a viewer for whatever path they pointed to...

Both shutil.launch() and shutil.startfile() are fine to me. I must admit launch() sounds a bit more obvious than startfile().

I am -1 on shutil.open().

Indeed, my preference is the same (i.e. shutil.launch()). The file isn't being started - an application is being started to read the file. And, despite the existence of os.startfile(), this functionality feels too high level to be generally appropriate for the os module. Cheers. Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia