extending the break statement

Bengt Richter bokr at oz.net
Thu Oct 23 00:49:37 CEST 2003

On 22 Oct 2003 08:06:36 -0700, mis6 at pitt.edu (Michele Simionato) wrote:

>Is there a way of "ending" a module? I would like something like this:
>  # mod.py
>  print 'something here'
>  end() # some mysterious function
>  print 'you should not get here'
>  # main.py
>  import mod
>  print 'it works'
>I cannot use 'sys.exit' in place of ``end()``, since it would exit from 
>the whole program and the line 'it works' would not be printed. 
>I know that I can modify the main program to catch the SystemExit
># main.py
>  import mod
>except SystemExit: 
>  pass
>print 'it works'
>but I find it really ugly, since I am forced to change by hand 
>all the scripts importing 'mod'. Moreover, I am abusing ``SystemExit``;
>I should add instead a new built-in exception ``EndModule``, but this 
>requires even more lines of code for something that should be trivial.
>On the other hand, I don't like the ``if 0:`` option, i.e. writing ``mod.py`` 
>in the form
>  # mod.py
>  print 'something here'
>  end() # some mysterious function
>  if 0:
>      print 'you should not get here'
>since it requires re-indenting by hand the (potentially long) block
>of code to be commented out. Yes, I know about C-c->, but honestly
>it is a PITA. Typically, I would like to comment out portions of
>experimental code during debugging; that code will enter in the final 
>program at the end, so I must indent and re-indent it until it works 
>(which means lots of times).
>More in general, one could think of an ``end()`` function with the ability of
>stopping the execution of the current frame and going back to the previous
>frame. One could even terminate classes in this way, i.e. skipping all the
>methods defined after the ``end()``
>... (some time passes) ...
>BTW, I have just realized that we don't need a new ``end()`` function: it would be 
>enough to extend the ``break`` statement. Currently, it works only inside 
>loops, why not to extend it to terminate classes and modules? IMHO, it would be
>very useful during debugging and refactoring. What do you people think? 
>Or is there already same magic which can do what I ask for?
>If not, take it as a feature request ;-)
I wonder if one couldn't get more bang for the change-buck by breaking the
1:1 module:file relationship. I.e., if there were a way to delimit multiple
modules in a single file, then you could use that mechanism to make a dummy module
segment that would be ignored unless specifically imported one way or another.

====< some_module.py >========================
"""Normal module source in this section works as usual"""

# the next line here creates a package style textually nested/embedded module definition
module embedded_module: <long-delimiter-string-a-la-mime>

def this(): pass
class That(object): pass

# the previous line ended the embedded module definition, and here
# it's optionally possible to continue with the normal outermost module source

Thus to do what you wanted to do, just define a dummy embedded module like

#... (your clean code in progress here)

module dummy: some-unique-delimiter-string

#XXX# get to this later ...
Any unfinished scraps etc that might have errors or whatever
can go here
So you could use this to "comment out" the tail of


This would solve your problem (I think) and might make a new package format possible.
E.g., you could import file_level_module.textually_nested_module etc. something like
importing from a zip file. I might be a handy way to structure mini-packages.

How a module might best refer to its own embedded modules (imported or not) I don't know...
though they ought to be visible via sys.modules through its own name.

BTW, I had the notion that importing ought to be generalized to create a usable module by
any means whatever, including compiling a foreign language source and creating an extension
DLL from and importing that, etc., of course caching as usual via sys.modules.

Such a generalized importing mechanism would logically also cover ordinary Python, but then
I see an opportunity to control it with optimization and/or debugging control parameters passed
to the import. Also possibly version-specific directives. IOW, import would become a general
dynamic way of getting current-version-compatible modules into the current run time environment
using any sources and translations etc. one could conceive. Adapting to embedded-module style
files via this would be a simple variant of the general idea.

Bengt Richter

More information about the Python-list mailing list