Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > New syntax for blocks

Reply
Thread Tools

New syntax for blocks

 
 
r
Guest
Posts: n/a
 
      11-10-2009
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 dunno, just seems to make good sense. You save one line of code but
more importantly one indention level. However i have no idea how much
trouble the implementation would be? Now i know you could write a
function and do the following to forgo the indention...

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

.....but that's even uglier and i would like the construct to work in
both sinlge 'ifs' and also conditional's Now some might say...Whats
the big deal, you only save one line of code?...True, but if you can
save one line of code 100 or 1000 times how many lines of code is that
my inquisitive friend?
 
Reply With Quote
 
 
 
 
Robert Latest
Guest
Posts: n/a
 
      11-10-2009
r 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 dunno, just seems to make good sense. You save one line of code but
> more importantly one indention level.


Typical case in matching regexes. But where do we save an indentation
level?

Also it's not the "if" that is (if at all) redundant here but the assignment.

robert
 
Reply With Quote
 
 
 
 
Bearophile
Guest
Posts: n/a
 
      11-10-2009
r:

> i think the following syntax would be quite beneficial
> to replace some redundant "if's" in python code.


http://python.org/dev/peps/pep-3003/

bearophile
 
Reply With Quote
 
steve
Guest
Posts: n/a
 
      11-10-2009
On 11/11/2009 02:05 AM, steve wrote:
> Hi,
>
> On 11/11/2009 12:53 AM, r wrote:
>> [...snip...]
>> i dunno, just seems to make good sense. You save one line of code but
>> more importantly one indention level. However i have no idea how much
>> trouble the implementation would be?

> I guess the problem would be that this would go against the (design ?) principle
> of not evaluating functions in the 'if' conditional part, because it would lead


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ gah !! sorry, what was I thinking ??
That is just not true !! Anyways, at least the assignments not being allowed bit
is true.


cheers,
- steve

--
random non tech spiel: http://lonetwin.blogspot.com/
tech randomness: http://lonehacks.blogspot.com/
what i'm stumbling into: http://lonetwin.stumbleupon.com/
 
Reply With Quote
 
steve
Guest
Posts: n/a
 
      11-10-2009
Hi,

On 11/11/2009 12:53 AM, r 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 dunno, just seems to make good sense. You save one line of code but
> more importantly one indention level. However i have no idea how much
> trouble the implementation would be?

I guess the problem would be that this would go against the (design ?) principle
of not evaluating functions in the 'if' conditional part, because it would lead
to statements such as:

if something(someother(sumsuch() + thisthing())) + ... == value:

also, assignment in the 'if' statement was consciously avoided, if I am not
mistaken.

However, the same 'effect' can be obtained with the 'with' statement:
------------------------------------------------
class something_that_returns_value:
def __init__(self, x):
# do something with x, self.value is what ought to be 'returned'
self.value = x

def __enter__(self):
if self.value:
return self.value
else:
return ValueError()

def __exit__(self, type, value, traceback):
return True


with something_that_returns_value(1) as value:
print value

with something_that_returns_value(0) as value:
print value

with something_that_returns_value(False) as value:
value + 10
# never reach here
value.dosomething()

with something_that_returns_value([1,2,3]) as value:
value.append(4)
print value

------------------------------------------------
nasty huh ?

cheers,
- steve

--
random non tech spiel: http://lonetwin.blogspot.com/
tech randomness: http://lonehacks.blogspot.com/
what i'm stumbling into: http://lonetwin.stumbleupon.com/
 
Reply With Quote
 
r
Guest
Posts: n/a
 
      11-10-2009
On Nov 10, 2:08*pm, Robert Latest <(E-Mail Removed)> wrote:
(..snip..)
> Also it's not the "if" that is (if at all) redundant here but the assignment.


Not exactly. The assignment happens only once just as the boolean
check of "if <value>" happens once. The redundancy is in validating
the existence of a truthful value contained in a variable after
assignment of a value to that same variable. It's like putting on your
tennis shoes and then asking yourself 'am i wearing tennis shoes?'. Of
course we all know *why* we must verify the existence of value
afterward and the shoe analogy doesn't translate 1:1 to programming.
It's more like...

shoes = grab_a_pair_of_shoes_or_none_and_apply_to_feet()
if shoes:
shoes.this()
shoes.that()

Now did we find a pair of shoes or did we fail because the lights were
out and all we accomplished was to toil around in the closet for half
an hour bumping our head before finally giving up and returning empty
handed?

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

(if(a.__eq__(openfile)))

Python would need to stuff the value of openfile into "a", then add
the variable "a" to the proper namespace, then evaluate if "a" is
True. This would read more naturally than even my first postulation. I
bet it would confuse the crap out of noobies though!

So basically with the new syntax what your saying is this:
if the value of this expression bools to False, toss it away because i
don't need it, else assign the value to a local variable and run the
block. Basically your encaspulating an if..else block in one line of
code.


 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-11-2009
On Tue, 10 Nov 2009 12:45:13 -0800, Bearophile wrote:

> r:
>
>> i think the following syntax would be quite beneficial to replace some
>> redundant "if's" in python code.

>
> http://python.org/dev/peps/pep-3003/


I knew it wouldn't take long for people to start responding to any
proposal with "don't bother, there's a moratorium".

Of course in this case, the correct response would have been "don't
bother, it's a stupid idea, moratorium or no moratorium".

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.



--
Steven
 
Reply With Quote
 
Carl Banks
Guest
Posts: n/a
 
      11-11-2009
On Nov 10, 11:23*am, r <(E-Mail Removed)> wrote:
> if something_that_returns_value() as value:
> * * #do something with value


Been proposed before. No one has bothered to write a PEP for it, so I
can't say for sure how the Python gods would react, but I suspect a
"meh, don't think it's important enough". This, even though it's more
useful than you are giving it credit for. It's a minor improvement.


Carl Banks
 
Reply With Quote
 
Carl Banks
Guest
Posts: n/a
 
      11-11-2009
On Nov 10, 7:12*pm, Steven D'Aprano
<(E-Mail Removed)> wrote:
> On Tue, 10 Nov 2009 12:45:13 -0800, Bearophile wrote:
> > r:

>
> >> i think the following syntax would be quite beneficial to replace some
> >> redundant "if's" in python code.

>
> >http://python.org/dev/peps/pep-3003/

>
> I knew it wouldn't take long for people to start responding to any
> proposal with "don't bother, there's a moratorium".
>
> Of course in this case, the correct response would have been "don't
> bother, it's a stupid idea, moratorium or no moratorium".


r didn't actually give a good example. Here is case where it's
actually useful. (Pretend the regexps are too complicated to be
parsed with string method.)

if re.match(r'go\s+(north|south|east|west)',cmd) as m:
hero.move(m.group(1))
elif re.match(r'take\s+(\w+)',cmd) as m:
hero.pick_up(m.group(1))
elif re.match(r'drop\s+(\w+)',cmd) as m:
here.put_Down(m.group(1))

I wouldn't mind seeing this in Python for this exact use case,
although I'd rather the syntax to be more like the following so that
you can bind something other than the condition if need be.

if m with m as re.match(regexp,command):

Moot point for the next two years, and probably forever as I doubt it
would ever happen.



Carl Banks
 
Reply With Quote
 
r
Guest
Posts: n/a
 
      11-11-2009
On Nov 10, 9:12*pm, Steven D'Aprano
<(E-Mail Removed)> wrote:
(..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.


Does anyone out there know the textual smiley for conveying an
overwhelming feeling of embarrassment? Also may want to send the one
for feeling of confusion too
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Methods and blocks - not that clear when blocks passed into Steven Taylor Ruby 9 04-27-2009 08:46 AM
"Building Blocks" are "Application Blocks" Arjen ASP .Net 3 02-27-2005 01:06 AM
Curly syntax for muliline blocks... Radley Smith Ruby 7 08-12-2004 05:28 PM
procs/blocks - blocks with procs, blocks with blocks? matt Ruby 1 08-06-2004 01:33 AM



Advertisments