py3k关注。一个例子 [英] py3k concerns. An example

查看:66
本文介绍了py3k关注。一个例子的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为什么迁移到py3k是一个问题?

例如我有使用字符串%字典的库

替换字典实际上是一个对象

模拟字典。 __getitem__对于

对象可能非常昂贵,并且仅在字符串替换需要

时调用。


在py3k中字符串%字典即将消失。为什么?

我不知道。


替换是string.format(...)方法

支持字典调用。

string.format(**字典)

但字典

调用不支持字典模拟。

所以在下面的示例中,替换工作

但是呼叫失败。


===代码


class fdict(dict):

def __getitem __(self,item):

return" got(" + item +")"


def fn(** d):

print d [" boogie"]


if __name __ == " __ main __":

fd = fdict()

打印尝试使用假字典替换字符串

打印

print" hello there%(boogie)s" %fd#< - 作品

打印

打印现在正在尝试用假字典打电话

打印

fn(** fd)#< - 失败


===输出


%python2.6 dtest.py

尝试用假字典替换字符串


你好(boogie)


现在尝试使用假的函数调用字典


Traceback(最近一次调用最后一次):

文件" dtest.py",第17行,< module>

fn(** fd)

文件dtest.py,第7行,fn

print d [" boogie"]

KeyError:''boogie''


====输出结束


因此没有简单的翻译方式

我的代码,我想。我怀疑你会在很多地方发现这种微妙的问题。或者更糟糕的是,在你的程序安装完毕之后,你才会发现



生产。


它' 真是太可惜了,因为

如果字符串%dict刚刚存在就不会成为问题。


另外,如果制作f(** d)支持dict仿真

有任何负面的性能影响

然后我不想要它。


叹息。 - Aaron Watters


===
http://www.xfeedme.com/nucular/pydis...EXT=crack+open

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/pydis...EXT=crack+open

推荐答案

On Fri,2008-04-18 at 08:58 -0700,Aaron Watters写道:
On Fri, 2008-04-18 at 08:58 -0700, Aaron Watters wrote:

为什么迁移到py3k关注?

例如我有使用字符串%字典的库

替换字典实际上是一个对象

模拟字典。 __getitem__对于

对象可能非常昂贵,并且仅在字符串替换需要

时调用。


在py3k中字符串%字典即将消失。为什么?

我不知道。


替换是string.format(...)方法

支持字典调用。

string.format(**字典)

但字典

调用不支持字典模拟。

所以在下面的示例中,替换工作

但是呼叫失败。


===代码


class fdict(dict):

def __getitem __(self,item):

return" got(" + item +")"


def fn(** d):

print d [" boogie"]


if __name __ == " __ main __":

fd = fdict()

打印尝试使用假字典替换字符串

打印

print" hello there%(boogie)s" %fd#< - 作品

打印

打印现在正在尝试用假字典打电话

打印

fn(** fd)#< - 失败


===输出


%python2.6 dtest.py

尝试用假字典替换字符串


你好(boogie)


现在尝试使用假的函数调用字典


Traceback(最近一次调用最后一次):

文件" dtest.py",第17行,< module>

fn(** fd)

文件dtest.py,第7行,fn

print d [" boogie"]

KeyError:''boogie''


====输出结束


因此没有简单的翻译方式

我的代码,我想。我怀疑你会在很多地方发现这种微妙的问题。或者更糟糕的是,在你的程序安装完毕之后,你才会发现



生产。


它' 真是太可惜了,因为

如果字符串%dict刚刚存在就不会成为问题。


另外,如果制作f(** d)支持dict仿真

有任何负面的性能影响

然后我不想要它。


叹息。 - Aaron Watters


===
http://www.xfeedme.com/nucular/pydis...EXT=crack+open



我在这个问题上和你在一起直到最后一段。你想要它,但只有它是免费的。这是荒谬的。一台

计算机确实需要处理器周期。


你真的想告诉我字符串插值是一个主要的

瓶颈给你?现在我想你只是抱怨因为你喜欢

听到自己的抱怨。尝试提出一个真正的评估标准。

多少性能影响实际上会给你带来麻烦?字符串插值1%额外

? 10%? 50%? 200%?


您确实提供了一个名为xfeedme.com的网站链接。而我刚刚给你带来了
。 IHBT。手。 : - /


-

Oook,

J. Cliff Dyer

卡罗来纳州数字图书馆和档案馆

UNC教堂山

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



试着想出一个真实的评估标准。

多少性能影响实际上会给您带来麻烦?字符串插值1%额外

? 10%? 50%? 200%?
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%?



你误解了我的评论。我不希望函数调用支持

字典模拟如果有速度惩罚,因为这是

这样的特殊情况和函数调用是如此重要。 />
我真的不知道,但我认为修复上面的问题

string.format(...)可能涉及更改每个python堆栈帧的表示

...在这种情况下不值得,如果有

是任何惩罚(afaik没有)。


另一种方法是为string.format提供备用接口

所以

你可以传入一个可以模拟字典的对象,

就像string.formatDict(D) - 或者你甚至可以采用一个快捷方式

符号如字符串%D - 嘿,有个主意!

- Aaron Watters


===
http://www.xfeedme.com /nucular/pydis...gnore+warnings


4月18日20:07,Aaron Watters< aaron.watt ... @ gmail .comwrote:
On 18 Apr., 20:07, Aaron Watters <aaron.watt...@gmail.comwrote:

我真的不知道,但我认为修复上面的问题

string.format(...)可能涉及更改每个python堆栈帧的表示

...在这种情况下不值得,如果有

是任何惩罚(afaik没有)。
I don''t really know, but I think "fixing" the above issue for
string.format(...) might involve changing the representation of
every python stack frame... not worth it in this case if there
is any penalty (afaik there isn''t).



在Python 2.6中,format函数只是在

字典对象上调用PyDict_GetItem,如果失败则引发KeyError。如果快速查找没有结果,则dict仿真

将需要再查找一次。如果在PyDict_GetItem中实现此查找将是一个特殊情况,那么在一般情况下
将是一个速度惩罚,但处理

格式的特殊情况实施可能看起来不那么糟糕。

In Python 2.6 the format function simply calls PyDict_GetItem on the
dictionary object and raises a KeyError if it fails. A dict emulation
would require one more lookup if the fast lookup has no result. It
would be a speed penalty in the general case if this lookup would be
implemented in PyDict_GetItem but handling a special case in the
format implementation might not look that bad.


这篇关于py3k关注。一个例子的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆