[ANN] istring 1.0.1 released; announce list created

[Steven D. Arnold]

Hi Fernando,

On Wednesday, March 06, 2002, at 5:05:03 AM, Fernando Pérez wrote:

FP> Very nice, and thanks for the contribution. I've long been a fan
FP> of this idea. But could you please clarify if your module is in
FP> anyway different to the 'old' interpolation module that's been the
FP> reference implementation to PEP 215? You can find it at
FP> http://web.lfw.org/python/ towards the middle of the page. Also
FP> see pep215 at http://python.sourceforge.net/peps/pep-0215.html

I apologize for not responding last time; I did see your previous
post but I'm usually very busy and I only have time to read
python-list and respond to posts occasionally (though I always enjoy
it when I do).  FYI, if you do really desire a response from me on any
subject, it's best to send an email to me directly or send me an
instant message.

I'd say the biggest difference is that istring is a type of string
(descended from the str class).  This gives it a lot of out-of-the-box
features and compatibility that itpl doesn't have.  On the other hand,
the parsing in itpl is more elegant.  When I get some time, I'll see
what I can learn from his code. :-)

In brief response to some other points raised in this thread:

1. What's wrong with the %(foo)s approach?  Nothing, if you have a
dictionary ready to go with the key/value pairs you need.  istring
fully supports the use of such constructs when you find it appropriate
to use them.  I'd say if you have a string that needs a lot of keys
from a particular dictionary and you have just such a dictionary,
you may want to use the %(foo)s format -- although personally I still
find it less pleasing to the eye and less immediately readable than
the $ notation.  I suppose there's no accounting for taste. :-)

2. Some have asked why one would not use vars() and the mapping format
all the time, since vars returns a dictionary of the local namespace?
The problem with vars() is that (at least as far as I know) it doesn't
support dictionaries, lists, object attributes and function calls.
Furthermore, if you use a mapping, it has to support all substitutions
in the string -- you can't intermingle with other variables.  With
istring, you can use $ notation for some variables and use vars() or
another mapping for other substitutions.

3. DB API substitution -- it's true, you're better off using the DB
API substitution rather than sending a literal string.  I'd like to
update istring to support this -- that is, you still see the same kind
of string from the user perspective, but the actual query is submitted
to the DB API behind the scenes in the correct way.  I feel sure this
is possible, it just hasn't been done yet.  IMO, this is by far the
most serious reason not to use istring, and it only applies to SQL.
So, I hope to remove it as an objection soon.

4. Standard library -- If anyone wishes to take the steps to include
it in the standard library, including any PEPs that may be needed in
addition to 215, you have my blessing and I'll provide support.  The
current license is LGPL-like, with the intent of ensuring changes are
open-source without infecting projects that use it.  I will make
istring available under the Python license if that is the only
obstacle keeping it from inclusion in the standard library.  In the
meantime, it's practically like, say, an r or u string, except with
parentheses:

>>> from neo.istring import istring as i
>>> l = [1,2,3]
>>> i('first value is $l.0')
'first value is 1'


Bottom line, I hope you like it and benefit from it.  If you don't
like it, then I wish you the best too, using whatever tools you do
like.  It's not a religion to me, just Python code. :-)  Cheers!

-------------------------------------------------------------- 
Steven D. Arnold                                    Neosynapse
stevena at neosynapse.net                        Managing Partner
AIM: abraxan                       MSN: neosynapse at hotmail.com