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
--
http://mail.python.org/mailman/listinfo/python-list
