Alternate indent proposal for python 3000

[Eric Wertman]

I was considering putting together a proposal for an alternate block
syntax for python, and I figured I'd post it here and see what the
general reactions are. I did some searching, and while I found a lot
of tab vs space debates, I didn't see anything like what I'm thinking
of, so forgive me if this is a very dead horse.

Generally speaking, I like the current block scheme just fine. I use
python on a daily basis for system administration and text parsing
tasks, and it works great for me.

From time to time, though, I find myself needing a language for server-
side includes in web pages. Because of the need to indent (and
terminate indents), python seems an awkward choice for this, and it's
easy for me to see why php and perl are more popular choices for this
kind of task. Perhaps this is just my perception though.

I feel that including some optional means to block code would be a big
step in getting wider adoption of the language in web development and
in general. I do understand though, that the current strict indenting
is part of the core of the language, so... thoughts?

 

[Christian Heimes]

I was considering putting together a proposal for an alternate block
syntax for python, and I figured I'd post it here and see what the
general reactions are. I did some searching, and while I found a lot
of tab vs space debates, I didn't see anything like what I'm thinking
of, so forgive me if this is a very dead horse.

You are definitely too late to propose a change for py3k.

I feel that including some optional means to block code would be a big
step in getting wider adoption of the language in web development and
in general. I do understand though, that the current strict indenting
is part of the core of the language, so... thoughts?

Why should Python repeat the mistakes other languages did with SSI or
<?php ?> inline code? Python favors the MVC separation of code and layout.

Christian

 

[George Sakkis]

I was considering putting together a proposal for an alternate block
syntax for python, and I figured I'd post it here and see what the
general reactions are.  I did some searching, and while I found a lot
of tab vs space debates, I didn't see anything like what I'm thinking
of, so forgive me if this is a very dead horse.

[with apologies to Monty Python]

This horse is no more! He has ceased to be! 'E's expired and gone to
meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! THIS
IS AN EX-HORSE!!

Generally speaking, I like the current block scheme just fine.  I use
python on a daily basis for system administration and text parsing
tasks, and it works great for me.

From time to time, though, I find myself needing a language for server-
side includes in web pages.  Because of the need to indent (and
terminate indents), python seems an awkward choice for this, and it's
easy for me to see why php and perl are more popular choices for this
kind of task.  Perhaps this is just my perception though.

Look into any of the dozen Python-based template engines that are
typically used for such tasks; they offer many more features than a
way to indent blocks.

George

 

[Eric Wertman]

Look into any of the dozen Python-based template engines that are
typically used for such tasks; they offer many more features than a
way to indent blocks.

George

I definitely will.. could you throw out some examples though?
Thanks!

Eric

 

[Matthew Woodcraft]

Why should Python repeat the mistakes other languages did with SSI or
<?php ?> inline code? Python favors the MVC separation of code and layout.

An alternative scheme for describing the block structure could be
useful in other cases, though. For example, if you wanted to support
putting snippets of Python in configuration files, or spreadsheet
cells.

There's no need to support the new scheme in .py files, so it seems to
me that this doesn't have to be done in the core language. All that's
needed is a variant of 'eval' which expects the alternate scheme, and
that could be prototyped just using text manipulation and the normal
'eval'.

If someone wrote a library for this and it proved popular, I expect it
would be considered for the standard library.

-M-

 

[Arnaud Delobelle]

An alternative scheme for describing the block structure could be
useful in other cases, though. For example, if you wanted to support
putting snippets of Python in configuration files, or spreadsheet
cells.

There's no need to support the new scheme in .py files, so it seems to
me that this doesn't have to be done in the core language. All that's
needed is a variant of 'eval' which expects the alternate scheme, and
that could be prototyped just using text manipulation and the normal
'eval'.

By 'eval', I guess you mean 'exec'

 

[Matthew Woodcraft]

By 'eval', I guess you mean 'exec'

Yes. Shows how often I use either.

-M-

 

[Terry Reedy]

| There's no need to support the new scheme in .py files, so it seems to
| me that this doesn't have to be done in the core language. All that's
| needed is a variant of 'eval' which expects the alternate scheme, and
| that could be prototyped just using text manipulation and the normal
| 'eval'.

Eval() is for expressions, exec() is for general code. But you do not
really need a variant. Just define a preprocessor function 'blockify'
which converts code in an alternate syntax to regular indented block
syntax. Then

exec(blockify(alt_code_string))

I presume that this is more or less what the templating engines do.

 

[Gabriel Genellina]

An alternative scheme for describing the block structure could be
useful in other cases, though. For example, if you wanted to support
putting snippets of Python in configuration files, or spreadsheet
cells.
[...] If someone wrote a library for this and it proved popular, I expect it
would be considered for the standard library.

There is "pindent.py" in the Tools/scripts directory:

# ... When called as "pindent -r" it assumes its input is a
# Python program with block-closing comments but with its indentation
# messed up, and outputs a properly indented version.

# A "block-closing comment" is a comment of the form '# end <keyword>'
# where <keyword> is the keyword that opened the block ...

def foobar(a, b):
if a == b:
a = a+1
elif a < b:
b = b-1
if b > a: a = a-1
# end if
else:
print 'oops!'
# end if
# end def foobar

 

[Matthew Woodcraft]

But you do not really need a variant. Just define a preprocessor
function 'blockify' which converts code in an alternate syntax to
regular indented block syntax. Then

exec(blockify(alt_code_string))

You can do it like that, but if it were to become part of the standard
distribution it would be nice to avoid having to tokenise the code
twice. (You could define the new block scheme in such a way that
'blockify' doesn't need to tokenise, but I think it would end up a bit
ugly.)

-M-

 

[Eric Wertman]

An alternative scheme for describing the block structure could be
useful in other cases, though. For example, if you wanted to support
putting snippets of Python in configuration files, or spreadsheet
cells.
[...] If someone wrote a library for this and it proved popular, I expect it
would be considered for the standard library.

There is "pindent.py" in the Tools/scripts directory:

# ... When called as "pindent -r" it assumes its input is a
# Python program with block-closing comments but with its indentation
# messed up, and outputs a properly indented version.

# A "block-closing comment" is a comment of the form '# end <keyword>'
# where <keyword> is the keyword that opened the block ...

def foobar(a, b):
if a == b:
a = a+1
elif a < b:
b = b-1
if b > a: a = a-1
# end if
else:
print 'oops!'
# end if
# end def foobar

That's actually not a lot different than what you have to do now in a
web page.. It still seems overcomplicated though. I'm not sure why
this is worse:

def foobar(a, b):
if a == b:
a = a+1;
elif a < b:
b = b-1;
if b > a:
a = a-1;
else:
print 'oops!';;

It's just ultimately whitespace insensitive. Whether that's a good or
bad design is a debate that can be argued either way, but other
languages do it, and it's handy sometimes. I agree that it makes it
much easier to produce illegible code. Developing for a browser is
arguably annoying and hackish enough, without having to stick in
comments and such to enforce indenting.

 

[bruno.desthuilliers]

I was considering putting together a proposal for an alternate block
syntax for python, and I figured I'd post it here and see what the
general reactions are. I did some searching, and while I found a lot
of tab vs space debates, I didn't see anything like what I'm thinking
of, so forgive me if this is a very dead horse.

Generally speaking, I like the current block scheme just fine. I use
python on a daily basis for system administration and text parsing
tasks, and it works great for me.

From time to time, though, I find myself needing a language for server-
side includes in web pages. Because of the need to indent (and
terminate indents), python seems an awkward choice for this, and it's
easy for me to see why php and perl are more popular choices for this
kind of task. Perhaps this is just my perception though.

The server-page scheme has long shown it's limitations and quirks -
mostly, you end up mixing application logic and presentation logic.
Even PHP programmers are slowly taking the MVC route.

I feel that including some optional means to block code would be a big
step in getting wider adoption of the language in web development and
in general. I do understand though, that the current strict indenting
is part of the core of the language, so... thoughts?

Python Server Page packages are nothing new, and didn't help making
Python more popular for web developpement. MVC frameworks like Django,
Pylons, Turbogears or web.py seems to draw way more attention, and we
start to see PHP coders switching to Django - which is the one with
the IMHO weakest templating language.

If you're looking for a templating system with Python syntax support,
you may want to take a look at Cheetah and (my favourite one) Mako.
Mako is the default template system for Pylons, and IIRC web.py
supports Cheetah (warning: never used web.py, and haven't followed
recent dev, so you'd better check by yourself).

HTH

 

[George Sakkis]

I definitely will.. could you throw out some examples though?
Thanks!

Eric

Start out here: http://wiki.python.org/moin/Templating

As you can see there is no shortage of alternatives, which can be
overwhelming. Cheetah used to be the most popular and it's still
widely used, but these days Django templates, Genshi and Mako seem
more prominent for web development.

HTH,
George

 

[Dan Bishop]

An alternative scheme for describing the block structure could be
useful in other cases, though. For example, if you wanted to support
putting snippets of Python in configuration files, or spreadsheet
cells.

There's no need to support the new scheme in .py files, so it seems to
me that this doesn't have to be done in the core language. All that's
needed is a variant of 'eval' which expects the alternate scheme, and
that could be prototyped just using text manipulation and the normal
'eval'.

We wouldn't even need that. Just a new source encoding. Then we
could write:

# -*- coding: end-block -*-

def _itoa(num, base):
"""Return the string representation of a number in the given base."""
if num == 0:
return DIGITS[0]
end if
negative = num < 0
if negative:
num = -num
end if
digits = []
while num:
num, last_digit = divmod(num, base)
digits.append(DIGITS[last_digit])
end while
if negative:
digits.append('-')
end if
return ''.join(reversed(digits))
end def

 

[George Sakkis]

An alternative scheme for describing the block structure could be
useful in other cases, though. For example, if you wanted to support
putting snippets of Python in configuration files, or spreadsheet
cells.

There's no need to support the new scheme in .py files, so it seems to
me that this doesn't have to be done in the core language. All that's
needed is a variant of 'eval' which expects the alternate scheme, and
that could be prototyped just using text manipulation and the normal
'eval'.

We wouldn't even need that.  Just a new source encoding.  Then we
could write:

# -*- coding: end-block -*-

def _itoa(num, base):
"""Return the string representation of a number in the given base."""
if num == 0:
return DIGITS[0]
end if
negative = num < 0
if negative:
num = -num
end if
digits = []
while num:
num, last_digit = divmod(num, base)
digits.append(DIGITS[last_digit])
end while
if negative:
digits.append('-')
end if
return ''.join(reversed(digits))
end def

A great example of why something like this would never fly in standard
Python.

 

[Terry Reedy]

|
| > But you do not really need a variant. Just define a preprocessor
| > function 'blockify' which converts code in an alternate syntax to
| > regular indented block syntax. Then
| >
| > exec(blockify(alt_code_string))
|
| You can do it like that, but if it were to become part of the standard
| distribution it would be nice to avoid having to tokenise the code
| twice.

For the motivating example I was responding to -- short snippets of code in
html/xml/etc, that is completely a non-issue.

Any such scheme is very unlikely to become part of the stdlib and if it
were, it would have to first be tested and beat out competitors. A
preprocessor written in Python is the obvious way to test and gain
acceptance.

| (You could define the new block scheme in such a way that
| 'blockify' doesn't need to tokenise,

Off the top of my head: copy C and use {} to demarcate blocks and ';' to
end statements, so that '\n' is not needed and is just whitespace when
present. So, repeatedly scan for the next one of '{};'.

| but I think it would end up a bit ugly.)

For beautiful, stick with standard Python.

Terry Jan Reedy

 

[Terry Reedy]

| We wouldn't even need that. Just a new source encoding. Then we
| could write:
|
| # -*- coding: end-block -*-

Ummm.. source encoding refers to how unicode chars/codepoints are
represented as bytes. This syntax is copied from emacs and uses standard
terms. What would you expect an encoding aware editor to do with something
like the above?

 

[Paul Boddie]

We wouldn't even need that. Just a new source encoding. Then we
could write:

# -*- coding: end-block -*-

[...]

Someone at EuroPython 2007 did a lightning talk showing working code
which provided C-style block structuring using this mechanism. My
brother then jokingly suggested to Martijn Faassen that if someone
plugged the 2to3 converter in as a source file encoding handler, his
worries about migrating to Python 3 would disappear. I'm waiting to
see if anyone actually bothered to make that happen, albeit for
amusement purposes only.

Paul

P.S. EuroPython 2008 is now accepting talks, especially ones on the
language, Python 3000, and other implementations. See http://www.europython.org/
for details!

 

[Matthew Woodcraft]

Off the top of my head: copy C and use {} to demarcate blocks and ';' to
end statements, so that '\n' is not needed and is just whitespace when
present. So, repeatedly scan for the next one of '{};'.

That would break if those characters appear in string literals or
comments. That's why it's nicer if you can do the transformation after
tokenising.

(Also, '{' and '}' have rather useful meanings in Python already.)

-M-

 

[Dan Bishop]

We wouldn't even need that. Just a new source encoding. Then we
could write:

# -*- coding: end-block -*-

[...]

Someone at EuroPython 2007 did a lightning talk showing working code
which provided C-style block structuring using this mechanism.

Yes, I saw an example of that: It's what inspired my post.