Relax Syntax for Augmented Arithmetic?

Chris Rebert clp2 at rebertia.com
Sun Jan 18 07:01:14 EST 2009


On Sun, Jan 18, 2009 at 3:42 AM, andrew cooke <andrew at acooke.org> wrote:
>> Therefore, Python requires you to rewrite the code in some other way
>> that makes your intentions more clear. For instance, why not use the
>> << operator instead?
>
> Right, but you're guessing what the context is.  Within a DSL it often
> makes a lot of sense to use operators for reasons that weren't
> originally intended.
>
> You even make the same case yourself indirectly.  The same argument
> you make could be made to say that << should only operator on values
> that can be shifted.  Now thankfully there is no way to test for that,
> so there is no restriction and, consequently, it is now widely
> accepted that no-one (even people arguing the case for constraints!)
> think it odd to use << for something other than its initial use.
>
> Obviously this kind of discussion has gone on since languages were
> first invented - it's the "how much rope" argument.  So rather than
> continue down that road I would just like to say that this feels like
> an inconsistency.  The other operators are *not* as restricted and
> this is making my life harder.

Indeed. Python happens to in this case draw the line at using the
augmented assignment operators for non-assignment. I personally see
this as reasonable because the = symbol has a consistent meaning in
Python (assignment) whereas the other plain operators, as you bring
up, consistently have no predetermined meaning; but I do agree that it
is in a sense an arbitrary restriction, like many programming language
design choices. However, Python was not explicitly designed for
creating DSLs, so it's kinda odd to complain about something Python
never claimed to support in the first place (although I do favor the
DSL in general-purpose-PL paradigm).

> It may sound crazy, but this may force me to use * and ** instead (the
> context is a language feature related to *args and **kargs, so the *
> and ** help convey the meaning).  And they have a much much stronger
> meaning to users, which will make my DSL harder to understand.  So in
> this case a blunt knife is making life harder.

Perhaps if you explained your particular predicament in more depth,
someone might be able to offer a workable suggestion.

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com



More information about the Python-list mailing list