PEP #99484663

Ian Bicking ianb at colorstudy.com
Thu Nov 14 17:16:21 EST 2002


On Thu, 2002-11-14 at 12:31, bboman at research.panasonic.com wrote:
> I also would like to see *OPTIONAL* block delimiters, but I wouldn't
> do it
> with {}.  It turns out that there are several keywords in Python like
> "return"
> "raise", "break", "continue" and "pass" that pretty much have to end a
> block.  Technically "pass" doesn't have to end a block but there is no
> point in putting "pass" anywhere except at a block end.
>
> All you need to do to implement block delimiters is to have a option
> to check that each block ends with one of these statements and that
> these statements do not appear anywhere except at the end of a block. 
> Now you have full block delimiters and complete compatibility with
> normal python code!

Intriguing.  I'm sure pychecker could add the check fairly easily,
though most people will still program without delimiters.  I wouldn't
mind making doubled-delimiters illegal, i.e.:

def func():
    return "something"
    return "something else"

I do this sometimes while debugging, but commenting out the second
return isn't burdensome, and there's no reason to use this form except
during development.

Is there anything besides (X)Emacs that can work with these delimiters?

Anyway, I think this could actually be a reasonable PEP -- it addresses
a real problem (mostly a problem of lots of complaints, but it's a
problem), and at least a partial solution is easy to implement without
bothering anybody much (making double-delimiters illegal).  Forcing all
blocks to be properly terminated may be achievable through some magic
variable that effects the parsing (like a "from __future__ import
explicit_delim" -- even if it's not really in Python's future).  Then
people can use it as they choose on their files, and smart editors could
even be aware of the requirement.  We just need more smart editors...

  Ian





More information about the Python-list mailing list