New syntax for blocks

[samwyse]

Forgive me if i don't properly explain the problem but i think the
following syntax would be quite beneficial to replace some redundant
"if's" in python code.

if something_that_returns_value() as value:
    #do something with value

# Which can replace the following syntactical construct...

value = something_that_returns_value()
if value:
    #do something with value

I don't like the proposed syntax. I know, it's copied from the "with"
statement, but it makes the assignment look like an afterthought.
Plus, it's not good English when read aloud.

If you want something useful, wait two years for the moratorium to
expire and then figure out how to augment the "for" statement with an
"if" clause, as is currently done in comprehensions. In other words,
instead of this:
"for" target_list "in" expression_list ":" suite
let's have this:
"for" target_list "in" expression_list [ "if" expression_nocond ]
":" suite

You don't save much typing, but you really do save one indention
level. OTOH, I can see the use of an else-clause following the 'for'
as being even more confusing to anyone new to the language.

And there's also the fact that an expression_list consists of
conditional_expressions, which potentially use "if". You could
probably get the parser to figure it out based on the presence of the
"else" clause, but it wouldn't be easy.

 

[Robert Latest]

Just thinking out loud here...what if variable assignments could
return a value... hmmm? Not to them selfs of course but to a caller,
like an if statement...

if a=openfile:
# do something with a

That's like in C. I sometimes miss it in Python.

robert

 

[Terry Reedy]

I can quote the Zen too:

Special cases aren't special enough to break the rules.

You haven't demonstrated that your construct is "beautiful", or the
existing way of writing it is "ugly".

# apparently not ugly
x = func()
y = x + 1
z = 2*x

# also not ugly
var = range(N)
var.append(42)
find(23, var)

# still not ugly
var = range(N)
for x in var:
do_something_with(x, var)

# not ugly
var = MyClass()
with var.magic as x:
process(var)


# why is this ugly?
var = range(N)
if var:
process(var)

This is the first time I have seen this explanation and justification of
the status quo. Thanks for posting it so clearly.

....

What's so special about "truth-seeking"?

as a second use

for x in range(N) as var:
do_something_with(x, var)


That would save a line too, it would behave exactly as you specified, and
it uses virtually the identical syntax: "expr as name".

I know that Guido does not want to generalize 'as' as a substitute for
'=' except where really necessary. The three current uses in import,
with, and except statements are necessary because the object being bound
is produced in the statement itself and so the assignment cannot be
separated into a prior proper assignment statement.

Terry Jan Reedy

 

[Steven D'Aprano]

No I really don't. I want to be able to see the action performed
adjacent to the test, and not have to scroll up to down ten pages to
find whatever function it dispatched to.

Then re-write the dispatcher to return a tuple (match_object,
method_to_call) and then call them there at the spot.

 

[Steven D'Aprano]

I'm well aware of it, but I didn't think the proposal deserved to be
called stupid when it was a reasonable solution to a real need, even
though a workable and less intrusive option exists.

Fair enough, I was feeling grumpy at the time. Perhaps "stupid" was
unfair. Perhaps.

 

[Carl Banks]

Then re-write the dispatcher to return a tuple (match_object,
method_to_call) and then call them there at the spot.

Well I don't just want to call a method, so I can't take that advice.
Some actions will do more than just to call a method. And I don't
want to scroll up or down ten screens to see what the actions
associated with the regexp are. A dispatcher is out.

Carl Banks

 

[r]

Well I don't just want to call a method, so I can't take that advice.
Some actions will do more than just to call a method. And I don't
want to scroll up or down ten screens to see what the actions
associated with the regexp are. A dispatcher is out.

+1

The if... elif... construct that Carl provided coupled with the
proposed new syntax is much cleaner. And i'm not just saying that
because Steven called my idea stupid, well, *maybe* not? ;-)

PS: Does anyone know the textual smiley for apathy?

 

[Bruno Desthuilliers]

r a écrit :
-snip)

Just thinking out loud here...what if variable assignments could
return a value... hmmm? Not to them selfs of course but to a caller,
like an if statement...

if a=openfile:
# do something with a

Congratulations, you just reinvented one of the most infamous source of
bugs in C, C++, Java, PHP, javascript and quite a few other languages.
Believe it or not, but not allowing this in Python was a very deliberate
design choice.

Now whether it was a good choice is another troll^Mtopic !-)

 

[Bruno Desthuilliers]

Steven D'Aprano a écrit :
(snip)

Hint to would-be language designers: if you start off by claiming that a
new feature will save an indent level, when in fact it *doesn't* save an
indent level, you can save yourself from embarrassment by pressing Close
on your post instead of Send.

Mouaaaaaaaa !-)

Thanks Steven, you made my day

(me ---> go back mouaaaaaa)

 

[Bruno Desthuilliers]

r a écrit :

Oh i get it now! If i assign a valid value to a variable the variable
is also valid...thats...thats... GENUIS! *sarcasm*

It's not about "assigning a valid value to a variable", it's about the
name being created (or not) in the current namespace, whatever it's
bound to.

 

[r]

It's not about "assigning a valid value to a variable", it's about the
name being created (or not) in the current namespace, whatever it's
bound to.

And thats what my sarcasm was alluding to. Steven's argument is moot
because it will blow up either way due to the fact that "value" is non-
existent! Every argument that has been brought forth about how this
will break is just False and basically a bunch of FUD! It just garbage
so you can discredit the idea.

It's actually quite funny when someone as small as me can bring down
the iron curtain of c.l.py.
'''Mr. Gorbachev, Tear down this wall!'''

How about one of you "esteemed" Pythonista's show me a real example
where it will break. Show me (and the world) this H.G Wells
nightmarish scenario you speak of but show no solid proofs. Sorry
chaps, I don't buy snake oil!

Going, Going, Gonnnne, out the park!

PS: And if it were so dangerous why would someone as knowledgeable as
Carl have stepped in and supported it. I think because (like me) Carl
put's the language before sewing circles. I think it's just personal
like all the times before, that's OK, i have very thick skin! If it's
wrong for a good reason i will graciously accept that, but no one has
proven it's non-worth, not yet!

 

[Steven D'Aprano]

Congratulations, you just reinvented one of the most infamous source of
bugs in C, C++, Java, PHP, javascript and quite a few other languages.
Believe it or not, but not allowing this in Python was a very deliberate
design choice.

Oh, but those hundreds of thousands of man-hours lost to bugs caused by
assignment-as-an-expression is nothing compared to the dozens of man-
minutes saved by having one fewer line of code!


*wink*

 

[r]

On Nov 12, 7:44 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote

Oh, but those hundreds of thousands of man-hours lost to bugs caused by
assignment-as-an-expression is nothing compared to the dozens of man-
minutes saved by having one fewer line of code!

OK, what *if* the variable would only be valid in *that* block and
*that* block only! My first idea was to have the variable avaiable in
the local scope (if that is correct terminology?) so if the
conditional was in global space the value would be available in global
space, alright? You follow me? Now forget all that and observe the
following. ;-)

if value=range(10):
#this block *would* execute and "value" would be a valid name
#but only IN this block!!!
value.append(1)
elif value=fetch(0):
#this block would *never* execute
value.append(1)

value.append(1) -> this throws a NameError


Is that different than how other languages handle "assignment-by-
expression"? Will that avoid the cataclysmic downward spiral you speak
of? I can't see any problems with it AND it can still be applied to
myself and Carl's use cases.

Anybody is welcome to comment...?

 

[Bruno Desthuilliers]

r a écrit :

On Nov 12, 7:44 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote

OK, what *if* the variable would only be valid in *that* block and
*that* block only!

Python doesn't have the notion of a "block scope" (or "block namespace").

My first idea was to have the variable avaiable in
the local scope (if that is correct terminology?) so if the
conditional was in global space the value would be available in global
space, alright? You follow me? Now forget all that and observe the
following. ;-)

if value=range(10):
#this block *would* execute and "value" would be a valid name
#but only IN this block!!!
value.append(1)
elif value=fetch(0):
#this block would *never* execute
value.append(1)

value.append(1) -> this throws a NameError
Yuck.


Is that different than how other languages handle "assignment-by-
expression"? Will that avoid the cataclysmic downward spiral you speak
of?

It's different, but only worse. It doesn't solve the problem of
mystyping "=" instead of "==" - which is the reason why Python's
assignement is not an expression, and it's not even consistent with
mainstream languages that support "assignement as an expression".

I can't see any problems with it

I do see at least two big ones !-)

Now I don't mean there's not a use case for some "assign and test"
syntax - Carl provided a good one, and indeed there are some cases where
a dispatcher is *not* the simplest and obvious solution. But by all
means, not *this* syntax.

 

[Bruno Desthuilliers]

r a écrit :

And thats what my sarcasm was alluding to. Steven's argument is moot
because it will blow up either way due to the fact that "value" is non-
existent!

Sorry, but Steve's code, ie:

var = range(100)
if var:
...

will not break - after the first line, the name "var" exists, whether
it's bound to true or false value.

While with your proposal *as it is* (or at least as I and Steve
understood it), the existence of name "var" depends on some
unpredictable condition.

Every argument that has been brought forth about how this
will break is just False

Actually, identity testing on True or False is considered a very bad

and basically a bunch of FUD! It just garbage
so you can discredit the idea.

Please take a deep breath and calm down. There's no conspiracy, no
secret plan, no hidden agenda, and pointing out the shortcomings of a
proposals is definitly not "discredit"ing "the idea".

It's actually quite funny when someone as small as me can bring down
the iron curtain of c.l.py.
'''Mr. Gorbachev, Tear down this wall!'''

How about one of you "esteemed" Pythonista's show me a real example
where it will break.

Steve did. But I'm afraid you missed his point.

PS: And if it were so dangerous why would someone as knowledgeable as
Carl have stepped in and supported it.

Carl supported the idea of a syntax for "assignment and test", but
that's not what Steve's comments were about - well, it may be that Steve
also refuses to consider the whole idea, but he still has a good point
wrt/ some shortcoming of your idea in it's current state.

I think because (like me) Carl
put's the language before sewing circles. I think it's just personal
like all the times before,

Well, to be true, you did manage to make a clown of yourself more than
once, so don't be surprised if some people here tend to treat you as one
- even when you come up with something that _may_ have some value.

that's OK, i have very thick skin! If it's
wrong for a good reason i will graciously accept that, but no one has
proven it's non-worth, not yet!

wrong != non-worth. I mean: having some possibly valid use case doesn't
imply the proposed solution is the good one in it's current state. And
pointing out the shortcomings of the proposed solution doesn't imply the
problem is not real neither (now whether it's a critical enough problem
to _require_ a solution is another problem I won't even debate here).

Anyway, just going to personal considerations won't help. If you ever
hope to be taken seriously, first behave as a reasonably sensible and
mature person.

My (hopefully friendly) 2 cents.

 

[r]

On Nov 13, 3:20 pm, Bruno Desthuilliers

Well, to be true, you did manage to make a clown of yourself more than
once, so don't be surprised if some people here tend to treat you as one
- even when you come up with something that _may_ have some value.

Well, i must agree with that assessment. There have been some
*interesting* post from me here. I am human and prone to make mistakes
like anyone 0

My (hopefully friendly) 2 cents.

Thanks, the tone of this message was very good!

But anyway this is all moot now. I received a message last night from
a very intelligent person who i will not name since the message was
only addressed to me (no it's not Guido! I don't want to start any
crazy rumors people!) This "persons" response was *so* intelligent and
informative i was awe struck whilst reading it and concluded i have no
further basis to argue for this syntax change (not at this time
anyway). I would like to post this person's message for all to see but
i will not without their permission. I can now see how the pros *may*
not outweigh the cons and so with that i concede to my opponents.

Anyway, good discussion chaps!

 

[Jonathan Saxton]

Oh, but those hundreds of thousands of man-hours lost to bugs caused by
assignment-as-an-expression is nothing compared to the dozens of man-
minutes saved by having one fewer line of code!


*wink*

And if I ever find the genius who had the brilliant idea of using = to mean assignment then I have a particularly nasty dungeon reserved just for him. Also a foul-smelling leech-infested swamp for those language designers and compiler writers who followed his example. (Come to think of it, plagiarizing a bad idea is probably the worse evil.)

 

[MRAB]

And if I ever find the genius who had the brilliant idea of using =
to mean assignment then I have a particularly nasty dungeon reserved
just for him. Also a foul-smelling leech-infested swamp for those
language designers and compiler writers who followed his example.
(Come to think of it, plagiarizing a bad idea is probably the worse
evil.)

C was derived from BCPL, which used ":=" and "=".

Fortran uses "=" and ".EQ.", probably because (some) earlier autocodes
did.

It's a pity that Guido chose to follow C.

 

[r]

And if I ever find the genius who had the brilliant idea of using = to mean assignment then I have a particularly nasty dungeon reserved just for him.  Also a foul-smelling leech-infested swamp for those language designers and compiler writers who followed his example.  (Come to think of it, plagiarizing a bad idea is probably the worse evil.)

I think every new programmer wrestles with this dilemma in their first
days but very soon after accepts it as reality. As for me it made
perfect sense from day one to have '=' mean "assignment" and '==' to
mean "equality". Programming is not mathematics (on the contrary) they
are two sides of a mountain forever unknowing of each other but
sharing the same space. I think the syntax was chosen because the
alternatives are even worse AND since assignment is SO common in
programming, would you *really* rather type two chars instead of one?

 

[Nobody]

C was derived from BCPL, which used ":=" and "=".

ISTR that Ritchie said that he chose "=" because assignment is more common
than testing for equality, so C's approach meant less typing.

Fortran uses "=" and ".EQ.", probably because (some) earlier autocodes
did.

It's a pity that Guido chose to follow C.

OTOH, functional languages use "=" for binding (let x = ... in ...), which
is more like C initialisation (which also uses "=").

Python's "=" is somewhere between assignment and binding. It's arguable
that Python should also have ":=" for in-place modification (as opposed to
re-binding a name). E.g. for an array, "foo := bar" would be equivalent to
"foo[:] = bar".