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

[Dan Sommers]

On Sun, 14 Aug 2005 01:04:04 GMT,
Dennis Lee Bieber <wl*****@ix.net com.com> wrote:

On 13 Aug 2005 13:18:21 -0700, si*****@gmail.c om declaimed the following
in comp.lang.pytho n:

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.tombstoneze ro.net/dan/>

[John Machin]

Dan Sommers wrote:

On Sun, 14 Aug 2005 01:04:04 GMT,
Dennis Lee Bieber <wl*****@ix.net com.com> wrote:

On 13 Aug 2005 13:18:21 -0700, si*****@gmail.c om declaimed the following
in comp.lang.pytho n:

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

[Paul Watson]

Dan Sommers wrote:

On Sun, 14 Aug 2005 01:04:04 GMT,
Dennis Lee Bieber <wl*****@ix.net com.com> wrote:

On 13 Aug 2005 13:18:21 -0700, si*****@gmail.c om declaimed the following
in comp.lang.pytho n:

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

[John Machin]

Paul Watson wrote:

Dan Sommers wrote:

On Sun, 14 Aug 2005 01:04:04 GMT,
Dennis Lee Bieber <wl*****@ix.net com.com> wrote:

On 13 Aug 2005 13:18:21 -0700, si*****@gmail.c om declaimed the following
in comp.lang.pytho n:

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

[Paul Watson]

John Machin wrote:

Paul Watson wrote:

Dan Sommers wrote:

On Sun, 14 Aug 2005 01:04:04 GMT,
Dennis Lee Bieber <wl*****@ix.net com.com> wrote:
On 13 Aug 2005 13:18:21 -0700, si*****@gmail.c om declaimed the
following
in comp.lang.pytho n:


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

[John Machin]

Paul Watson wrote:

John Machin wrote:

Paul Watson wrote:

Dan Sommers wrote:

On Sun, 14 Aug 2005 01:04:04 GMT,
Dennis Lee Bieber <wl*****@ix.net com.com> wrote:
> On 13 Aug 2005 13:18:21 -0700, si*****@gmail.c om declaimed the
> following
> in comp.lang.pytho n:

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

[Steve Holden]

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 [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[Scott David Daniels]

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.docstrin g, 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
Sc***********@A cm.Org