Pastebin [was: Trying to make a basic Python score counter in a game... will not count.]

[Chris Angelico]

On Mon, Dec 17, 2012 at 5:47 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Mon, 17 Dec 2012 07:13:44 +1100, Chris Angelico wrote:
>> I don't understand the idea behind the boycott. Are people worried about
>> the longevity of linked-to content, in the event that pastebin should,
>> as you say, cease to exist tomorrow? Or is it that some won't click a
>> pastebin link in case it's abusive? This isn't the sort of abuse that
>> can compromise your computer.
>
> How do you know? Between javascript and flash, just about any browser
> could be vulnerable to just about any website. You might implicitly trust
> Pastebin, but you can't possibly *know* that the site won't do bad
> things. It wouldn't be the first time that even a reputable website got
> hacked by somebody who used it to deploy malware.

Sure, anything can be compromised. But demonstrations that Pastebin
has been used to disseminate illegal information have nothing to do
with that. However...

> But that's not why I dislike Pastebin. I argue against Pastebin because:
>
> 1) Longevity of the content. Your question is going to be around for
> much, much longer than your pastebin. People searching for help will
> click through to the pastebin and find the code is gone. It is really
> frustrating to (say) search for the solution to a problem, and find that
> the answer is given in an expired pastebin.

... ah, that's a much more serious issue. When do they expire? I
didn't find it on the site. Some of the others expire after a VERY
short time (weeks, or even hours), making them completely
inappropriate for this sort of thing. It really needs to be indefinite
duration.

> 2) When you ask for help via email, you shouldn't assume that the people
> reading have access to the web. Perhaps they have email access, but all
> or part of the web is blocked to them. Perhaps they are reading email on
> a mobile device and don't mind paying to download a couple of KB of
> email, but draw the line at (potentially) hundreds of KB of a web page
> plus associated images, unnecessary javascript, web bugs, advertisements,
> etc. Or maybe they just don't want the context switch:
>
> "I'm reading email right now, I'll click the link later..."
>
> Email is a push technology. A pastebin is a pull technology. Whenever you
> require your audience to actively go and get content, you're cutting your
> audience by some fraction.

Yes, I agree. And I'll go further: I don't like having to download an
attached file. Put your code inline; if it's too long for that, it's
probably too long to be asking about.

There are exceptions, of course, but if I'm going to go fetch
components from elsewhere, I have to have already been drawn into the
thread with strong interest. It's a steep hill to climb.

> "Why should I
> have to go out of my way to find out what your question is? You're asking
> me to do you a favour, and you're making me work to find out what the
> favour is???"

Can't argue with that! I agree, other than that I don't swear. :)

> I'm not saying "never use a paste bin". I think it probably makes lots of
> sense to use one in IRC, where it is inappropriate to paste more than a
> line or two of code at once, and the conversation is already ephemeral.
> But in a Usenet or email forum, I think it is almost always inappropriate
> to use paste bins. If your code is too large to paste directly in the
> body of your email, chances are it is too large to expect people to debug
> for you. But you can try adding it as an attachment (.py, not .doc), and
> only if you can't do that for some reason, then maybe a paste bin is
> appropriate.

Yeah, it's good for a MUD too. We use URL shorteners and such, and
aren't too concerned that tinyurl.com might not exist in a few years
(though it is better to use ones that don't expire URLs). But really,
when you're asking for Python help, you shouldn't need to blat tens of
kay of code at us all. It should be possible to put it in-line.

ChrisA