Python import

[brucetrask2]

Hello, Just curious. Are there any plans to allow python code to be imported?
Thanks

[codemanyak]

There haven't been decisive plans to implement it very soon, because of three reasons:

• The indentation policy in Python respresents a new difficulty for the scanning / parsing;
• The import of object-oriented code conceptually overstrains the power of Structorizer (the Java / Processing import has caused a lot of dubious workarounds and compromises). This let me hesitate to go on in this direction while we haven't got a better strategy;
• So far noone has requested it 😏 .

Well, the third obstacle seems just have gone. The only competent solution for the second obstacle seems to be enhancing Structorizer with the capability to create UML class diagrams, which would approach it to tools like Unimozer, ArgoUML, or the like, which is an enormous challenge. W.r.t. the first obstacle, the parser module we happened to use for code import in Structorizer indeed offers a mode to process grammars where whitespace isn't ignored but part of the grammar rules. We simply haven't ever tried it. And it may not get easier by the fact that the actual number of spaces (or tabs) for an indentation level in Python isn't exactly fix. On the other hand, the rest of the Python grammar rather ignores white space.

I will have a look into the indentation problem first. Perhaps a preprocessor might offer a solution.

[codemanyak]

@brucetrask2
Just an interim status report:
After a sequence of (so far unsuccessful) attempts to coerce the official Python grammar (which is of PEG type) such that it fits to the needs of the LALR(1) parser incorporated in Structorizer (still about 61 hard rule conflicts), I see the following alternative ways to go on (and to decide among):

1. Further to simplify the grammar (by weakening the rules. i.e. accepting more than is "allowed") under the assumption that only syntactically correct Python programs will be fed. This would mean less strict syntax restrictions for the expressions while adhering to the established import paradigms.
2. To try to achieve a LALR(1) grammar by imposing narrowing syntactical restrictions to the importable Python code, i.e., to search for a viable Python language subset. Like option 1 (and in contrast to 3 and 4), this would avoid the integration of a new parser library, but may of course become a source of user frustration. (It would not be completely new, given that the import for C, COBOL, and Java already implies sort of such syntactical restrictions.)
3. To add an additional PEG parser library to Structorizer and respective import routines without changing the implemented import mechanisms for Pascal, C, Java, Processing, and COBOL which will inflate the product and may possibly confuse users (different import strategies with potentially more less differing behaviour). Advantage: It might significantly facilitate further import projects as it widens the range of acceptable grammars.
4. To replace the recent LALR(1)-based import tools by a PEG parser module (to avoid redundancy), which would require completely to rewrite the existing code import stuff. Obvious drawbacks are the extra efforts to replace running code and the potential risk of disruption and new defects. Perhaps, though, the size of the product wouldn't grow as fast as with approach 3.

Obviously, in order to achieve option 4 (if favoured), option 3 would be a sensible intermediate step and proof of concept test, anyway. Hence, the next activities will chiefly focus on options 1 and 3.