Thread: [A-A-P-develop] Referring to variables in Python fragments
Brought to you by:
vimboss
From: John W. <jr...@po...> - 2004-03-05 16:47:29
|
I'm bothered by having to prefix all my recipe variables with "_no" in Python code; it's awkward to type, very strange looking for a beginner such as myself, and probably very easy to accidentally forget. I have an alternate suggestion: allow the "$variable" syntax in Python code. As far as I can tell, this would just mean replacing "$" with "_no." outside of string literals. Taking this a step futher, the "$" could work in string literals, too, so for example, "the value of X is $X" could become ("the value of X is " + _no.X). Another possible improvement would be to allow some of the extended sytnaxes like $?var and $*var in Python code. If I wrote a patch for this would it be accepted? jw |
From: Bram M. <Br...@mo...> - 2004-03-05 19:19:15
|
John Williams wrote: > I'm bothered by having to prefix all my recipe variables with "_no" in > Python code; it's awkward to type, very strange looking for a beginner > such as myself, and probably very easy to accidentally forget. Right. The only reason it's this way is that we could not make it work like we wanted to. The "exec" command does not accept a user dictionary. > I have an alternate suggestion: allow the "$variable" syntax in Python > code. As far as I can tell, this would just mean replacing "$" with > "_no." outside of string literals. That does sound like a nice simplification. Doesn't Python use $ outside of strings? I can't think of anything. One catch: It could be used in the next Python version. > Taking this a step futher, the "$" could work in string literals, too, so > for example, "the value of X is $X" could become ("the value of X is " + > _no.X). That does require escaping litaral "$" characters. I don't think we should go this way, since using "%s" isn't difficult, while escaping can get complicated. > Another possible improvement would be to allow some of the extended > sytnaxes like $?var and $*var in Python code. Support $?var would not be much of a problem. Using "_no.get('var')" should work. Things like $_parent.var can work as well (just to make it consistent, the $ isn't needed here). Implementing $*var is complicated. This requires parsing what comes before and after it. I wouldn't do that, try to keep it simple. > If I wrote a patch for this would it be accepted? The question is if this works perfectly well in all situations. We need to parse the Python code to discover where the "$" must be replaced with "_no.". How complicated is this? If you can write a patch that looks like it should work, with a test, and nobody objects to this use of "$" in Python code, I'll probably include it. PS: I had to manually approve your messages. Are you not subscribed to the maillist or using a different address? -- Snoring is prohibited unless all bedroom windows are closed and securely locked. [real standing law in Massachusetts, United States of America] /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |
From: John W. <jr...@po...> - 2004-03-05 20:47:20
|
Bram Moolenaar wrote: >>I have an alternate suggestion: allow the "$variable" syntax in Python >>code. As far as I can tell, this would just mean replacing "$" with >>"_no." outside of string literals. >> >> > >That does sound like a nice simplification. Doesn't Python use $ >outside of strings? I can't think of anything. One catch: It could be >used in the next Python version. > > It's not used at all so far. I doubt it will be used in the future either, for several reasons. First, the Python maintainers are extremely conservative with syntax changes. Second, I've been reading python-dev for a while and the only use I've ever seen for "$" is to do variable substitution inside strings--this usage wouldn't conflict with what I'm proposing. Third, because the proposed "$name" syntax is just a weaker version of the "%(name)s" syntax, it will not be added as long as the "%(name)s" syntax still exists--GvR hates redundancy! If "$name" is ever added and "%(name)s" removed, this will come at a time when backwards-incompatible changes are being made en masse, so reconciling two uses of "$" would probably be the least of your worries in that case. >>Taking this a step futher, the "$" could work in string literals, too, so >>for example, "the value of X is $X" could become ("the value of X is " + >>_no.X). >> >> > >That does require escaping litaral "$" characters. I don't think we >should go this way, since using "%s" isn't difficult, while escaping can >get complicated. > > Good point. >>Another possible improvement would be to allow some of the extended >>sytnaxes like $?var and $*var in Python code. >> >> > >Support $?var would not be much of a problem. Using "_no.get('var')" >should work. Things like $_parent.var can work as well (just to make it >consistent, the $ isn't needed here). > > I agree that $_parent.var should be made to work. >Implementing $*var is complicated. This requires parsing what comes >before and after it. I wouldn't do that, try to keep it simple. > > Yeah, $?var is the only I'd really care about, so I'll stick with that. >The question is if this works perfectly well in all situations. We need >to parse the Python code to discover where the "$" must be replaced with >"_no.". How complicated is this? > > > Unless I'm forgetting something really major, the only complication is with string literals. There are several different variations on string literals, but they're all pretty simple, and they're all spelled out in the manual. The biggest potential problem I can see is that when the parser sees $x.y, it can't distinguish a variable y in scope x from a member y in variable x. I think the correct interpretation is the first one, but then there's no way of calling methods on the value of the variable; it's not an issue for Python 1.x, but someone used to 2.x might expect something like $VAR.split() to work. I think a warning in the manual would be more than sufficient to get people to write split($VAR) or ($VAR).split() instead. >If you can write a patch that looks like it should work, with a test, >and nobody objects to this use of "$" in Python code, I'll probably >include it. > > I'll let you know when I've got something working. I don't think it will be a lot of work but it might take a while for me to get around to it, though. We'll see. >PS: I had to manually approve your messages. Are you not subscribed to >the maillist or using a different address? > > Sorry about that. I just joined the list. jw |
From: Bram M. <Br...@mo...> - 2004-03-06 11:08:51
|
John Williams wrote: > >>I have an alternate suggestion: allow the "$variable" syntax in Python > >>code. As far as I can tell, this would just mean replacing "$" with > >>"_no." outside of string literals. > > > >That does sound like a nice simplification. Doesn't Python use $ > >outside of strings? I can't think of anything. One catch: It could be > >used in the next Python version. > > > > > It's not used at all so far. I doubt it will be used in the future > either, for several reasons. First, the Python maintainers are extremely > conservative with syntax changes. It's just that '$' would be a very nice character to use for adding a completely new feature. Perhaps in Python 3.0? > Second, I've been reading python-dev for a while and the only use I've > ever seen for "$" is to do variable substitution inside strings--this > usage wouldn't conflict with what I'm proposing. Third, because the > proposed "$name" syntax is just a weaker version of the "%(name)s" > syntax, it will not be added as long as the "%(name)s" syntax still > exists--GvR hates redundancy! If "$name" is ever added and "%(name)s" > removed, this will come at a time when backwards-incompatible changes > are being made en masse, so reconciling two uses of "$" would probably > be the least of your worries in that case. That "%(name)s" is only used inside strings, thus if we don't support $var inside strings then we don't have this problem. > >The question is if this works perfectly well in all situations. We need > >to parse the Python code to discover where the "$" must be replaced with > >"_no.". How complicated is this? > > Unless I'm forgetting something really major, the only complication is > with string literals. There are several different variations on string > literals, but they're all pretty simple, and they're all spelled out in > the manual. I suppose so. You could try asking in a Python forum about $ being used outside of strings for something. Recognizing strings should not be too difficult. It does mean extra work, parsing the Python code. It may take some effort to do it fast. > The biggest potential problem I can see is that when the parser sees > $x.y, it can't distinguish a variable y in scope x from a member y in > variable x. I think the correct interpretation is the first one, but > then there's no way of calling methods on the value of the variable; > it's not an issue for Python 1.x, but someone used to 2.x might expect > something like $VAR.split() to work. I think a warning in the manual > would be more than sufficient to get people to write split($VAR) or > ($VAR).split() instead. I think we should do it the same as in Aap expressions as much as possible. We are introducing a bit of Aap syntax inside Python code here, thus I think the Aap syntax is most important. > >If you can write a patch that looks like it should work, with a test, > >and nobody objects to this use of "$" in Python code, I'll probably > >include it. > > I'll let you know when I've got something working. I don't think it will > be a lot of work but it might take a while for me to get around to it, > though. We'll see. I'm curious if this will really work. Would be a nice addition. Ah, you already made a patch. I'll look into it. -- Females are strictly forbidden to appear unshaven in public. [real standing law in New Mexico, United States of America] /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html /// |