Spaces and tabs again

[bearophileHUGS]

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

 

[Torsten Bronger]

Hallöchen!

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

 

[Jeff Schwab]

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

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

:set expandtab
:%retab

 

[Aahz]

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.

 

[sigzero]

Aahz wrote:

Python 3.0 will prohibit tabs.
--
Aahz ([email protected]) <*> 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

 

[Christopher Subich]

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

 

[Jeff Schwab]

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!

 

[sigzero]

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]

Ah!!! I read it and noticed the date "April 1st". Doh!

 

[Dennis Lee Bieber]

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

 

[Dan Sommers]

On 13 Aug 2005 13:18:21 -0700, (e-mail address removed) declaimed the following
in comp.lang.python:
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

 

[John Machin]

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

 

[Paul Watson]

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

 

[John Machin]

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

 

[Paul Watson]

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.

 

[John Machin]

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

 

[Steve Holden]

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

 

[Scott David Daniels]

Warning: this post contains arcane knowledge.

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
(e-mail address removed)