py3k concerns. An example

[J. Cliff Dyer]

On Fri, 2008-04-18 at 08:58 -0700, Aaron Watters wrote:
> Why is the migration to py3k a concern?
> For example I have libraries which use string%dictionary
> substitution where the dictionary is actually an object
> which emulates a dictionary.  The __getitem__ for
> the object can be very expensive and is only called when
> needed by the string substitution.
> 
> In py3k string%dictionary is going away.  Why?
> I have no idea.
> 
> The replacement is a string.format(...) method
> which supports dictionary calling.
>     string.format(**dictionary)
> But dictionary
> calling doesn't support dictionary emulation.
> So in the example below the substitution works
> but the call fails.
> 
> === code
> 
> class fdict(dict):
>     def __getitem__(self, item):
>         return "got("+item+")"
> 
> def fn(**d):
>     print d["boogie"]
> 
> if __name__=="__main__":
>     fd = fdict()
>     print "attempting string substitution with fake dictionary"
>     print
>     print "hello there %(boogie)s" % fd # <-- works
>     print
>     print "now attempting function call with fake dictionary"
>     print
>     fn(**fd) # <-- fails
> 
> === output
> 
> % python2.6 dtest.py
> attempting string substitution with fake dictionary
> 
> hello there got(boogie)
> 
> now attempting function call with fake dictionary
> 
> Traceback (most recent call last):
>   File "dtest.py", line 17, in <module>
>     fn(**fd)
>   File "dtest.py", line 7, in fn
>     print d["boogie"]
> KeyError: 'boogie'
> 
> ==== end of output
> 
> Consequently there is no simple way to translate
> my code, I think.  I suspect you will find this kind of subtle
> issue in many places.  Or worse, you won't find it
> until after your program has been installed
> in production.
> 
> It's a damn shame because
> if string%dict was just left in it wouldn't be an issue.
> 
> Also, if making f(**d) support dict emulation
> has any negative  performance implications
> then I don't want it please.
> 
> sigh.  -- Aaron Watters
> 
> ===
> http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=crack+open
> 

I was with you on this issue right up until that last paragraph.  You
want it, but only if its free.  That's ridiculous.  Every thing a
computer does requires processor cycles. 

Do you really mean to tell me that string interpolation has been a major
bottleneck for you?  Now I think you're just whining because you like to
hear yourself whine.  Try coming up with a real standard for evaluation.
How much of a performance hit will actually cause you trouble?  1% extra
on string interpolation?  10%? 50%? 200%?

You do provide a link to a website called xfeedme.com.  And I just fed
you.  IHBT.  HAND. :-/

-- 
Oook,
J. Cliff Dyer
Carolina Digital Library and Archives
UNC Chapel Hill