<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.
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?
> 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 !-)
> 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.
> 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.
<bdesth.quelquech...@free.quelquepart.fr> 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, 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!
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!
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.
> 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!
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.
> On Nov 12, 2:37 pm, Bruno Desthuilliers > <bdesth.quelquech...@free.quelquepart.fr> 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 <g>
> 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.
> > 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.
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.)
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.
On Nov 17, 9:28 am, Jonathan Saxton <jsax...@appsecinc.com> 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?
On Tue, 17 Nov 2009 17:31:18 +0000, 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".
On Nov 17, 7:28 am, Jonathan Saxton <jsax...@appsecinc.com> 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.
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 =.
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!
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.
<ste...@REMOVE.THIS.cybersource.com.au> 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 <CNTRL> and press <KEYPAD-1> twice, then release <CNTRL>. ;-)
PS: But please lets not start using Unicode chars in programming, you guy's already know how much i *hate* Unicode.
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.
Gregory Ewing <greg.ew...@canterbury.ac.nz> 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 <URL: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
On Nov 19, 12:20 am, Gregory Ewing <greg.ew...@canterbury.ac.nz> 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.
Carl Banks <pavlovevide...@gmail.com> writes: > On Nov 19, 12:20 am, Gregory Ewing <greg.ew...@canterbury.ac.nz> > 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
