Re: [A-A-P-develop] Referring to variables in Python fragments

[Bram M. <Br...@mo...>]

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 ///