Spaces and tabs again

Discussion in 'Python' started by bearophileHUGS, Aug 13, 2005.

  1. Hello, I know this topic was discussed a *lot* in the past, sorry if it
    bores you...
    Benchmark:
    http://www.fourmilab.ch/fourmilog/archives/2005-08/000567.html

    This is the source pack:
    http://www.fourmilab.ch/fbench/fbench.zip

    I've read its Python sourcecode, probably there few things that can be
    changed to speed it up some (like moving the main code in a function,
    using Psyco, or even vectorizing it with numarray), but I've had
    problems in changing the code because it mixes tabs and spaces for the
    indentations.
    I like a lot how Python uses indentations, I've never had problems with
    them in my programs, but I have big problems when I find a source that
    mixes them (I often need time to find how much spaces a tab is, to try
    to convert them all in spaces).
    I know that some people likes tabs, and other people likes spaces, so
    probably a single standard cannot be enforced, but I think the python
    compiler must generate an error (and stop compiling) when the
    sourcecode of a module contains both spaces and tabs to indent the
    lines of code (and comments lines too?).

    Bye,
    bearophile
     
    bearophileHUGS, Aug 13, 2005
    #1
    1. Advertisements

  2. Hallöchen!

    I think the interpreter option -tt does this but I've never used it.

    I agree that mixing spaces and tabs is a bad thing. Unfortunately,
    my default Emacs configuration did so, whyever. I changed it a
    couple of days ago. However, the PEP 8 strongly dicourages it
    anyway.

    Tschö,
    Torsten
     
    Torsten Bronger, Aug 13, 2005
    #2
    1. Advertisements

  3. bearophileHUGS

    Jeff Schwab Guest


    What's wrong with mixing spaces and tabs? Either way, it's pretty easy
    to convert back & forth. In Vim:

    :set expandtab
    :%retab
     
    Jeff Schwab, Aug 13, 2005
    #3
  4. bearophileHUGS

    Aahz Guest

    Python 3.0 will prohibit tabs.
     
    Aahz, Aug 13, 2005
    #4
  5. bearophileHUGS

    sigzero Guest

    Aahz wrote:
    Are you kidding? You are going to MANDATE spaces?

    Robert
     
    sigzero, Aug 13, 2005
    #5
  6. Actually, future whitespace rules will be extensive. See:
    http://64.233.187.104/search?q=cache:k1w9oZr767QJ:www.artima.com/weblogs/viewpost.jsp?thread=101968
    (google cache of
    http://www.artima.com/weblogs/viewpost.jsp?thread=101968 because it
    seems to be down at the moment)

    The only change from April 1, 2005 is that the enforcement is punted
    until Python 3.0, because of the source-incompatible nature of the change.

    "Lrf, vg'f na Ncevy Sbbyf' wbxr.".decode('rot13')
     
    Christopher Subich, Aug 13, 2005
    #6
  7. bearophileHUGS

    Jeff Schwab Guest

    Downright unpythonic!
     
    Jeff Schwab, Aug 13, 2005
    #7
  8. bearophileHUGS

    sigzero Guest

    That is rediculous. If that happens...Python comes of my list of
    languages to use. Are they going to mandate 4 spaces as well?

    Robert
     
    sigzero, Aug 13, 2005
    #8
  9. bearophileHUGS

    sigzero Guest

    Ah!!! I read it and noticed the date "April 1st". Doh!
     
    sigzero, Aug 13, 2005
    #9
  10. After the backlash, Python 4.0 will ban leading spaces and require
    tabs <G>

    (Especially when M$ decides to ban fixed-width fonts, and uses
    micro-spaces such that the difference between one space and eight spaces
     
    Dennis Lee Bieber, Aug 14, 2005
    #10
  11. bearophileHUGS

    Dan Sommers Guest

    Why not petition the unicode people to include PYTHON INDENT and PYTHON
    DEDENT code points, and leave the display up to the text editors? ;-)

    Regards,
    Dan
     
    Dan Sommers, Aug 14, 2005
    #11
  12. bearophileHUGS

    John Machin Guest

    Good idea, Dan. And when you don't want the indented/dedented display,
    but a repr-like "what's actually there", they could be rendered as
    little icons of a snake and a ladder respectively.

    [It's a joke, Joyce.]
     
    John Machin, Aug 14, 2005
    #12
  13. bearophileHUGS

    Paul Watson Guest

    The Unicode people will correctly point out that there is already a
    Unicode codepoint assignment which can be used for this purpose. It is
    even in the BMP portion of the C0 controls group.

    0009 = HORIZONTAL TABULATION
     
    Paul Watson, Aug 15, 2005
    #13
  14. bearophileHUGS

    John Machin Guest

    and how do you use this to get the DEDENT effect? Use something out of
    the bidirectional kit? E.g. RLO then tab then PDF ;-)
     
    John Machin, Aug 15, 2005
    #14
  15. bearophileHUGS

    Paul Watson Guest

    The use of one less HORIZONTAL TABULATION on a line in relation to the
    number of HORIZONTAL TABULATION codepoints used by the pervious line
    indicated "dedent" as you call it. :)

    There are things about your suggestion that would be great! It would
    require a language aware editing tool to be used. Like HTML was
    intended, the rendering of the program source would be managed by the
    tool. Everyone could choose the style in which they would like to
    interact with the code.

    This is also the biggest problem. It would mean that a specialized
    editor tool would be required. One could not just use a POTE (Plain Old
    Text Editor).

    Using U+0009 HORIZONTAL TABULATION would provide both user selectable
    rendering style as well as access through most existing tools.

    Of course, there is always 'expand' and 'unexpand' if you are really
    desparate.
     
    Paul Watson, Aug 15, 2005
    #15
  16. bearophileHUGS

    John Machin Guest

    OK Paul, you've convinced me. I look forward to your PEP "Mandated
    U+0009 HORIZONTAL TABULATION in Python source".
    Cheers,
    John
     
    John Machin, Aug 15, 2005
    #16
  17. bearophileHUGS

    Steve Holden Guest

    Yes. The .pyo files are optimized by removing certain features that
    aren't essential to execution (things like doc strings).
    The next time you import the module concerned the interpreter will
    recreate the .pyc file.
    There is no difference between 2.3 and 2.4 in their treatment of .pyc
    and .pyo files. The .pyo files are used when you give the interpreter
    the -O option to indicate you want optimized performance. Most people
    happily live without ever using this option, but in certain cases it can
    save some run time.
    The interpreter will have to take the time to re-create the .pyc on
    imported modules. If the files can't be created (due to permission
    problems or whatever) the module has t be recompiled each execution.
    Hope this helps.

    regards
    Steve
     
    Steve Holden, Aug 22, 2005
    #17
  18. Warning: this post contains arcane knowledge.

    The -O option defines __debug__ to be False, and (as a side-effect)
    ignores assert statements in the code used. The -OO option does
    everything the -O option does, while also removing things like doc
    strings. Both -O and -OO produce .pyo files, so having made things
    with -OO, even using -O you will not see the doc strings in those
    modules.

    Here is a weird python program called opdemo.py to show these effects:

    Call it opdemo.py
    ==================================
    import sys

    def function():
    '''doc strings kept'''
    try:
    assert 4 == 5
    print '%s: assert skipped (__debug__ = %s)' % (
    __name__, __debug__)
    except AssertError:
    print '%s: assert checked (__debug__ = %s)' % (
    __name__, __debug__)

    docstring = function.__doc__ or 'No doc strings'
    print sys.version
    print '%s: __debug__ = %s; %s' % (__name__, __debug__, docstring)
    print __file__
    function()

    if __name__ == '__main__':
    print '============='
    import opdemo
    print opdemo.__name__, opdemo.docstring, opdemo.__file__
    opdemo.function()
    ==================================

    Now that you have this, you can run:
    python opdemo.py
    and then
    python opdemo.py
    To see how you can tell if you are running post-compiled.

    If you run
    python -OO opdemo.py
    and then
    python -O opdemo.py
    You will see it looks like -O also removes docstrings.
    However if you delete opdemo.py and run
    python -O opdemo.py
    and then
    python -O opdemo.py
    You will see the docstrings are in fact there for -O.
    Of course, for all of this you will have to think a lot about
    exactly what code is being executed. A help to figuring this out
    is to remember that if you import a module you get a new and
    different copy of the module from the main program.

    --Scott David Daniels
     
    Scott David Daniels, Aug 22, 2005
    #18
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.