«

On Nov 10, 1:23*pm, r <rt8...@gmail.com> wrote:
> 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.

r wrote:
> 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

Steven D'Aprano wrote:

>>> Why is the third example, with an if... test, so special that it needs
>>> special syntax to make it a two-liner?
>> ...because Beautiful is better than ugly.
>
> 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

On Wed, 11 Nov 2009 03:52:45 -0800, Carl Banks wrote:

>> This is where a helper function is good. You want a dispatcher:
>
> 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

On Wed, 11 Nov 2009 04:00:09 -0800, Carl Banks wrote:

>> as has been posted before and again in a slightly different form in
>> Steve's post.
>
> 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.


--
Steven

On Nov 11, 4:12*pm, Steven D'Aprano
<ste...@REMOVE.THIS.cybersource.com.au> wrote:
> On Wed, 11 Nov 2009 03:52:45 -0800, Carl Banks wrote:
> >> This is where a helper function is good. You want a dispatcher:
>
> > 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.

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

On Nov 11, 9:04 pm, Carl Banks <pavlovevide...@gmail.com> wrote:
(Carl's reply to Steven's comments...)

> 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?

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 !-)

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)

r a écrit :
> On Nov 11, 2:37 am, Steven D'Aprano
> <ste...@REMOVE.THIS.cybersource.com.au> wrote:
>> On Wed, 11 Nov 2009 00:08:58 -0800, r wrote:
>
>>> Yea it's called a NameError. Would it not also blow up in the current
>>> state of syntax usage?
>> No.
>>
>>> if var:
>>> print 'var'
>>> Traceback (most recent call last):
>>> File "<pyshell#45>", line 1, in <module>
>>> if var:
>>> NameError: name 'var' is not defined
>> You missed a line:
>>
>> var = range(N)
>> if var:
>
> 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.