How to respond to trolling
Was it really necessary for all the usual folks on this list to engage with the "Python review" threads? I think a much more effective response would have been a resounding silence. -- --Guido van Rossum (python.org/~guido)
On 1/10/17 10:43 AM, Ivan Levkivskyi wrote:
I don't like to use the term "trolling" except for people who are trying to annoy people. I think the recent thread was misguided, but not malicious. I do agree that the thread should have ended at "unless you are seriously proposing a change to the language, this is not the right list." --Ned.
If you're proposing throwing half of Python's current syntax in the bin, this isn't the right list either. If not marginally malicious, I think it's delusional to think a post to Language X's lists by someone who recommends multiple breaking changes would ever be accepted. The correct response (if any) would be to use another language or write your own transpiler that better agrees with your aesthetic. Nick
I don't like to use the term "trolling" except for people who are trying to
Whether the intent was to annoy or just to provoke, the effect was dozens of messages with people falling over each other trying to engage the OP, who clearly was ignorant of most language design issues and uninterested in learning, and threw some insults in for good measure. The respondents should have known better. -- --Guido van Rossum (python.org/~guido)
I think that replying with an almost canned response, like the one Ned proposed ("unless you are seriously proposing a change to the language, this is not the right list."), would help discourage other list members from responding where responses aren't necessary. -Ryan Birmingham On 10 January 2017 at 16:58, Guido van Rossum <guido@python.org> wrote:
the effect was dozens of messages with people falling over each other trying to engage the OP,
Sure -- but all in one thread
The respondents should have known better.
But we like to kibitz-- that's why (many of us) are on this list. Anyway, all (most anyway) of the points brought up are : A) not going to change B) have been justified / explained in multiple blog posts, wiki pages, and what have you. So perhaps the best response would be: "These are all fairly core Python design decisions -- do some googling to find out why." But it made me think that it would be good to have a single place that addresses these kinds of thing to point people to. There was the old "python warts" page, but this would be a "python features page" Maybe I'll start that if I find the roundtoits. Or, if it already exists -- someone please point me to it. -CHB
On Wed, Jan 11, 2017 at 12:02 PM, Xavier Combelle <xavier.combelle@gmail.com> wrote:
Personally, when I read the original posting, there is quite a bit of it that comes across as arrogant and ignorant, but none that comes across as insulting. As such, I agree with some of the other replies to this thread: some reply was needed to the original thread. While the thread belonged on python-list, it was also not fully off-topic for python-ideas: while the wording was of a review of Python, and it was not worded as actually suggesting changes, it could be read as indirectly proposing changes or new features. As such, I feel that any reply to the thread should at least aim to point the poster to the correct forum (in this case, python-list), and it is not unreasonable to answer some of the points as though they are in fact suggesting changes - likely with links to the rational of the original decisions, or at least enough information for the original poster to fairly easily find such rationals themselves (eg a tutorial page or faq).
On Tue, Jan 10, 2017 at 07:29:12AM -0800, Guido van Rossum wrote:
Giving a newcomer the Silent Treatment because they've questioned some undocumented set of features not open to change is not Open, Considerate or Respectful (the CoC). Even if their ideas are ignorant or ill-thought out, we must give them the benefit of the doubt and assume they are making their comments in good faith rather than trolling. Shunning is a particularly nasty form of passive-aggression, as the person being shunned doesn't even get any hint as to what they have done to bring it on. It's one thing to ignore an unrepentant troublemaker or troll after numerous warnings -- that's the old Usenet "plonk" or kill-file treatment -- but greeting a newcome who has inadvertently (we must assume good faith) crossed a line in that way is hostile behaviour. I don't think it is necessary for somebody to explicitly say the magic words "I propose this as a change..." for it to be obvious that the OP was suggesting his "review" to initiate a discussion for ways Python should change. I don't know whether the OP has learned anything from his treatment here. But I know he wouldn't learn anything except that the Python community is closed-minded and unwelcoming if he had been greeted with silence. -- Steve
On 1/11/17, Steven D'Aprano <steve@pearwood.info> wrote:
I think that in this case: not all(people) == any(people) So in my humble opinion it is good to say something by some (which reflect CoC culture of python community) and be silent like zen master (and most people did it) by others :) BTW. This discussion could be inspiring and we could prepare PEP where we could give some hints how to do (stupid?) things in unified and clever way! ;) For example: 1. if you want to have endblocks then use "# endfor" instead of "# for" 2. if you want to replace "self" by one letters then use ᐠ (CANADIAN SYLLABICS FINAL GRAVE) see https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html etc. Some editors could probably syntax highlight these constructs (and maybe hide dot too in case of replacing self :P) in future (at least in fancy mode :) ( Some of us could test idea through vi conceal feature for example to http://gnosis.cx/bin/.vim/after/syntax/python.vim insert something like syntax match pyNiceStatement "\<self\." conceal cchar=ᐠ )
Steven D'Aprano writes:
Honest question: do you think that response has to be done in public? (Whether Guido intended "private" as an alternative or not is a red herring, irrelevant to my question.) I would prefer answers at GitHub: https://github.com/python/overload-sig/issues/5. but that's up to respondents. (Will summarize responses privately and in other channels to that issue. This is an experiment for the Overload SIG: https://mail.python.org/mm3/mailman3/lists/overload-sig@python.org/.) Steve
On Wed, Jan 11, 2017 at 02:23:06PM +0900, Stephen J. Turnbull wrote:
"Has to be done in public" in the sense of being mandatory? No. There are pros and cons to both public and private messaging. But in the sense of preferred, yes, I do think so. Private responses could be the idiosyncratic response of a single weirdo who doesn't speak for the community. Public responses that don't get contradicted demonstrate community aggreement, and offer the OP a way to engage if they are willing to ask questions, learn from the answers, and moderate their tone. -- Steve
On 1/10/17 10:43 AM, Ivan Levkivskyi wrote:
I don't like to use the term "trolling" except for people who are trying to annoy people. I think the recent thread was misguided, but not malicious. I do agree that the thread should have ended at "unless you are seriously proposing a change to the language, this is not the right list." --Ned.
If you're proposing throwing half of Python's current syntax in the bin, this isn't the right list either. If not marginally malicious, I think it's delusional to think a post to Language X's lists by someone who recommends multiple breaking changes would ever be accepted. The correct response (if any) would be to use another language or write your own transpiler that better agrees with your aesthetic. Nick
I don't like to use the term "trolling" except for people who are trying to
Whether the intent was to annoy or just to provoke, the effect was dozens of messages with people falling over each other trying to engage the OP, who clearly was ignorant of most language design issues and uninterested in learning, and threw some insults in for good measure. The respondents should have known better. -- --Guido van Rossum (python.org/~guido)
I think that replying with an almost canned response, like the one Ned proposed ("unless you are seriously proposing a change to the language, this is not the right list."), would help discourage other list members from responding where responses aren't necessary. -Ryan Birmingham On 10 January 2017 at 16:58, Guido van Rossum <guido@python.org> wrote:
the effect was dozens of messages with people falling over each other trying to engage the OP,
Sure -- but all in one thread
The respondents should have known better.
But we like to kibitz-- that's why (many of us) are on this list. Anyway, all (most anyway) of the points brought up are : A) not going to change B) have been justified / explained in multiple blog posts, wiki pages, and what have you. So perhaps the best response would be: "These are all fairly core Python design decisions -- do some googling to find out why." But it made me think that it would be good to have a single place that addresses these kinds of thing to point people to. There was the old "python warts" page, but this would be a "python features page" Maybe I'll start that if I find the roundtoits. Or, if it already exists -- someone please point me to it. -CHB
On Wed, Jan 11, 2017 at 12:02 PM, Xavier Combelle <xavier.combelle@gmail.com> wrote:
Personally, when I read the original posting, there is quite a bit of it that comes across as arrogant and ignorant, but none that comes across as insulting. As such, I agree with some of the other replies to this thread: some reply was needed to the original thread. While the thread belonged on python-list, it was also not fully off-topic for python-ideas: while the wording was of a review of Python, and it was not worded as actually suggesting changes, it could be read as indirectly proposing changes or new features. As such, I feel that any reply to the thread should at least aim to point the poster to the correct forum (in this case, python-list), and it is not unreasonable to answer some of the points as though they are in fact suggesting changes - likely with links to the rational of the original decisions, or at least enough information for the original poster to fairly easily find such rationals themselves (eg a tutorial page or faq).
On Tue, Jan 10, 2017 at 07:29:12AM -0800, Guido van Rossum wrote:
Giving a newcomer the Silent Treatment because they've questioned some undocumented set of features not open to change is not Open, Considerate or Respectful (the CoC). Even if their ideas are ignorant or ill-thought out, we must give them the benefit of the doubt and assume they are making their comments in good faith rather than trolling. Shunning is a particularly nasty form of passive-aggression, as the person being shunned doesn't even get any hint as to what they have done to bring it on. It's one thing to ignore an unrepentant troublemaker or troll after numerous warnings -- that's the old Usenet "plonk" or kill-file treatment -- but greeting a newcome who has inadvertently (we must assume good faith) crossed a line in that way is hostile behaviour. I don't think it is necessary for somebody to explicitly say the magic words "I propose this as a change..." for it to be obvious that the OP was suggesting his "review" to initiate a discussion for ways Python should change. I don't know whether the OP has learned anything from his treatment here. But I know he wouldn't learn anything except that the Python community is closed-minded and unwelcoming if he had been greeted with silence. -- Steve
On 1/11/17, Steven D'Aprano <steve@pearwood.info> wrote:
I think that in this case: not all(people) == any(people) So in my humble opinion it is good to say something by some (which reflect CoC culture of python community) and be silent like zen master (and most people did it) by others :) BTW. This discussion could be inspiring and we could prepare PEP where we could give some hints how to do (stupid?) things in unified and clever way! ;) For example: 1. if you want to have endblocks then use "# endfor" instead of "# for" 2. if you want to replace "self" by one letters then use ᐠ (CANADIAN SYLLABICS FINAL GRAVE) see https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html etc. Some editors could probably syntax highlight these constructs (and maybe hide dot too in case of replacing self :P) in future (at least in fancy mode :) ( Some of us could test idea through vi conceal feature for example to http://gnosis.cx/bin/.vim/after/syntax/python.vim insert something like syntax match pyNiceStatement "\<self\." conceal cchar=ᐠ )
Steven D'Aprano writes:
Honest question: do you think that response has to be done in public? (Whether Guido intended "private" as an alternative or not is a red herring, irrelevant to my question.) I would prefer answers at GitHub: https://github.com/python/overload-sig/issues/5. but that's up to respondents. (Will summarize responses privately and in other channels to that issue. This is an experiment for the Overload SIG: https://mail.python.org/mm3/mailman3/lists/overload-sig@python.org/.) Steve
On Wed, Jan 11, 2017 at 02:23:06PM +0900, Stephen J. Turnbull wrote:
"Has to be done in public" in the sense of being mandatory? No. There are pros and cons to both public and private messaging. But in the sense of preferred, yes, I do think so. Private responses could be the idiosyncratic response of a single weirdo who doesn't speak for the community. Public responses that don't get contradicted demonstrate community aggreement, and offer the OP a way to engage if they are willing to ask questions, learn from the answers, and moderate their tone. -- Steve
participants (11)
-
Chris Barker - NOAA Federal -
Chris Kaynor -
Guido van Rossum -
Ivan Levkivskyi -
Ned Batchelder -
Nick Timkovich -
Pavol Lisy -
Ryan Birmingham -
Stephen J. Turnbull -
Steven D'Aprano -
Xavier Combelle