[Uml-user] Code generation in Python

[Jonathan Pennington]

This is great software, first of all. I'm using it extensively for 
development of a scientific modeling environment that is quite complex 
(http://pyarie.sourceforge.net/).

The code generation for Python, however, seems to be a bit dodgy. For 
instance, I've got:

from Short import *
from Int import *
from String import *
from List import *
from Float import *

There are a some problems with this generation:

1) The module String is then not found because the module is called 
string (no caps). Line 63 of pythonwriter.cpp (this is the 1.4.0beta2 
version) capitolizes the module names for output, so those still work, 
however the actual imported modules are broken because of this. In 
Python, all modules are actually lower-case, while classes are upper 
case. Thus, you'll have pickle.Pickle and string.String, vs. what the 
notes in pythonwriter.cpp seem to suggest.

2) There is no int or float module in Python, since it is a 
loosely-typed interpreter, these are internal. Also internal are the 
Python types list, dictionary, tuple, etc. Hence, there exists no list 
module as these are all in the __builtin__ space.

This problem seems to stem from the pythonwriter.cpp method of using a 
UMLClassifierList instance to derive the modules that need to be 
imported. Since this list instance apparently houses strongly-typed 
information about every datatype (i.e. string, list, int, etc.), it is 
not sufficient to use that list to import the modules, at least without 
modification.

Further, line 101 of pythonwriter.cpp:
headerName= headerName.replace(0, 1, first);
seems to be where the module name is capitolized, as is noted in number 
1 above. This might be considered broken in many cases. I have commented 
that line out of the source and the output is no longer broken- lower 
case python modules and upper-case generated modules. However, there are 
cases where this will not be sufficient.

I'm not familiar enough with the code to suggest a clean, permanant 
alternative, but it seems as though there might have to be some 
user-space configurations needed.

3) from module import * is a fairly messy way of cluttering up the 
namespace. It would probably be best to import module and let the user 
deal with namespaces when they write the method code- or perhaps a 
template in the manner of ../umbrello/headings could be derived or some 
other way to allow choice of import format. This is easily changed in 
line 102:
h<<"from "<<headerName<<" import *"<<m_endl;
which can become:
h<<"import "<<headerName<<m_endl;
which is a method that will not clutter the namespace and cause 
namespace clashes (Something quite possible in complex projects, which 
is where UML modeling is most useful). This I have changed in the code 
to good effect, however, is another case where module imports are site 
specific. This could possibly be a configure switch if runtime switching 
of this is difficult.

If the python code generator writer wants, I might be able to aid with 
solutions to some of these issues, but wanted to present the issues 
first, so I don't step on toes.

Thanks for the great software!
Cheers,
-JW
-- 
JW Pennington	| My Mind Map:http://oregonstate.edu/~penningj/
Masters Student: Bioresource Engineering & Geosciences
Oregon State Univ., Wilkinson 017, Corvallis Or. 97331
     "A computer without windows is like a dog
         without bricks tied to its head."