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...

    This is the source pack:

    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
    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?).

    bearophileHUGS, Aug 13, 2005
    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

    Torsten Bronger, Aug 13, 2005
    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
    Jeff Schwab, Aug 13, 2005
  4. bearophileHUGS

    Aahz Guest

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

    sigzero Guest

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

    sigzero, Aug 13, 2005
  6. Actually, future whitespace rules will be extensive. See:
    (google cache of 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
  7. bearophileHUGS

    Jeff Schwab Guest

    Downright unpythonic!
    Jeff Schwab, Aug 13, 2005
  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?

    sigzero, Aug 13, 2005
  9. bearophileHUGS

    sigzero Guest

    Ah!!! I read it and noticed the date "April 1st". Doh!
    sigzero, Aug 13, 2005
  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
  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? ;-)

    Dan Sommers, Aug 14, 2005
  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
  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.

    Paul Watson, Aug 15, 2005
  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
  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
    Paul Watson, Aug 15, 2005
  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".
    John Machin, Aug 15, 2005
  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.

    Steve Holden, Aug 22, 2005
  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

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

    Call it
    import sys

    def function():
    '''doc strings kept'''
    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__

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

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

    If you run
    python -OO
    and then
    python -O
    You will see it looks like -O also removes docstrings.
    However if you delete and run
    python -O
    and then
    python -O
    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
    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.