indentation preservation/restoration

[smichr]

I have (inadvertently) wiped out the functionality of my personal
python snippets by eliminating leading space. I have also just visited
http://www.python.org/tim_one/000419.html and saw a piece of code with
the indentation gone. Python code is fragile in this regard. One
solution that occurs to me is that a "indentation code" could be
appended to a script which could be used to rebuild the script if
necessary. e.g. if we let letters represent the number of spaces before
a line and numbers to indicate how many lines have that spacing, then
A2E2A1 could represent the leading space on the code,

# A Hello Program
def hi():
msg = 'hello world!'
return msg
print hi()

If the line returns are gone (as they are at the url above) then this
wouldn't work and perhaps the number of characters on each line could
be encoded as well. I'm not sure what the best way to do that would be.
I'm not sure where the best time and place to add such a coding to file
would be, however. If you do as I did to my library (anyone?) then
having the code placed at the bottom of the script as save time
wouldn't have helped in the recovery. Placing the code with scripts
that are placed on the web or archived might be smart.

Any thoughts?

/c

[Claudio Grondi]

sm****@gmail.com wrote:

I have (inadvertently) wiped out the functionality of my personal
python snippets by eliminating leading space. I have also just visited
http://www.python.org/tim_one/000419.html and saw a piece of code with
the indentation gone. Python code is fragile in this regard. One
solution that occurs to me is that a "indentation code" could be
appended to a script which could be used to rebuild the script if
necessary. e.g. if we let letters represent the number of spaces before
a line and numbers to indicate how many lines have that spacing, then
A2E2A1 could represent the leading space on the code,

# A Hello Program
def hi():
msg = 'hello world!'
return msg
print hi()

If the line returns are gone (as they are at the url above) then this
wouldn't work and perhaps the number of characters on each line could
be encoded as well. I'm not sure what the best way to do that would be.
I'm not sure where the best time and place to add such a coding to file
would be, however. If you do as I did to my library (anyone?) then
having the code placed at the bottom of the script as save time
wouldn't have helped in the recovery. Placing the code with scripts
that are placed on the web or archived might be smart.

Any thoughts?

/c

Usually the problem can be solved by looking at the source code of an
HTML page. The people programming Python are not always good
Web-programmer and forget to put their code into textarea or pre tags in
order to make the code pastable directly from the web page.

This seems also to be for the mentioned page the case. So go to see the
source code of the HTML page in your editor and you will get the lost
spaces.

Claudio

[Steven D'Aprano]

On Mon, 02 Jan 2006 14:19:15 -0800, smichr wrote:

I have (inadvertently) wiped out the functionality of my personal
python snippets by eliminating leading space. I have also just visited
http://www.python.org/tim_one/000419.html and saw a piece of code with
the indentation gone. Python code is fragile in this regard. One
solution that occurs to me is that a "indentation code" could be
appended to a script which could be used to rebuild the script if
necessary. e.g. if we let letters represent the number of spaces before
a line and numbers to indicate how many lines have that spacing, then
A2E2A1 could represent the leading space on the code,

What a great idea! I had a similar problem, your scheme could be adapted
to solve that too. I accidentally deleted all the numeric literals from my
Python code, and Python is fragile in this regard. So we could have a
"number code" appended to a script which could be used to rebuild the
script if necessary: e.g. a code like "E,D,CA" means the fourth token of
the fifth line is 31.

With a little bit of work, this could be expanded to add redundancy for
not just indentation and numeric literals, but also string literals,
keywords, operators, and anything else. Using compression and
error-correcting codes should mean that your Python scripts will then be
safe from absolutely anything short of deleting the entire file -- and for
that, you have backups.

--
Steven.

[smichr]

Steven D'Aprano wrote:

With a little bit of work, this could be expanded to add redundancy for
not just indentation and numeric literals, but also string literals,
keywords, operators, and anything else.

When I copy and assign to variable 'post' the reply posted here on
c.l.p. starting with "On Mon, 02" and ending with "- \nSteven." and run
it through the hidden() function below with the indices indicated, I
can see what you were really thinking.

The point is well taken: one must consider leading space as an
important part of the code. This is just one of those things that's so
easy to shift around, however. You don't have to work very hard with an
editor's text manipulations to lose it.

That's life. I know.
/c

###
def hidden(t,indx):
msg=[]
for i in indx:
msg.append(t[i])
return ''.join(msg)
thought=[40, 47, 51, 106, 179, 180, 181, 182, 395, 396, 399,
1129, 1143, 1194, 1224, 1225, 1226]
print hidden(post,thought)
###

[smichr]

I can't believe I forgot that trick :-| Thanks for the helpful
reminder.

/c

[Claudio Grondi]

sm****@gmail.com wrote:

Steven D'Aprano wrote:

With a little bit of work, this could be expanded to add redundancy for
not just indentation and numeric literals, but also string literals,
keywords, operators, and anything else.

When I copy and assign to variable 'post' the reply posted here on
c.l.p. starting with "On Mon, 02" and ending with "- \nSteven." and run
it through the hidden() function below with the indices indicated, I
can see what you were really thinking.

The point is well taken: one must consider leading space as an
important part of the code. This is just one of those things that's so
easy to shift around, however. You don't have to work very hard with an
editor's text manipulations to lose it.

That's life. I know.
/c

###
def hidden(t,indx):
msg=[]
for i in indx:
msg.append(t[i])
return ''.join(msg)
thought=[40, 47, 51, 106, 179, 180, 181, 182, 395, 396, 399,
1129, 1143, 1194, 1224, 1225, 1226]
print hidden(post,thought)
###

The subject of spaces in Python has been discussed over and over here in
a manner which reminds sometimes of threads caused by simple trolling.

It is so easy to mix different things into one when not beeing able to
see clearly what is what. Writing code is one thing, data security is
another and compression also another thing. From the point of view of
programming it is a origin of additional efforts required when all the
aspects are mixed together into a data format which is to be processed.
It would be much cleaner and easy to understand when staying separate,
i.e. format first, than a compression scheme for it, than secure storage
media system.

The conclusion out of it?

From my point of view adding redundancy already at the level of source
code is the wrong way to go and not worth to consider.
Such efforts belong to the design of a secure storage media system or
are covered by usage of a versioning system.

Claudio