Re: New syntax for blocks
Carl Banks writes: > On Nov 19, 12:20 am, Gregory Ewing > wrote: > > They all still seem to work -- presumably generating the appropriate > > unicode characters now instead of MacRoman. > > ³It¹s about time.² I � Unicode. (lrf, gung *vf* qryvorengr, sbe gur uhzbhe-vzcnverq nzbat lbh) -- \ “Courteous and efficient self-service.” —café, southern France | `\ | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 19, 12:20 am, Gregory Ewing wrote: > Steven D'Aprano wrote: > > I don't know what the state of the art on Mac is > > these days, but in 1984s Macs had a standard keyboard layout that let you > > enter most available characters via the keyboard, using sensible > > mnemonics. E.g. on a US keyboard layout, you could get ≠ by holding down > > the Option key and typing =. > > They all still seem to work -- presumably generating the > appropriate unicode characters now instead of MacRoman. ³It¹s about time.² Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Input characters not available on the keyboard (was: New syntax for blocks)
Gregory Ewing writes: > Steven D'Aprano wrote: > > I don't know what the state of the art on Mac is these days, but in > > 1984s Macs had a standard keyboard layout that let you enter most > > available characters via the keyboard, using sensible mnemonics. > > E.g. on a US keyboard layout, you could get ≠ by holding down the > > Option key and typing =. […] > I don't think there's any left-arrow character available on the > keyboard though, unfortunately. I'm glad to live in an age when free-software “Input Methods” for many different character entry purposes are available in good operating systems. I switch between them using SCIM http://www.scim-im.org/>. At a pinch, when I'm without my GUI, I can turn some of them on with Emacs. Common input methods → joy. I usually default to the “rfc1345” input method which has many non-keyboard characters available via two-character mnemonics from the eponymous RFC document — which appears to be about the only purpose that document has any more. -- \ “The most dangerous man to any government is the man who is | `\ able to think things out for himself, without regard to the | _o__) prevailing superstitions and taboos.” —Henry L. Mencken | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
Steven D'Aprano wrote: I don't know what the state of the art on Mac is these days, but in 1984s Macs had a standard keyboard layout that let you enter most available characters via the keyboard, using sensible mnemonics. E.g. on a US keyboard layout, you could get ≠ by holding down the Option key and typing =. They all still seem to work -- presumably generating the appropriate unicode characters now instead of MacRoman. I don't think there's any left-arrow character available on the keyboard though, unfortunately. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 18, 5:27 pm, Steven D'Aprano wrote: > On Wed, 18 Nov 2009 18:28:11 +1300, greg wrote: > > r wrote: > >> 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? > > > Smalltalk solved the problem by using a left-arrow character for > > assignment. But they had an unfair advantage in being able to use a > > non-standard character set on their custom-built machines. > > > We should be able to do a lot better now using Unicode. We could even > > heal the <> vs != rift by using a real not-equal symbol! > > The problem isn't with the available characters, but with *typing* them. > > It is hard to enter arbitrary Unicode characters by the keyboard, which > frankly boggles my mind. I don't know what the state of the art on Mac is > these days, but in 1984s Macs had a standard keyboard layout that let you > enter most available characters via the keyboard, using sensible > mnemonics. E.g. on a US keyboard layout, you could get ≠ by holding down > the Option key and typing =. > > For me, I had to: > > Click Start menu > Utilities > More Applications > KCharSelect. > Click through thirty-four(!) tables scanning by eye for the symbol I > wanted. > Click the ≠ character. > Click To Clipboard. > Go back to my editor window and paste. > > -- > Steven ♂ <-- Heres a free lesson... Stephen, hold down and press twice, then release . ;-) PS: But please lets not start using Unicode chars in programming, you guy's already know how much i *hate* Unicode. -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Wed, 18 Nov 2009 18:28:11 +1300, greg wrote: > r wrote: >> 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? > > Smalltalk solved the problem by using a left-arrow character for > assignment. But they had an unfair advantage in being able to use a > non-standard character set on their custom-built machines. > > We should be able to do a lot better now using Unicode. We could even > heal the <> vs != rift by using a real not-equal symbol! The problem isn't with the available characters, but with *typing* them. It is hard to enter arbitrary Unicode characters by the keyboard, which frankly boggles my mind. I don't know what the state of the art on Mac is these days, but in 1984s Macs had a standard keyboard layout that let you enter most available characters via the keyboard, using sensible mnemonics. E.g. on a US keyboard layout, you could get ≠ by holding down the Option key and typing =. For me, I had to: Click Start menu > Utilities > More Applications > KCharSelect. Click through thirty-four(!) tables scanning by eye for the symbol I wanted. Click the ≠ character. Click To Clipboard. Go back to my editor window and paste. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
r wrote: 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? Smalltalk solved the problem by using a left-arrow character for assignment. But they had an unfair advantage in being able to use a non-standard character set on their custom-built machines. We should be able to do a lot better now using Unicode. We could even heal the <> vs != rift by using a real not-equal symbol! -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
MRAB wrote: Fortran uses "=" and ".EQ.", probably because (some) earlier autocodes did. I think Fortran used .LT. and .GT. because some early character sets didn't have < and > symbols. Having done that, it probably seemed more consistent to use .EQ. for comparison than to break the pattern and use =. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Tue, Nov 17, 2009 at 10:15 AM, r wrote: > On Nov 17, 9:28 am, Jonathan Saxton wrote: > > > 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? > Well, equality testing is very very common too... I concede, a bit less common (probably) then assignment, but still. I too never had any issue with getting assignment verses equality-testing with the operations as concepts (except that it is a not terribly uncommon typo for me to type = and mean ==, and I'm quite happy its a syntax error as a result), but in an ideal world? If I were today making my own private little programming language to share with the world... I wish no one would use a single "=" by itself for anything. Neither assignment nor equality testing. For me, the problem comes down to readability; when one sees "x = y", what do they say in their head? "x equals y" -- the meaning of which for an individual can depend on the context and intonation, how they are reading the word "equal" in their head. They might be saying it as a verb, declaring "let x become y", or they my be saying it as an noun, testing "x is equal to y". I don't ever have that problem, but I know a lot of new programmers do and its something which can stick for quite awhile. The word "equal" is just sort of dodgy and fuzzy to the initiate and they start to confuse the two entirely separate concepts (equality testing, assignment) by having the same symbol in programming represent both. Personally! I wish that equality and assignment both got their hands off the bare "=" and let mathematics keep it, and programming take say, ":=" for assignment and "==" for equality testing (or whatever, not advocating a specific syntax) and have "=" by itself be an error all around. So yes, I'd actually much rather type two characters instead of one-- purely in the hypothetical sense that this conversation has gone down. :) --S -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 17, 7:28 am, Jonathan Saxton wrote: > On Thu, 12 Nov 2009 21:27:31 +0100, Bruno Desthuilliers wrote: > >> 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* > > 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.) There is absolutely nothing wrong with using = for assignment. The problem in C was allowing an assignment within a conditional expression. Now *that* was a bonehead idea! (Hingsight is 20/20, of course.) Python does not allow that, so there is no problem. Nor do most other languages allow it. -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Tue, 17 Nov 2009 17:31:18 +, MRAB wrote: >> 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 "=". 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". -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 17, 9:28 am, Jonathan Saxton wrote: > 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
Jonathan Saxton wrote: On Thu, 12 Nov 2009 21:27:31 +0100, Bruno Desthuilliers wrote: 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* 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. -- http://mail.python.org/mailman/listinfo/python-list
RE: New syntax for blocks
On Thu, 12 Nov 2009 21:27:31 +0100, Bruno Desthuilliers wrote: >> 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* 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.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 13, 3:20 pm, Bruno Desthuilliers wrote: (...snip...) > > 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. 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! -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
r a écrit : > On Nov 12, 2:37 pm, Bruno Desthuilliers > wrote: > >>> 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. > > 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 practice. You really want equality testing > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
r a écrit : > On Nov 12, 7:44 pm, Steven D'Aprano 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! 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Thu, Nov 12, 2009 at 8:10 PM, r wrote: > On Nov 12, 7:44 pm, Steven D'Aprano 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. ;-) > > Assignment is a statement and not an expression in Python intentionally; its not just some random artifact. It was a decision. If you really want to overcome it, you need to show a SERIOUSLY huge amount of justification that goes far beyond 'hey, it saves me one line in certain situations'. You keep mentioning "elegant" and "clean" in the examples you've provided, but those terms (while often applied to Pythonisms) are very subjective. What you find elegant and clean, others may find prone to confusion or misunderstanding. There's a certain class of languages which treat assignments as expressions-- the C family most prominently. And some people love them and will forever seek it, as there is indeed a reduction of lines and/or code to express certain ideas if you use assignments as expressions. No one is really arguing against that. The argument against it is that it is extremely easy to screw up in ways which are extremely difficult to debug. > if value=range(10): > The problem with this is, its far too easy to type this but mean, "if value==range(10):" or some such. And then its far too hard to figure out why your program is wrong when it starts producing incorrect results. This has been a source of countless bugs over the years and years of C programming-- true, an excellent programmer will never make the mistake. But get some group of people together maintaining some codebase, and someone's gonna miss something, and others just will fail to see it as they scan over the code trying to figure out what's wrong. Granted, you can produce shorter and more concise code if you can make assignments expressions instead of statements. However, your code isn't anymore READABLE. And readability is more important then concise in Python, /on purpose/. It's true that you can usually produce a program in far fewer lines of Python code then you can in certain other languages not to be named; but that isn't the overriding goal. That's not a zen. There's no doctrine of, "Shorter is better". Readability counts is, though. The expression, "x=y" in a statement is far too easy to mess up with "x==y". You can try to do screwy things with the syntax like your original proposal of, "if x as y" to make it so a single missed = won't mess it up, but that doesn't really improve readability. It makes it less likely to accidentally screw things up, but also makes it very hard to scan code and determine where names are created and assigned to objects. Yeah, we use "as" in a few situations for assignment already. But those are all special constructs which stand on their own. Try/except, with, and import support it; but when scanning code those stand out on their own anyways, and none of them support arbitrarily complex expressions. The if statement does. The "as" can become lost within that expression, and when looking in the block of code you can easily miss where the binding occurs. The proposal that the variable exists only within the 'if' block is a non-starter; Python's namespaces don't work like that, they don't have arbitrary blocks of private variables. You just have your local, global, and builtin namespace (and static nested namespaces for closures)... changing that is a whole other can of worms, and this is not the proposal to do it. --S -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 12, 7:44 pm, Steven D'Aprano 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...? -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Thu, 12 Nov 2009 21:27:31 +0100, Bruno Desthuilliers wrote: > 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* -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 12, 2:37 pm, Bruno Desthuilliers wrote: > > 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. 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, Goe, 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! -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
r a écrit : > On Nov 11, 2:37 am, Steven D'Aprano > 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 "", line 1, in >>> 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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. Mou !-) Thanks Steven, you made my day (me ---> go back mouaa) -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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 !-) -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 11, 9:04 pm, Carl Banks 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 11, 4:12 pm, Steven D'Aprano 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 10, 1:23 pm, 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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
Hi,
On 11/11/2009 12:30 PM, r wrote:
[...snip...]
I think what has escaped everyone (including myself until my second
post) is the fact that what really needs to happen is for variable
*assignments* to return a boolean to any "statements" that evaluate
the assignment -- like in an "if" or "elif" construct. The current
"with" statement cannot replace that action and was never meant for
such things.
True. It escaped me too that the assignment was happening and I was only relying
on the side-effect to break out of the with statement. So, I'm sorry.
Very clean, very elegant solution to a messy problem that pops up in
python code quite often. It not only saves one distracting line of
code per usage but makes the code more readable. If there is an
existing solution, Steve's is not it.
However, if it is /only/ about saving that one 'distracting' line of the final
code that you are concerned about (which I think is the case), how about:
-
def deco(f):
def assign(x):
if x:
globals()['value'] = f(x)
return True
else:
globals()['value'] = False
return assign
@deco
def something_that_returns_value(x):
# do something with x and return a value
return x
if something_that_returns_value(1) and value:
print value
if something_that_returns_value(0) and value:
print value
# or if you cannot decorate something_that_returns_value in it's definition
# for instance, a method from another module, then ...
if deco(something_that_returns_value)(0) and value:
print value
# Note that we've just siphoned off the assignment elsewhere. One problem
# tho' is, irrespective of the conditional code being entered 'value' would
# be initialized, which is what your ...
#
# if something_that_returns_value(x) as value:
#
# ... would also have done (if such a thing existed).
# To avoid this side effect we could also do:
if (something_that_returns_value(0) and value) or globals().pop('value'):
print value
# ...but that is beginning to look too much like the perl.
Well, that's all i could think of to overcome one line of extra code.
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/
--
http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 10, 9:44 pm, Terry Reedy wrote: > Carl Banks wrote: > > > 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)) > > The effect of this proposal can already be accomplished with a 'pocket' > class Nice metaphorical name. > 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. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 10, 9:37 pm, Steven D'Aprano wrote: > On Tue, 10 Nov 2009 20:13:21 -0800, Carl Banks wrote: > > On Nov 10, 7:12 pm, Steven D'Aprano > > 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)) > > 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. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 11, 2:37 am, Steven D'Aprano 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 "", line 1, in > > 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* > The problem isn't the if statement, it is the conditional assignment. > Sometimes "x as y" creates y, sometimes it doesn't, according to some > mysterious rule something to do without whether the assignment is true or > false, whatever that means. i don't find True or False, Black or White, 1 or 0, Alpha or Omega to be mysterious...? If you still cannot grasp this simple concept then i fear i may not be able to help you understand Steven. (snip: excessive inane blubbering) > > No if you read my post my usage of this syntax only includes "if" and > > "elif" constructs and nothing "else" because usage outside of such a > > "truth-seeking" construct is pointless. > > What's so special about "truth-seeking"? > > for x in range(N) as var: > do_something_with(x, var) You could do that but why would you want to. A "for x in range(N)" is just so you can loop N times. And since changing the values in a list whilst looping over it is the sport of fools then what usefulness would a variable be for such a construct? You have failed to prove the usefulness of this syntax Steven. I suggest you go back and read over my posts again and then marinate on the contents for a while. THEN come back with an argument based in reality and we will try again...You know at one time i actually considered you a formidable foe, well these times they are a chang'in right Dylan? -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Wed, 11 Nov 2009 00:08:58 -0800, r wrote: >> > #variable "var" will never be created! >> That will cause no end of trouble. >> if range(N) as var: >> do_something_with_var() >> if var: >> print "Oops, this blows up if N <= 0" >> Conditional assignments are a terrible idea. > > 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 "", line 1, in > if var: > NameError: name 'var' is not defined You missed a line: var = range(N) if var: ... The problem isn't the if statement, it is the conditional assignment. Sometimes "x as y" creates y, sometimes it doesn't, according to some mysterious rule something to do without whether the assignment is true or false, whatever that means. >> 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) >> Would you suggest we can write this? >> # instead of var = range(N) >> p = range(N).index(5) as var # var might be range(N), or undefined. >> var.append(42) > > No if you read my post my usage of this syntax only includes "if" and > "elif" constructs and nothing "else" because usage outside of such a > "truth-seeking" construct is pointless. What's so special about "truth-seeking"? 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". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 11, 1:25 am, Steven D'Aprano wrote: (snip) > Incorrect. > >>> True == None > False > >>> False == None > False Of course i meant True/False but my fingers were thinking None at the time. And besides if i don't make a mistake here or there what ever would you do with your time? ;-) Seven += 1 > > #variable "var" will never be created! > That will cause no end of trouble. > if range(N) as var: > do_something_with_var() > if var: > print "Oops, this blows up if N <= 0" > Conditional assignments are a terrible idea. Yea it's called a NameError. Would it not also blow up in the current state of syntax usage? if var: print 'var' Traceback (most recent call last): File "", line 1, in if var: NameError: name 'var' is not defined Steven -= 1 > 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. > Would you suggest we can write this? > # instead of var = range(N) > p = range(N).index(5) as var # var might be range(N), or undefined. > var.append(42) No if you read my post my usage of this syntax only includes "if" and "elif" constructs and nothing "else" because usage outside of such a "truth-seeking" construct is pointless. print Steven -> 0 Hmm, just as i suspected. -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Tue, 10 Nov 2009 23:00:09 -0800, r wrote: > I think what has escaped everyone (including myself until my second > post) is the fact that what really needs to happen Why? > is for variable > *assignments* to return a boolean to any "statements" that evaluate the > assignment -- like in an "if" or "elif" construct. I don't even understand what that means. > The current "with" > statement cannot replace that action and was never meant for such > things. > > if range(0) as var: >#python will never execute even one line >#in this block because bool(var) == None No, that's impossible. bool() always returns True or False, not None. >#also since bool(var) equals None, the Incorrect. >>> True == None False >>> False == None False >#variable "var" will never be created! That will cause no end of trouble. if range(N) as var: do_something_with_var() if var: print "Oops, this blows up if N <= 0" Conditional assignments are a terrible idea. > elif range(10) as var: >#this block will execute and the variable "var" >#will be added to appropriate namespace containing >#a list of 10 ints > > var = 100 #var is still available in this namespace! > > > Very clean, very elegant solution to a messy problem that pops up in > python code quite often. You haven't actually explained what the messy problem is. var = range(N) if var: ... is not a messy problem. It's perfectly reasonable. If you need to do two things with a value, you assign it to a name first: var = range(N) p = var.index(5) var.append(42) x = func(10) y = x + 1 z = x*2 x = func(10) if x: y = x + 1 Why is the third example, with an if... test, so special that it needs special syntax to make it a two-liner? Would you suggest we can write this? # instead of var = range(N) p = range(N).index(5) as var # var might be range(N), or undefined. var.append(42) > It not only saves one distracting line of code > per usage but makes the code more readable. What distracting line of code? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 10, 2:49 pm, steve wrote: (..snip..) > However, the same 'effect' can be obtained with the 'with' statement: (..snip..) Hardly!,Here is an interactive session with your test case #--# >>> 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 'block' block >>> with something_that_returns_value(0) as value: print 'block' block >>> with something_that_returns_value(False) as value: print 'block' block >>> with something_that_returns_value([1,2,3]) as value: print 'block' block #--# The block obviously executes every time no matter what value is returned from something_that_returns_value(*). The with statement is meant to only cleanup an exception in a "nice-clean-way" not to evaluate a variable assignment as evidenced by this simple testing of your code. If anything executes in the block following the "if" (when the assignment value is None) it undermines the whole reason for using the new syntax in the first place! I think what has escaped everyone (including myself until my second post) is the fact that what really needs to happen is for variable *assignments* to return a boolean to any "statements" that evaluate the assignment -- like in an "if" or "elif" construct. The current "with" statement cannot replace that action and was never meant for such things. if range(0) as var: #python will never execute even one line #in this block because bool(var) == None #also since bool(var) equals None, the #variable "var" will never be created! elif range(10) as var: #this block will execute and the variable "var" #will be added to appropriate namespace containing #a list of 10 ints var = 100 #var is still available in this namespace! Very clean, very elegant solution to a messy problem that pops up in python code quite often. It not only saves one distracting line of code per usage but makes the code more readable. If there is an existing solution, Steve's is not it. -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
Carl Banks wrote: 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)) The effect of this proposal can already be accomplished with a 'pocket' class as has been posted before and again in a slightly different form in Steve's post. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Tue, 10 Nov 2009 20:13:21 -0800, Carl Banks wrote:
> On Nov 10, 7:12 pm, Steven D'Aprano
> 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))
This is where a helper function is good. You want a dispatcher:
COMMANDS = {
r'go\s+(north|south|east|west)': hero.move,
r'take\s+(\w+)': hero.pick_up,
r'drop\s+(\w+)': here.put_Down,
}
def dispatch(cmd):
for regex in COMMANDS:
m = re.match(regex, cmd)
if m:
COMMANDS[regex](m.group(1))
break
dispatch(cmd)
If you need the regexes to be tested in a specific order, change the dict
to an OrderedDict, or use a list of tuples and the obvious change to the
for loop.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 10, 9:12 pm, Steven D'Aprano 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 ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 10, 7:12 pm, Steven D'Aprano 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 10, 11:23 am, r 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 10, 2:08 pm, Robert Latest 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 " 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
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 -- http://mail.python.org/mailman/listinfo/python-list
New syntax for blocks
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? ;-) -- http://mail.python.org/mailman/listinfo/python-list
