Spaces and tabs again

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

  1. Guest

    Hello, I know this topic was discussed a *lot* in the past, sorry if it
    bores you...

    >From the Daily Python-URL I've seen this interesting Floating Point

    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
     
    , Aug 13, 2005
    #1
    1. Advertising

  2. Hallöchen!

    writes:

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


    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, aquisgrana, europa vetus
     
    Torsten Bronger, Aug 13, 2005
    #2
    1. Advertising

  3. Jeff Schwab Guest

    wrote:
    > Hello, I know this topic was discussed a *lot* in the past, sorry if it
    > bores you...
    >
    >>From the Daily Python-URL I've seen this interesting Floating Point

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



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

    In article <>,
    <> wrote:
    >
    >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?).


    Python 3.0 will prohibit tabs.
    --
    Aahz () <*> http://www.pythoncraft.com/

    The way to build large Python applications is to componentize and
    loosely-couple the hell out of everything.
     
    Aahz, Aug 13, 2005
    #4
  5. Guest

    Aahz wrote:
    <snip>
    > Python 3.0 will prohibit tabs.
    > --
    > Aahz () <*> http://www.pythoncraft.com/
    >
    > The way to build large Python applications is to componentize and
    > loosely-couple the hell out of everything.


    Are you kidding? You are going to MANDATE spaces?

    Robert
     
    , Aug 13, 2005
    #5
  6. wrote:

    > Are you kidding? You are going to MANDATE spaces?


    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. Jeff Schwab Guest

    Christopher Subich wrote:
    > wrote:
    >
    >> Are you kidding? You are going to MANDATE spaces?

    >
    >
    > 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')


    Downright unpythonic!

    --
    """Va Nhthfg? Gung'f pehry. V nyzbfg jrag onpx gb Crey!

    Univat arire frra "GBBJGQV" orsber abj, V nz fgvyy ynhtuvat cerggl uneq.
    """.decode('rot13')
     
    Jeff Schwab, Aug 13, 2005
    #7
  8. 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
     
    , Aug 13, 2005
    #8
  9. Guest

    Ah!!! I read it and noticed the date "April 1st". Doh!
     
    , Aug 13, 2005
    #9
  10. On 13 Aug 2005 13:18:21 -0700, declaimed the following
    in comp.lang.python:

    >
    > Are you kidding? You are going to MANDATE spaces?
    >

    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
    is only a display pixel <G>)
    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Home Page: <http://www.dm.net/~wulfraed/> <
    > Overflow Page: <http://wlfraed.home.netcom.com/> <
     
    Dennis Lee Bieber, Aug 14, 2005
    #10
  11. Dan Sommers Guest

    On Sun, 14 Aug 2005 01:04:04 GMT,
    Dennis Lee Bieber <> wrote:

    > On 13 Aug 2005 13:18:21 -0700, declaimed the following
    > in comp.lang.python:


    >>
    >> Are you kidding? You are going to MANDATE spaces?
    >>

    > After the backlash, Python 4.0 will ban leading spaces and require
    > tabs <G>


    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
    <http://www.tombstonezero.net/dan/>
     
    Dan Sommers, Aug 14, 2005
    #11
  12. John Machin Guest

    Dan Sommers wrote:
    > On Sun, 14 Aug 2005 01:04:04 GMT,
    > Dennis Lee Bieber <> wrote:
    >
    >
    >>On 13 Aug 2005 13:18:21 -0700, declaimed the following
    >>in comp.lang.python:

    >
    >
    >>>Are you kidding? You are going to MANDATE spaces?
    >>>

    >>
    >> After the backlash, Python 4.0 will ban leading spaces and require
    >>tabs <G>

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


    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. Paul Watson Guest

    Dan Sommers wrote:
    > On Sun, 14 Aug 2005 01:04:04 GMT,
    > Dennis Lee Bieber <> wrote:
    >
    >
    >>On 13 Aug 2005 13:18:21 -0700, declaimed the following
    >>in comp.lang.python:

    >
    >
    >>>Are you kidding? You are going to MANDATE spaces?
    >>>

    >>
    >> After the backlash, Python 4.0 will ban leading spaces and require
    >>tabs <G>

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


    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. John Machin Guest

    Paul Watson wrote:
    > Dan Sommers wrote:
    >
    >> On Sun, 14 Aug 2005 01:04:04 GMT,
    >> Dennis Lee Bieber <> wrote:
    >>
    >>
    >>> On 13 Aug 2005 13:18:21 -0700, declaimed the following
    >>> in comp.lang.python:

    >>
    >>
    >>
    >>>> Are you kidding? You are going to MANDATE spaces?
    >>>>
    >>>
    >>> After the backlash, Python 4.0 will ban leading spaces and require
    >>> tabs <G>

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

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


    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. Paul Watson Guest

    John Machin wrote:
    > Paul Watson wrote:
    >
    >> Dan Sommers wrote:
    >>
    >>> On Sun, 14 Aug 2005 01:04:04 GMT,
    >>> Dennis Lee Bieber <> wrote:
    >>>
    >>>
    >>>> On 13 Aug 2005 13:18:21 -0700, declaimed the
    >>>> following
    >>>> in comp.lang.python:
    >>>
    >>>
    >>>
    >>>
    >>>>> Are you kidding? You are going to MANDATE spaces?
    >>>>>
    >>>>
    >>>> After the backlash, Python 4.0 will ban leading spaces and require
    >>>> tabs <G>
    >>>
    >>>
    >>>
    >>>
    >>> 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

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

    >
    >
    > 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 ;-)


    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. John Machin Guest

    Paul Watson wrote:
    > John Machin wrote:
    >
    >> Paul Watson wrote:
    >>
    >>> Dan Sommers wrote:
    >>>
    >>>> On Sun, 14 Aug 2005 01:04:04 GMT,
    >>>> Dennis Lee Bieber <> wrote:
    >>>>
    >>>>
    >>>>> On 13 Aug 2005 13:18:21 -0700, declaimed the
    >>>>> following
    >>>>> in comp.lang.python:
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>>> Are you kidding? You are going to MANDATE spaces?
    >>>>>>
    >>>>>
    >>>>> After the backlash, Python 4.0 will ban leading spaces and require
    >>>>> tabs <G>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>> 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
    >>>
    >>>
    >>>
    >>>
    >>> 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

    >>
    >>
    >>
    >> 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 ;-)

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


    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. Steve Holden Guest

    Re: Reg Python Byte code

    praba kar wrote:
    > Dear All,
    >
    > Python 2.3 creates byte code with *.pyc
    > extention. But Python 2.4 creates bytes code with
    > *.pyo. Is there any difference between *.pyc
    > and *.pyo?.
    >

    Yes. The .pyo files are optimized by removing certain features that
    aren't essential to execution (things like doc strings).

    > Actually After python compiled a program
    > then that program will run from the *.pyc byte
    > code. If I delete that byte code what will be
    > happen.?
    >

    The next time you import the module concerned the interpreter will
    recreate the .pyc file.

    > If I delete *.pyc byte code in the python
    > 2.3 then It will create again *.pyc byte code.
    > But If I delete *.pyo byte code in the python
    > 2.4 then It will not create again *.pyo. Why
    > this difference.
    >

    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.

    > If I delete byte code of the python.
    > I want to know Whether it will affect the
    > performance of the programme or not.
    >

    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.

    > Kindly clear me all the doubts regarding
    > byte code of python.
    >
    > with regards
    > Prabahar
    >
    >

    Hope this helps.

    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
     
    Steve Holden, Aug 22, 2005
    #17
  18. Re: Reg Python Byte code <warning: arcane knowledge>

    Warning: this post contains arcane knowledge.

    Steve Holden wrote:
    > praba kar wrote:
    >> Python 2.3 creates byte code with *.pyc
    >> extention. But Python 2.4 creates bytes code with
    >> *.pyo. Is there any difference between *.pyc
    >> and *.pyo?.
    >>

    > Yes. The .pyo files are optimized by removing certain features that
    > aren't essential to execution (things like doc strings).


    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. 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. nospam
    Replies:
    2
    Views:
    5,343
    Joe Smith
    Jul 3, 2004
  2. Sandeep
    Replies:
    1
    Views:
    929
    Raymond DeCampo
    Jan 15, 2006
  3. qwweeeit
    Replies:
    2
    Views:
    676
    qwweeeit
    Dec 14, 2005
  4. rantingrick

    Tabs -vs- Spaces: Tabs should have won.

    rantingrick, Jul 16, 2011, in forum: Python
    Replies:
    95
    Views:
    1,920
    Roy Smith
    Jul 19, 2011
  5. John Kopanas
    Replies:
    2
    Views:
    317
    Gregory Brown
    Jan 29, 2007
Loading...

Share This Page