extending the break statement

[Bengt Richter]

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
>exception:
>
>
># main.py
>try: 
>  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.

E.g.,
====< 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

<long-delimiter-string-a-la-mime>
# 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

some-unique-delimiter-string

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.

Regards,
Bengt Richter