Idea for P3K

[Méta-MCI \(MVP\)]

Hi!

print become a function ; OK

I thought: and why the affection (=) would not become, also, a function?
Examples:
a = 123 return 123
b,c = 543.21, "LOL" return (543.21, "LOL")



@-salutations

Michel Claveau

 

[Arnaud Delobelle]

Hi!

print become a function ; OK

I thought: and why the affection (=) would not become, also, a function?
Examples:
a = 123 return 123
b,c = 543.21, "LOL" return (543.21, "LOL")

Do you mean a = 3 would become an *expression* ?

For one thing, it wouldn't fit with the Python's function call syntax:

f(4, x=2)

currently means that f is called with first positional argument equal
to 4 and named argument 'x' equal to 2.

Moreover, it seems to me utterly unpythonic (and I don't often feel
like using this word!). Binding a name to a new value is something
that needs to be clearly visible in the code flow, not hidden within
an expression

E.g.

f(3, 4 + (x=2), 5)

has the side-effect that x is now bound to 2, but it is only apparent
if one closely scrutinises the code.

 

[Méta-MCI \(MVP\)]

Hi!

I don't often feel like using this word

Look at languages like OCAML or F #

@-salutations

 

[Gary Herron]

Hi!


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. Most of us in the community support that
point of view and would fight the introduction of such a feature into
Python.

Gary Herron

 

[Arnaud Delobelle]

Hi!


Look at languages like OCAML or F #

While I like Objective Caml, it is definitively not Python!

 

[Daniel Fetchinson]

I don't often feel like using this word

Look at languages like OCAML or F #

I looked at OCAML and F#. Now what?

Cheers,
Daniel

 

[bruno.desthuilliers]

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.

 

[John Roth]

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

 

[bruno.desthuilliers]

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].

Indeed. Neither are expression-based languages anyway.

 

[Diez B. Roggisch]

Hi!


Look at languages like OCAML or F #

The point being? Yes, shockingly enough other languages have other syntax &
semantics.

Diez