和规范的实现有所不同，IronPython 使用 Unicode 而不是 ASCII 字节流来实现 str 类。而有些人说这是一个严重的分裂问题，其他人说这也没有什么大不了的。
这个问题的根源是 str 类是否必须使用 ASCII 来实现。虽然 ASCII 在支持非英语语言时存在严重的局限性，但可以通过使用代码页（Code Page）来解决。ASCII 字符串也能被用于表示二进制数据从而当作字节流。
在非规范实现中，如 IronPython 和 JPython，str 类使用平台特定的 String 类来实现。在这样的情况下，就意味着使用 Unicode 字符串。虽然这不会影响大部分应用程序，但还是有一些在使用 str 处理非英语代码页或作为字节数组的情况下不能正常工作。
Calvin Spealman 提出这是一个严重的问题：
IronPython 以这样的语法削短了这个语言本身的功能。问题是，一个对于 Python 和 IronPython 都是爱好者的人，就会遇到这样的情况。在 Python 的地盘上，我们将看到大量从 IronPython（也即通过 Silverlight）世界涌进来的对此感兴趣的人，但是所有这些新的开发人员都在创建不兼容的代码。在另一方面，IronPython 的拥护者还傻想着提升 Python 语言，但却完全忘记了大量现存的伟大函数库、多年建设起来的社区、和不仅仅只是一个流行词汇的协作等。
来自社区的回应并非全是否定的。Michael Foord 答复道：
为了说清楚这个问题，我来举个例子，在 Resolver（我们的一个很大的 IronPython 应用程序）中，用到了大量的 Python 标准函数库以及第三方的一些 Python 函数库——它工作的很好啊。
Manuel 也为这样的讨论辩护道：
首先，Python、CPython、IronPython、Jython、PyPy 都是在改变的个体。作为改变的个体，我们只能合理地对他们的发展轨迹提出意见。我没有看到任何迹象说 IronPython 会和 Python 社区产生分歧。已经有很多工作在致力于让 Python 函数库运行于 IronPython，如 FePy 社区和微软认可的社区都在做这样的事情。
Even Guido van Rossum，Python 的创造者，也加入到讨论中：
你应该认识到 Jython 已经很明确地存在 str==unicode 的问题，对吧？我从一开始就赞成对于两个版本的这种处理方式。所以我不知道你一心想扭曲的是什么？
暂时来看，Python 社区似乎愿意接受一些不兼容来换取多个平台的支持。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论