Idea for P3K

[John Roth]

On May 7, 3:03 pm, "bruno.desthuilli... at gmail.com"
<bruno.desthuilli... at gmail.com> wrote:
> On 7 mai, 21:41, Gary Herron <gher... at islandtraining.com> wrote:
>
> > Méta-MCI (MVP) wrote:
> > > Hi!
>
> > >> I don't often feel like using this word
>
> > > Look at languages like OCAML or F #
>
> > > @-salutations
>
> > Well of course, we're all well aware of other languages that allow
> > variables to be bound in the middle of an expression.  It's just that
> > Python was purposely created without that (mis)feature because it's so
> > unclear, and easy to abuse.
>
> This is the same argument that has been used to justify the lack of MI
> and operator overloading in Java.
>
> Not that I would support having assignment as expressions in Python
> (wouldn't fit the whole design IMHO), but this is still a somewhat
> arbitrary design choice, not necessarily a GoodThing(tm) by itself -
> well designed expression-based languages have their strength too.

Clearly this leaves C and C++ out [grin]. After all, a significant
problem in those languages is confusing = and ==. I wouldn't mind
seeing a way of assigning in the middle of an expression because it
comes up fairly frequently when one needs to do a test and save the
result at the same time. However I absolutely do not want to see the
operator be =.

However, if it's not =, then it opens another can of worms, that is,
what to call it, and where it fits into the precedence structure. <--
might work.

John Roth