Re: Referring to variables in Python fragments

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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click