exarkun at divmod.com wrote:
>On Tue, 14 Sep 2004 08:04:45 -0400, Kevin Jacobs <jacobs at theopalgroup.com> wrote:
>
>
>>Phillip J. Eby wrote:
>>
>>
>>>For these reasons, I'd feel more comfortable with either a literal
>>>syntax (to address algebra, SQL, etc.) or some type of special infix
>>>notation to allow new operators to be defined in Python, so that it
>>>isn't necessary to use prefix or method notation to perform operations
>>>like these. Neither of these solutions burdens applications that
>>>don't need the feature(s).
>>>
>>>
>>Both of your alternatives are being used in some form and
>>neither is really satisfactory. Literal representations require
>>complex parsers, when the Python parser is really what is
>>desired.
>>
>>
> Python's parser is already available, through the compiler module. The example given earlier, query("x and y or z"), is relatively straightforward to implement as a set of AST manipulations.
>
>
While strictly true, your suggestion still requires two
distinct parsers (although one implementation) and
two distinct parsing contexts (one embedded in a literal
string).
The use cases I care about involve minimizing the difference
between evaluating regular Python expressions and
ADT instances -- plus the ability to mix constructs from both
in a seamless way. If Python didn't support any over-loadable
ADT methods, then this wouldn't be an issue. However,
the problem is that virtually all ADT methods _are_ defined
_except_ logical conjunction and disjunction. Thus, I am
more concerned with correcting this oversight than I am with
a fraction of a percent in slowdown in real applications.
(or at least micro-benchmarks are _not_ representative
of any real world situations I've ever cared about)
-Kevin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4