Coding style

[Antoon Pardon]

On 2006-07-23, Gerhard Fiedler <gelists at gmail.com> wrote:
> On 2006-07-23 06:24:09, Antoon Pardon wrote:
>
>>> In general, I'd say that in this case the example was not well-chosen.
>>> After such a "shudder removal", a poster should IMO review what caused
>>> the shudder, and rephrase the original problem without the shudder.
>> 
>> The shudder is not with the poster. The poster can't predict how the
>> readers will react. 
>
> Correct. But if someone with the potential to help shudders, I might just 
> rephrase my "question" (the code) to suit that person's preferences. Why 
> not?

The point is that the shudder makes people react in an unhelpfull way.
If you think they still can be helpfull and you want to respond in
such a way that makes it more likely they will respond in a helpfull
way, sure go ahead.

>>> That might take a few iterations, but in general, either one or more of
>>> the "shudder removals" actually address the OP's issue, maybe without
>>> any individual helper understanding all of the problem (due to
>>> incomplete example code), or the iterations lead to a code that's
>>> "shudder free" and still shows the original problem -- now usually in a
>>> clearer form, because free of other issues that are not relevant to the
>>> OP's point.
>> 
>> I doubt that. 
>
> I'm not sure, but I've seen in the short time I've been here that a few of 
> the regulars both have their specific "shudder" issues, and post helpful 
> alternative solutions and corrections. So I think it definitely can help to 
> address their "shudder" issues and get this out of the way. 

Sure, but it takes time. Not everyone thinks it is worth that time.

>> My experience is that you have more chance of being helped by people who
>> try to understand where the OP is trying to go form than from those who
>> react to style issues. 
>
> No contest to that. But why not talk to the others, who in a way insist on 
> their idiom but otherwise contribute to helpful solutions, in their idiom?

That is what each person has to decide for by himself. My personal
experience is others usually have come with equally usefull
contributions without losing time harping on Python idiom.
Your milage may vary.

> My view is: I ask for help on a public forum. I get what I get... and if I 
> consider that someone who responded with something that's not immediately 
> helpful has a potential to help me better, I try to get in a dialog and 
> address what has been suggested, carving out my real problem in the idiom 
> of that person. This is my responsibility -- after all, I'm the one who 
> wants to learn how that person would solve my problem. Later then I can try 
> to separate what I want to use from that solution from what I consider 
> personal preference of the helping person.

It all depends. If that person is one of many that responded, I may
think it is not worth my time to find out how this particular person
would solve my problem. If he seems to be the only one who has a clue
I may be more inclined to get that dialog started.

>>> E.g. if someone makes a suggestion that is valid with the example code I
>>> posted but not with the real code I have, I need to post an updated
>>> example code that introduces a restriction similar to the one I
>>> actually have, which then correctly invalidates the formerly valid
>>> suggestion -- and helps getting more helpful responses.
>> 
>> Not necessarily. A valid suggestion doesn't imply a relevant suggestion.
>> 
>> If someone come with code like:
>> 
>>   if Number != 0:
>> 
>> And someone suggests that the python idiom is
>> 
>>   if Number:
>> 
>> Then that suggestion is valid, but it also is irrelevant. 
>
> Correct. But if it helps the person who suggested it to see the original 
> problem, now not hidden (for that person) under offending idiom, then the 
> change was relevant -- not for the problem, but for the communication about 
> it. 
>
> It's like if you want good stock advice from your uncle, who's experienced 
> in the matter but very formal, ask him without using the f*** word. You can 
> use it when asking your other uncle, who's also experienced but doesn't 
> really care about formalities. Tune in if you want a good channel...

That is one side of the coin. The other side is that if the formal
uncle is heard a lot without someone contradicting him from time
to time, then all the newbies will think that formal is the
way to go, creating a lot more people who are somewhat uptight.
causing a lot of time to go into getting things formal instead
of solving the problem.

> I agree that mere aesthetic changes usually don't address the problem in 
> itself. But it's just like posting here in a distant Chinese dialect won't 
> do you any good (and neither in a distant, say, Scottish dialect :). If you 
> want to get up a helpful communication, you need to use the right language. 
> Here it is English and Python :)  and if making my example code more 
> pythonic (and my textual part more English) helps me creating a better 
> communication about the issue I'm interested in, that's what I do (and what 
> I'd recommend everybody else to do). 
>
> If there is a valid reason for a part of the code being different 
> ("non-pythonic"), and that difference may be relevant, then there's a way 
> to show that reason in the example code. It may be that exactly this 
> process of boiling the code down to the relevant pieces shows you the 
> answer. That happens more often than most people realize, and is a process 
> that's quite valuable. 
>
> To apply that to your example... If there's no particular reason to write 
> "number != 0", then just repost the problem code with "number" instead and 
> you're done. But if there's a reason, try to set up your example code so it 
> shows that reason.

This goes against the advise that is given here and in other language and
programming groups: If you have a problem with particular behaviour (a
bug) reduce your program to the minimal that still produces the trouble
some behaviour. 

> This both helps people understand your problem better, 

Sure, but it seems there are people who can tangle the problem without
knowing whether or not there is a reason. They just look at the code
and figure out what it does, whithout bothering about how it should
look like and in the end that is the most helpfull attitude. 

> and may just show the reason for the problem -- after all, you most often 
> than not don't know where exactly your problem is, so you're not in a good 
> position to judge what you can leave out of the code without taking out the 
> problematic part. So: boil down your code to what shows the problem, and 
> nothing more, as much as possible, and present it in an idiom that helps 
> the others to help you. 

I don't know. It seems a waste of time a lot of the times. If I'm
talking with someone in real life about a problem and I get the
feeling that person is more interested in me wording the problem
in the proper formal way instead of caring about the problem itself,
I probably consider not longer bothering this person with my problems
unless there seems to be no alternative.

I think the same applies to newsgroups.

-- 
Antoon Pardon