Contact: fumanchu@aminus.org

Log in as guest/geniusql to create tickets

Changeset 254

Show
Ignore:
Timestamp:
11/28/08 17:39:16
Author:
fumanchu
Message:

Removing the now-unused decompile module.

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • trunk/geniusql/logic.py

    r217 r254  
    5656     
    5757    You'll notice, in this first example, some extra parentheses in the final 
    58     lambda. The lambda has already undergone an explicit compile/decompile 
     58    lambda. The lambda has already undergone an explicit parse/deparse 
    5959    step. These differences don't affect the logic in any way, but it's 
    60     impossible to guess the exact original syntax when decompiling. 
     60    impossible to guess the exact original syntax when deparsing. 
    6161     
    6262    However, be advised of this IMPORTANT point. When you form an Expression 
    …… 
    105105 
    106106 
    107 Derivation (Decompilation) and Translation: 
    108     'Deriving' is the opposite of 'parsing'. The codewalk.LambdaDecompiler 
     107Deparsing and Translation: 
     108    'Deparsing' is the opposite of 'parsing'. The codewalk.LambdaDeparser 
    109109    class walks a function or code object and produces equivalent Python 
    110110    code in a string. 
    111111     
    112112    >>> e = logic.Expression(lambda x: x.a == 3 and (x.b > 1 or x.b < -10)) 
    113     >>> codewalk.LambdaDecompiler(e.func).code() 
    114     'lambda x: not ((x.a == 3) and ((x.b > 1) or (x.b < -10)))' 
     113    >>> e.code() 
     114    'lambda x: (x.a == 3) and ((x.b > 1) or (x.b < -10))' 
    115115     
    116116    However, we are not limited to Python statements of our Expression! 
    117     Another decompiler might produce our Expression in another language; 
     117    Another deparser might produce our Expression in another language; 
    118118    this example produces a WHERE clause for SQL (a declarative language!): 
    119119     
    …… 
    121121                             x.Date > datetime.date(2004, 2, 14) and 
    122122                             x.Name.endswith('_')) 
    123     >>> ADOSQLDecompiler(e).code() 
     123    >>> SQLServerDeparser([(None, t)], e, sqlserver.SQLServerTypeSet()).code() 
    124124    "([Group] = '3' and [Date] > #2/14/2004#) and [Name] Like '%\\_'" 
    125125 
    …… 
    128128    __setstate__). You might notice that the function itself is *not* 
    129129    pickled; instead, its code() method is called, which produces a 
    130     string representation of the function (decompilation). This makes 
     130    string representation of the function (deparsing). This makes 
    131131    pickled Expressions much more stable across Python versions than, 
    132132    say, storing the function's co_code. However, this presents a problem 
    …… 
    304304        """Return source code for self.func.""" 
    305305        if hasattr(self, 'func'): 
    306             decom = astwalk.LambdaDeparser(self.ast, env=builtins) 
    307             return decom.code() 
     306            dep = astwalk.LambdaDeparser(self.ast, env=builtins) 
     307            return dep.code() 
    308308        else: 
    309309            return 'function not yet loaded'