posting code snippets

[Mark H. Harris]

hi folks,
Its been too long... can't remember... are there rules here about posting code snippets, or length considerations, and so forth?
Seems like there was a place to share code snips outside of the message area?

A related question, is there a python repository for uploading py files, patches, suggestions, etc?

What is the correct venue protocol for contributing code source?

tnx... happy Thursday!

 

[Chris Angelico]

hi folks,
Its been too long... can't remember... are there rules here about posting code snippets, or length considerations, and so forth?
Seems like there was a place to share code snips outside of the message area?

The convention is to post it in-line, just have it right there in the
body of the email. There's no specific rule on length, but if it goes
over a screenful or two, a lot of people won't bother to read it.

Keeping the code in the message itself is the best way to carry it
around. Not every transmission medium supports attachments, and they
don't cut down on size in any way; and a link to an external resource
creates a dependency. But if your code really is too long to be
practical, you could post it to pastebin or somesuch. It's not as good
as keeping it in the email, but it can work. Do try to make your code
more consumable, though - posting a link to a thousand-line script is
just as useless as embedding it, as nobody will bother to read through
it.

tnx... happy Thursday!

I never could get the hang of Thursdays.

ChrisA

 

[Jerry Hill]

hi folks,
Its been too long... can't remember... are there rules here about posting code snippets, or length considerations, and so forth?

Chris' advice about just posting your code inline with your message is
good. If the problem is that you think your code is too long to post
inline, you're probably right. That means it's probably also too long
for people to give it much attention. If you really want people to
help figure out what is going on with code you don't understand, the
best thing to do is to post a Short, Self Contained, Correct Example
(http://www.sscce.org/). That means cutting the code down to the bare
minimum required to demonstrate your issue. Many times, the very act
of cutting the code down to a digestible chunk will show you the
problem without posting. And if you still don't understand what's
going on, you're much more likely to get help when you present a
problem that can be read in a single screenful or so of code.

A related question, is there a python repository for uploading py files, patches, suggestions, etc?

Assuming this goes beyond posting code for people on the list to look
at, yes, there are lots of places to post python code.

For short bits, Activestate has a repository of python recipes:
http://code.activestate.com/recipes/langs/python/

For publishing full modules and packages, there's the python package
index: https://pypi.python.org/pypi

Patches, bugs and feature requests for the python language itself
belong here: http://bugs.python.org/ attached to an appropriate
tracker issue. Feature requests should probably be raised on the
python-ideas mailing list
(https://mail.python.org/mailman/listinfo/python-ideas) before opening
an issue on the bug tracker.

 

[Mark H. Harris]

Thanks guys, perfect. 'preciate it!

 

[Tim Chase]

are there rules here about posting code snippets, or length
considerations, and so forth? Seems like there was a place to share
code snips outside of the message area?

This is the internet, so you're welcome to post code as you please.
However, be aware that

- if it's on an external site, lots of potential respondants will
shrug with an "I ain't got time for that" or assume that the
code-pasting site won't keep the content around (possibly making
answers useless/contextless in a couple years) and skip it

- if it's inline but too long, lots of potential respondants will
shrug with an "I ain't got time for that" and skip it, or flame you
for filling their mailbox with junk

People here on the list generally enjoy helping where they can, but
are more likely to do so if you've made it as easy possible. So
SSCCEs (as Chris & Jerry mentioned) are your best hope of getting a
useful & friendly reply

-tkc

 

[Mark H. Harris]

Post your code in-line with your message. This is for the sake of the
people whose time you're requesting, and of later readers who will find
the thread when searching the archives -- URLs to snippets are likely to
be invalid later.

Thanks everyone for the great responses.... will do. I read this group frequently, but have not posted for quite some time for time and focus reasons. To tell you just how long, well, my isp withdrew the post service (nntp) from their server at end of 2011... and I didn't notice till now! ha! So, I'm not using seamonkey any longer... using google groups/ and that has been a fit to get used to, but I'm making progress.

:-}

Thanks again

 

[Dave Angel]

my isp withdrew the post service (nntp) from their server at end of 2011... and I didn't notice till now! ha! So, I'm not using seamonkey any longer... using google groups/ and that has been a fit to get used to, but I'm making progress.

You could still use nntp, if you switch to gmane.comp.python.

 

[Chris Angelico]

Since you'll be posting the code in-line, make sure it's short. Since
it'll be short, make sure it's complete — we should need nothing else to
run the code and expect to see the same behaviour you're seeing.

Since you'll be making it short, complete, and still demonstrating the
behaviour, you may even get the result that you understand the cause of
the behaviour before posting it. Everyone wins!

Which is the scientific basis of the astonishingly successful (that
is, it's astonishing to people who don't understand) debugging
technique of Rubber Ducking, or talking to your teddy bear, or other
variants of the subject. (I have a figurine from American McGee's
"Alice: Madness Returns" who is extremely helpful to me. She's pretty,
she's smart, and she's pretty smart.) By the time you've explained it
to someone, you've boiled the problem down into a manageable form, and
that often helps you solve the problem yourself.

The problem does have to believe that the rubber duck/teddy
bear/figurine is an expert, though. I've had my siblings or parents
come to me with problems and, without saying a word or touching the
computer or anything, I've solved them. The problem itself respects my
skill, and retracts its objection and solves itself. Why this works I
am not sure, but just remember to treat your teddy bear as an
intelligent partner in the debugging process, not as an idiot who just
gets in the way. He's a brilliant programmer from another dimension;
he knows all about coding, but not about your code, so you have to
explain its little oddities to him. (Or her. Female teddy bears are
just as good at debugging as male ones are.)

ChrisA

 

[Grant Edwards]

The problem does have to believe that the rubber duck/teddy
bear/figurine is an expert, though. I've had my siblings or parents
come to me with problems and, without saying a word or touching the
computer or anything, I've solved them. The problem itself respects
my skill, and retracts its objection and solves itself.

The same thing works with expensive/complex test equipment instead of
an expert.

You drag out the lab scope, logic analyzer, spectrum analyzer, sweep
generator, strip plotter, and the machine that goes "ping". You start
to get everything set up to nail that problem securely to the
dissecting board. Long before you actually get to that point, the
problem becomes intimidated and reveals itself and a solution.

 

[Gene Heskett]

The same thing works with expensive/complex test equipment instead of
an expert.

You drag out the lab scope, logic analyzer, spectrum analyzer, sweep
generator, strip plotter, and the machine that goes "ping". You start
to get everything set up to nail that problem securely to the
dissecting board. Long before you actually get to that point, the
problem becomes intimidated and reveals itself and a solution.

Chuckle ;-)

Is there not a Murphy's Law corollary on that, Grant? I have certainly
been there and done that enough times to know its 100% true.

Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

 

[Chris Angelico]

You drag out the lab scope, logic analyzer, spectrum analyzer, sweep
generator, strip plotter, and the machine that goes "ping". You start
to get everything set up to nail that problem securely to the
dissecting board. Long before you actually get to that point, the
problem becomes intimidated and reveals itself and a solution.

*ALL* my machines go ping. It's fundamental to network debugging. I
know that's not what you meant, but somehow it comes to the same
thing.

And yep. That is so absolutely right. Problems know when concealment
becomes pointless.

ChrisA

 

[Gregory Ewing]

You drag out the lab scope, logic analyzer, spectrum analyzer, sweep
generator, strip plotter, and the machine that goes "ping". You start
to get everything set up to nail that problem securely to the
dissecting board. Long before you actually get to that point, the
problem becomes intimidated and reveals itself and a solution.

"No! No! Not the comfy spectrum analyser! I give up!"

 

[Gene Heskett]

As a maintenance engineer I find there is also an opposite factor in
operation.
Equipment manufacturers appear to include an "Engineer Proximity
Detector" in all designs that cause the equipment to work flawlessly
when triggered.

The issue the customer has been complaining about incessantly never
occurs whilst there is an engineer on site.

Most sensitive when any cover has been opened. It took me 5 years to find
an intermittent video insert problem in a piece of Chyron gear, and when I
found it, I called the guy at Chyron whose name was on the schematic page
and told him in no uncertain terms that the best part of him ran down his
mothers leg. He'd used a spare gate in a quad nand gate package as an
inverter, a common practice when you need just one more inverter in a
design. Nothing at all wrong with the concept, but the idiot left one of
the two inputs floating, disconnected. That is an absolute no-no in any
digital logic circuit, and will bite somebody on the ass, repeatedly. And
since I could only get at it for not more than 20 minutes at a time because
of its duties, I am ashamed that it took me 5 years to find it when the fix
was half an inch of wire wrapping wire to tie it to the other input pin.

There is not a digital logic chip book on the planet that doesn't contain
warnings about floating inputs.

Yeah, I CAN be one of those to idiots. As Marion Morrison, aka John Wayne
was fond of saying in his movies, stupidity should hurt. And this guy
deserved to hurt.

Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.