A desperate lunge for on-topic-ness

Discussion in 'Python' started by Zero Piraeus, Oct 18, 2012.

  1. Zero Piraeus

    Zero Piraeus Guest

    :

    Okay, so, first thing vaguely Python-related that comes to mind [so
    probably not even slightly original, but then that's not really the
    point]:

    What are people's preferred strategies for dealing with lines that go
    over 79 characters? A few I can think of off the bat:

    1. Say "screw it" and go past 79, PEP8 be damned.

    2. Say "screw it" and break the line using a backslash.

    3. Say "well, at least it's not a backslash" and break the line using
    parentheses.

    4. Spend 45 minutes trying to think up shorter [but still sensible]
    variable names to make it fit.

    5. Perform an otherwise pointless assignment to a temp variable on the
    previous line to make it fit.

    6. Realise that if it's that long, it probably shouldn't have been a
    list comprehension in the first place.

    Any I've missed? Any preferences?

    -[]z.
     
    Zero Piraeus, Oct 18, 2012
    #1
    1. Advertising

  2. On Thu, 18 Oct 2012 02:06:19 -0400, Zero Piraeus wrote:

    > What are people's preferred strategies for dealing with lines that go
    > over 79 characters? A few I can think of off the bat:
    >
    > 1. Say "screw it" and go past 79, PEP8 be damned.


    I've been burnt enough by word-wrapping in editors that don't handle word-
    wrapping that well that it makes me really uncomfortable to go over 78-79
    characters, even by only 1 extra. So I don't like doing this.

    Just about the only time I go over is if I have a comment that includes a
    URL with more than 78 characters. I hate breaking URLs more than I hate
    breaking the 79 character limit.


    > 2. Say "screw it" and break the line using a backslash.


    Low on my preference list, but occasionally.


    > 3. Say "well, at least it's not a backslash" and break the line using
    > parentheses.


    I mostly do this. Since most lines include a bracket of some sort, I
    rarely need to add outer parentheses just for the purpose of line
    continuation.

    some_variable = spam('x') + ham(
    some_longer_variables, here_and_here,
    and_here_also)

    I know PEP 8 says I should drop the final round bracket to the next line,
    but I don't normally like that.


    > 4. Spend 45 minutes trying to think up shorter [but still sensible]
    > variable names to make it fit.


    Ha! Since most of my variable names are already relatively short, that's
    not often much help.


    > 5. Perform an otherwise pointless assignment to a temp variable on the
    > previous line to make it fit.


    Hardly ever.

    You missed one:

    5a. Perform an assignment to a temp variable that you really should have
    done anyway, but reducing the number of characters in the line was the
    impetus that finally made you act.


    > 6. Realise that if it's that long, it probably shouldn't have been a
    > list comprehension in the first place.


    What if it wasn't a list comp in the first place? :)

    Refactoring code makes most long lines go away on their own.



    --
    Steven
     
    Steven D'Aprano, Oct 18, 2012
    #2
    1. Advertising

  3. Zero Piraeus

    rusi Guest

    On Oct 18, 11:06 am, Zero Piraeus <> wrote:
    > :
    >
    > Okay, so, first thing vaguely Python-related that comes to mind [so
    > probably not even slightly original, but then that's not really the
    > point]:
    >
    > What are people's preferred strategies for dealing with lines that go
    > over 79 characters? A few I can think of off the bat:


    It really depends on whether one is programming for learning, as a
    profession or publicly (as on this list).

    The third is necessary to say because mailers are going to break long
    lines.
    As for the other two, there is a distinction because:
    For example, a candidate C-programmer would be expected to show
    prowess with pointers in an interview that would be frowned upon when
    he professionally develops in C for production.
     
    rusi, Oct 18, 2012
    #3
  4. Zero Piraeus

    Paul Rubin Guest

    Zero Piraeus <> writes:
    > 2. Say "screw it" and break the line using a backslash.


    Often the line will break ok without a backslash, but I don't feel any
    particular pain in using a backslash in the other cases.

    I do pretty rigorously try to keep all lines shorter than 72 columns or
    so, unless there's a long literal like a url. Even such a literal would
    probably only occur in throwaway code. Any specific url in
    longer-lasting code should probably be read from a configuration file
    rather than being hard coded.
     
    Paul Rubin, Oct 18, 2012
    #4
  5. Zero Piraeus

    Hans Mulder Guest

    On 18/10/12 08:31:51, Steven D'Aprano wrote:
    > On Thu, 18 Oct 2012 02:06:19 -0400, Zero Piraeus wrote:
    >> 3. Say "well, at least it's not a backslash" and break the line using
    >> > parentheses.

    > I mostly do this. Since most lines include a bracket of some sort, I
    > rarely need to add outer parentheses just for the purpose of line
    > continuation.
    >
    > some_variable = spam('x') + ham(
    > some_longer_variables, here_and_here,
    > and_here_also)


    I would spell that as:

    some_variable = spam('x') + ham(
    some_longer_variables,
    here_and_here,
    and_here_also,
    )

    > I know PEP 8 says I should drop the final round bracket to the next line,
    > but I don't normally like that.


    I normally put the final bracket on the next line, where it is
    very visible. Compare:

    if looks_like_it_might_be_spam(
    some_longer_variables,
    here_and_here, and_here_also):
    logger.notice("might be spam")
    move_to_spam_folder(some_longer_variables)
    update_spam_statistics(here_and_here)

    vs.

    if looks_like_it_might_be_spam(
    some_longer_variables,
    here_and_here,
    and_here_also,
    ):
    logger.notice("might be spam")
    move_to_spam_folder(some_longer_variables)
    update_spam_statistics(here_and_here)

    Which one would you say is more readable?


    -- HansM
     
    Hans Mulder, Oct 18, 2012
    #5
  6. Zero Piraeus

    Guest

    Le jeudi 18 octobre 2012 11:07:25 UTC+2, Hans Mulder a écrit :
    > On 18/10/12 08:31:51, Steven D'Aprano wrote:
    >
    > > On Thu, 18 Oct 2012 02:06:19 -0400, Zero Piraeus wrote:

    >
    > >> 3. Say "well, at least it's not a backslash" and break the line using

    >
    > >> > parentheses.

    >
    > > I mostly do this. Since most lines include a bracket of some sort, I

    >
    > > rarely need to add outer parentheses just for the purpose of line

    >
    > > continuation.

    >
    > >

    >
    > > some_variable = spam('x') + ham(

    >
    > > some_longer_variables, here_and_here,

    >
    > > and_here_also)

    >
    >
    >
    > I would spell that as:
    >
    >
    >
    > some_variable = spam('x') + ham(
    >
    > some_longer_variables,
    >
    > here_and_here,
    >
    > and_here_also,
    >
    > )
    >
    >
    >
    > > I know PEP 8 says I should drop the final round bracket to the next line,

    >
    > > but I don't normally like that.

    >
    >
    >
    > I normally put the final bracket on the next line, where it is
    >
    > very visible. Compare:
    >
    >
    >
    > if looks_like_it_might_be_spam(
    >
    > some_longer_variables,
    >
    > here_and_here, and_here_also):
    >
    > logger.notice("might be spam")
    >
    > move_to_spam_folder(some_longer_variables)
    >
    > update_spam_statistics(here_and_here)
    >
    >
    >
    > vs.
    >
    >
    >
    > if looks_like_it_might_be_spam(
    >
    > some_longer_variables,
    >
    > here_and_here,
    >
    > and_here_also,
    >
    > ):
    >
    > logger.notice("might be spam")
    >
    > move_to_spam_folder(some_longer_variables)
    >
    > update_spam_statistics(here_and_here)
    >
    >
    >
    > Which one would you say is more readable?
    >
    >
    >
    >
    >
    > -- HansM


    I use a "double indentation".

    >>> if 'asdf' and 'asdf' and 'asdf' \

    .... 'asdf' and 'asdf' and \
    .... 'asdf' and 'asdf':
    .... print('do if')
    .... s = 'asdf'
    .... ss = 'asdf'
    ....
    do if
    >>> if looks_like_it_might_be_spam(

    .... some_longer_variables,
    .... here_and_here, and_here_also):
    .... logger.notice("might be spam")
    .... move_to_spam_folder(some_longer_variables)
    .... update_spam_statistics(here_and_here)
    ....
    Traceback (most recent call last):

    jmf
     
    , Oct 18, 2012
    #6
  7. On Thu, Oct 18, 2012 at 8:07 PM, Hans Mulder <> wrote:
    >
    > if looks_like_it_might_be_spam(
    > some_longer_variables,
    > here_and_here, and_here_also):
    > logger.notice("might be spam")
    > move_to_spam_folder(some_longer_variables)
    > update_spam_statistics(here_and_here)
    >


    This wants different indentation levels for the condition and the
    code. That'd make it readable enough.

    ChrisA
     
    Chris Angelico, Oct 18, 2012
    #7
  8. Zero Piraeus

    Zero Piraeus Guest

    :

    There seems to be a consensus [to the extent there ever is, anyway]
    around using parentheses etc., then ...

    On 18 October 2012 02:31, Steven D'Aprano
    <> wrote:
    > I've been burnt enough by word-wrapping in editors that don't handle word-
    > wrapping that well that it makes me really uncomfortable to go over 78-79
    > characters, even by only 1 extra. So I don't like doing this.


    I have to admit, I try quite hard not to exceed 78. I don't know why
    [never been bitten by badly behaved editors], but something about 79
    characters in an 80-char window makes me uncomfortable.

    > Just about the only time I go over is if I have a comment that includes a
    > URL with more than 78 characters. I hate breaking URLs more than I hate
    > breaking the 79 character limit.


    Agreed.

    > You missed one:
    >
    > 5a. Perform an assignment to a temp variable that you really should have
    > done anyway, but reducing the number of characters in the line was the
    > impetus that finally made you act.


    Ah. Yes :)

    On 18 October 2012 05:33, <> wrote:
    > I use a "double indentation".
    >
    >>>> if 'asdf' and 'asdf' and 'asdf' \

    > ... 'asdf' and 'asdf' and \
    > ... 'asdf' and 'asdf':
    > ... print('do if')
    > ... s = 'asdf'
    > ... ss = 'asdf'


    Actually, I had a follow-up question about indentation planned. I used
    to double-indent, but am now more likely to go with e.g.

    >>> if check_something(

    .... arg1,
    .... arg2,
    .... arg3
    .... ):
    .... do_something()

    as others have suggested. An alternative would be something like

    >>> if check_something(arg1,

    .... arg2,
    .... arg3):
    .... do_something()

    which I like much less. I have to admit, though, that all the original
    options make me feel a little dirty except (#4) "shorter variable
    names" [which just makes me feel that I am being overly precious] and
    (#6 generalised) "this needs refactoring" [which I would say includes
    Steven's #5a].

    -[]z.
     
    Zero Piraeus, Oct 18, 2012
    #8
  9. Zero Piraeus

    Tim Chase Guest

    On 10/18/12 04:33, wrote:
    > I use a "double indentation".
    >
    >>>> if 'asdf' and 'asdf' and 'asdf' \

    > ... 'asdf' and 'asdf' and \
    > ... 'asdf' and 'asdf':
    > ... print('do if')
    > ... s = 'asdf'
    > ... ss = 'asdf'
    > ...
    > do if
    >>>> if looks_like_it_might_be_spam(

    > ... some_longer_variables,
    > ... here_and_here, and_here_also):
    > ... logger.notice("might be spam")
    > ... move_to_spam_folder(some_longer_variables)
    > ... update_spam_statistics(here_and_here)


    I lean towards double-indent as well, though I favor parens/brackets
    vs. trailing backslashes. My conditions usually go one-per-line,
    too. I also tend to put my closing paren+colon on a stand-alone line:

    if (
    something
    or something_else
    or yet_other_stuff
    ):
    do_thing1()
    do_thing2()

    It's not quite as nice with pure parens, working better with
    function-calls. However, it makes my git/svn diffs easier to read
    when conditions get added/removed because only that line (usually)
    changes, rather than having the noise of the paren moving around.

    In 2.5 and later, I like to write that as

    if any([
    something,
    something_else,
    yet_other_stuff,
    ]):
    do_thing1()
    do_thing2()

    where each item is uniform (one trailing comma, rather than one item
    being special without a comma/or/and) so I don't have the diff noise
    for "or"/"and" bouncing around either.

    Making my diffs easy to read is pretty important to me.

    -tkc

    PS: and in such cases, yes, I often alphabetize my conditions too as
    long as the order doesn't matter. Just a little CDO. That's OCD,
    but in alphabetical order the way the letters should be :)
     
    Tim Chase, Oct 18, 2012
    #9
  10. On 2012-10-18, Zero Piraeus <> wrote:

    > What are people's preferred strategies for dealing with lines that go
    > over 79 characters? A few I can think of off the bat:


    I try to do what's easiest to read and understand. Sometimes that
    means using a line thats 120 characters long, sometimes that means
    breaking up the line.

    --
    Grant Edwards grant.b.edwards Yow! Am I in GRADUATE
    at SCHOOL yet?
    gmail.com
     
    Grant Edwards, Oct 18, 2012
    #10
  11. Zero Piraeus

    Den Guest

    On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
    > :
    >
    >
    > What are people's preferred strategies for dealing with lines that go
    >
    > over 79 characters? A few I can think of off the bat:
    >


    I personally just keep typing until my statement is finished. This is my program, not PEP's.

    But I have to say I'm amused by the whole question, and others related to PEP8. A quick aside, the width of our roads all go back to the width of a two horse rig. The suggested maximum of 80 characters goes back to teletypemachines, and IBM cards, and character based terminals

    Should that really be the basis for a suggested style now?

    Den
     
    Den, Oct 18, 2012
    #11
  12. Zero Piraeus

    Den Guest

    On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
    > :
    >
    >
    > What are people's preferred strategies for dealing with lines that go
    >
    > over 79 characters? A few I can think of off the bat:
    >


    I personally just keep typing until my statement is finished. This is my program, not PEP's.

    But I have to say I'm amused by the whole question, and others related to PEP8. A quick aside, the width of our roads all go back to the width of a two horse rig. The suggested maximum of 80 characters goes back to teletypemachines, and IBM cards, and character based terminals

    Should that really be the basis for a suggested style now?

    Den
     
    Den, Oct 18, 2012
    #12
  13. Zero Piraeus

    Neil Cerutti Guest

    On 2012-10-18, Den <> wrote:
    > But I have to say I'm amused by the whole question, and others
    > related to PEP8. A quick aside, the width of our roads all go
    > back to the width of a two horse rig. The suggested maximum of
    > 80 characters goes back to teletype machines, and IBM cards,
    > and character based terminals
    >
    > Should that really be the basis for a suggested style now?


    I had to use vim's reformatting powers to fix your first
    paragraph. ;)

    http://www.codinghorror.com/blog/2006/06/text-columns-how-long-is-too-long.html

    Code is limited to one column, is left-justified, and
    comprehension is much more important than reading speed. There
    are lots of studies, but they are all about blocks of text, not
    code.

    Though technology has moved along swiftly, keeping your code
    accessible to the guy using a crummy old console xterm might
    still be worthwhile, and it makes printouts easy to create.

    --
    Neil Cerutti
     
    Neil Cerutti, Oct 18, 2012
    #13
  14. On Fri, Oct 19, 2012 at 3:13 AM, Neil Cerutti <> wrote:
    > Though technology has moved along swiftly, keeping your code
    > accessible to the guy using a crummy old console xterm might
    > still be worthwhile, and it makes printouts easy to create.


    And keeping your interface accessible to someone who can't use the
    Home and End keys allows it to be used by someone who's using PuTTY on
    Windows to SSH to a gateway and then SSH from there to a firewalled
    computer that's running your application. And yes, I do exactly that,
    and yes, for some reason Home/End don't always work. One day I'll
    probably figure out what the issue is, but for now, I'm just glad
    there are baseline text editors that don't need such keys...

    Technology moves on, but not everywhere.

    ChrisA
     
    Chris Angelico, Oct 18, 2012
    #14
  15. On 2012-10-18, Den <> wrote:
    > On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
    >
    >> What are people's preferred strategies for dealing with lines that go
    >>
    >> over 79 characters? A few I can think of off the bat:

    >
    > I personally just keep typing until my statement is finished. This
    > is my program, not PEP's.
    >
    > But I have to say I'm amused by the whole question, and others
    > related to PEP8. A quick aside, the width of our roads all go back
    > to the width of a two horse rig. The suggested maximum of 80
    > characters goes back to teletype machines, and IBM cards, and
    > character based terminals
    >
    > Should that really be the basis for a suggested style now?


    You don't expect me to through my Heathkit H19 terminal in the trash,
    do you? :)

    --
    Grant Edwards grant.b.edwards Yow! This is a NO-FRILLS
    at flight -- hold th' CANADIAN
    gmail.com BACON!!
     
    Grant Edwards, Oct 18, 2012
    #15
  16. Hans Mulder wrote:

    > On 18/10/12 08:31:51, Steven D'Aprano wrote:

    > > On Thu, 18 Oct 2012 02:06:19 -0400, Zero Piraeus wrote:

    > >> 3. Say "well, at least it's not a backslash" and break the line using
    > >> > parentheses.

    > > I mostly do this. Since most lines include a bracket of some sort, I
    > > rarely need to add outer parenthesesjust for the purpose of line
    > > continuation.
    > >
    > > some_variable = spam('x') + ham(
    > > some_longer_variables, here_and_here,
    > > and_here_also)

    >
    > I would spell that as:
    >
    > some_variable = spam('x') + ham(
    > some_longer_variables,
    > here_and_here,
    > and_here_also,
    > )
    >

    > > I know PEP 8 says I should dropthe final round bracket to the next line,
    > > but I don't normally like that.

    >
    > I normally put the final bracket on the next line, where it is
    > very visible. Compare:
    >
    > if looks_like_it_might_be_spam(
    > some_longer_variables,
    > here_and_here, and_here_also):
    > logger.notice("might be spam")
    > move_to_spam_folder(some_longer_variables)
    > update_spam_statistics(here_and_here)
    >
    > vs.
    >
    > if looks_like_it_might_be_spam(
    > some_longer_variables,
    > here_and_here,
    > and_here_also,
    > ):
    > logger.notice("might be spam")
    > move_to_spam_folder(some_longer_variables)
    > update_spam_statistics(here_and_here)
    >
    > Which one would you say is morereadable?
    >


    For the first example, I would probably indent the arguments more
    to differentiate a continuing line. That way the "):" does not
    look like it was un-indented to be part of a different block.

    if looks_like_it_might_be_spam(
    some_longer_variables,
    here_and_here, and_here_also):
    logger.notice("might be spam")
    move_to_spam_folder(some_longer_variables)
    update_spam_statistics(here_and_here)


    Ramit Prasad



    This email is confidential and subject to important disclaimers and
    conditions including on offers for the purchase or sale of
    securities, accuracy and completeness of information, viruses,
    confidentiality, legal privilege, and legal entity disclaimers,
    available at http://www.jpmorgan.com/pages/disclosures/email.
     
    Prasad, Ramit, Oct 18, 2012
    #16
  17. Den wrote:

    > On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:

    > > :
    > >
    > >
    > > What are people's preferred strategies for dealing with lines that go
    > >
    > > over 79 characters? A few I can think of off the bat:
    > >

    >
    > I personally just keep typing until my statement is finished. This is my program, not PEP's.
    >
    > But I have to say I'm amused by the whole question, and others related to PEP8. A quick aside, the width of our
    > roads all go back to the width of a two horse rig. The suggested maximum of 80 characters goes back to teletype
    > machines, and IBM cards, and character based terminals
    >
    > Should that really be the basisfor a suggested style now?
    >
    > Den


    Unlike IBM cards and the teletype, character based terminals are still
    widely used (at least in the developer communities). They often default to
    80 characters, but handle various sizes. So that comparison is not quite
    fair.

    Ramit Prasad

    This email is confidential and subject to important disclaimers and
    conditions including on offers for the purchase or sale of
    securities, accuracy and completeness of information, viruses,
    confidentiality, legal privilege, and legal entity disclaimers,
    available at http://www.jpmorgan.com/pages/disclosures/email.
     
    Prasad, Ramit, Oct 18, 2012
    #17
  18. Chris Angelico wrote:

    > On Fri, Oct 19, 2012 at 3:13 AM, Neil Cerutti<> wrote:

    > > Though technology has moved along swiftly, keeping your code
    > > accessible to the guy using a crummy old console xterm might
    > > still be worthwhile, and it makes printouts easy to create.

    >
    > And keeping your interface accessible to someone who can't use the
    > Home and End keys allows it to be used by someone who's using PuTTY on
    > Windows to SSH to a gateway and then SSH from there to a firewalled
    > computer that's running your application. And yes, I do exactly that,
    > and yes, for some reason Home/End don't always work. One day I'll
    > probably figure out what the issue is, but for now, I'm just glad
    > there are baseline text editors that don't need such keys...
    >
    > Technology moves on, but not everywhere.
    >
    > ChrisA
    > --


    Home and end do not bother me much as I can usually use ctrl+a/ctrl+e
    for the same purpose. I do wish I found a better way to page up/down.


    Ramit Prasad

    This email is confidential and subject to important disclaimers and
    conditions including on offers for the purchase or sale of
    securities, accuracy and completeness of information, viruses,
    confidentiality, legal privilege, and legal entity disclaimers,
    available at http://www.jpmorgan.com/pages/disclosures/email.
     
    Prasad, Ramit, Oct 18, 2012
    #18
  19. Zero Piraeus

    Zero Piraeus Guest

    :

    On 18 October 2012 11:55, Den <> wrote:
    > [...] I'm amused by the whole question, and others related
    > to PEP8. A quick aside, the width of our roads all go back to the
    > width of a two horse rig. The suggested maximum of 80 characters goes
    > back to teletype machines, and IBM cards, and character based
    > terminals [...]


    .... and the decisions made back in the day about line length on
    teletypes etc. were informed [perhaps unconsciously] by the rules of
    printed literature - and *those* rules have a *lot* of accumulated
    wisdom behind them.

    Robert Bringhurst's Elements of Typographical Style is very good on
    that stuff; one thing he points out is that, at root, what's
    comfortable is defined by the size of the human hand, the distance we
    hold a book from our eye, etc. ... and while we still live in a world
    composed of physical objects, a lot of that gut feeling about what's
    comfortable carries across into the digital world.

    The accepted rule in print is that lines of prose should be between 45
    and 90 characters, with 66 being ideal for readability. Code is not
    prose, and the combination of fixed-width and much more variable line
    length aids readability, but however it came about, ~80 does seem to
    more or less work as a limit.

    I'm pretty slavish about adhering to PEP 8 these days. Programmers are
    an opinionated bunch, and we all, given the opportunity, will come up
    with our own set of obviously [goddammit] correct rules. Having a
    broadly sensible, authoritative set of guidelines that we grudgingly
    agree to follow makes working with other coders easier IMO.

    -[]z.
     
    Zero Piraeus, Oct 18, 2012
    #19
  20. Zero Piraeus

    Gene Heskett Guest

    On Thursday 18 October 2012 18:40:52 Grant Edwards did opine:

    > On 2012-10-18, Den <> wrote:
    > > On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
    > >> What are people's preferred strategies for dealing with lines that go

    > >
    > >> over 79 characters? A few I can think of off the bat:

    > > I personally just keep typing until my statement is finished. This
    > > is my program, not PEP's.
    > >
    > > But I have to say I'm amused by the whole question, and others
    > > related to PEP8. A quick aside, the width of our roads all go back
    > > to the width of a two horse rig. The suggested maximum of 80
    > > characters goes back to teletype machines, and IBM cards, and
    > > character based terminals
    > >
    > > Should that really be the basis for a suggested style now?

    >
    > You don't expect me to through my Heathkit H19 terminal in the trash,
    > do you? :)


    Or me to delete the vt-220 I wrote to run on a TRS-80 Color Computer
    running OS-9 for an OS, 20 years ago when the Dec made one ate its H.O.T. &
    Dec would not sell me a H.O.T. since it was over 5 years old and wanted
    $2995 for brand new vt-550 (with no guarantee it would be compatible)?

    That, and their field service engineers inability to fix a crashing hourly
    or more PDP-11/723a amply explains why DEC is no longer with us.

    That single obstinate computer made the CBS tv network design a new system
    and distribute it gratis to every network affiliate they had, somewhere
    around 125 stations, at a cost of at least 10G's a station.

    Screw that. I had better things to than throw more good money after bad.
    So did CBS at the time.

    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)
    My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
    How sharper than a hound's tooth it is to have a thankless serpent.
     
    Gene Heskett, Oct 18, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Angelico

    Re: A desperate lunge for on-topic-ness

    Chris Angelico, Oct 18, 2012, in forum: Python
    Replies:
    0
    Views:
    139
    Chris Angelico
    Oct 18, 2012
  2. Demian Brecht

    Re: A desperate lunge for on-topic-ness

    Demian Brecht, Oct 18, 2012, in forum: Python
    Replies:
    0
    Views:
    182
    Demian Brecht
    Oct 18, 2012
  3. Mark Lawrence

    Re: A desperate lunge for on-topic-ness

    Mark Lawrence, Oct 18, 2012, in forum: Python
    Replies:
    0
    Views:
    130
    Mark Lawrence
    Oct 18, 2012
  4. Jean-Michel Pichavant

    Re: A desperate lunge for on-topic-ness

    Jean-Michel Pichavant, Oct 18, 2012, in forum: Python
    Replies:
    2
    Views:
    159
    Demian Brecht
    Oct 19, 2012
  5. Chris Angelico

    Re: A desperate lunge for on-topic-ness

    Chris Angelico, Oct 18, 2012, in forum: Python
    Replies:
    0
    Views:
    147
    Chris Angelico
    Oct 18, 2012
Loading...

Share This Page