兼容 | 易学教程

Supporting Python 3——迁移python2的c扩展到python3

阅读更多关于 Supporting Python 3——迁移python2的c扩展到python3

迁移C扩展 Python 3有很多在C语言API上的变化，包括在API中定义类和初妈化的模块。这意味着每一个C扩展为了能在Python 3 下运行需要进行修改。一些变化很简单而另一些不简单，但是因为2to3只处理Python代码，你不得不对这些变化进化手动处理。这也意味着不你能通过2to3的转换来同时实现Python 2和Python 3的支持。幸运的是，C预处理程序可以很容易地实现使用相同的代码支持Python 2和Python 3.这是一个使在C中支持不同版本API的标准方式，这也将成为C程序员的标准技能。因此没有丑陋的黑客参与，只是少了些漂亮的 #if 和# ifndef 语句。在你开始前有一些事情你可以在真正开始移植前先做。首先是移除一些你根本不需要的老别名的用法。例如RO宏已经被删除了。它只是一个简写的READONLY，因些如果你在代码中用了RO，你可以使用READONLY来替代它。其他常见的重定义是 statichere 和 staticforward。他们是为了兼容特定编译器的变通方法。对于表现良好的编译器他们只是 static 的重定义，因此在CPython支持的所有平台都有表现良好的编译器的当今Python 3已经不需要他们了。如果你在代码中使用了他们，你可以用 static 来代替。其他在移植你可以做的变化是摆脱 PyClassObject

Supporting Python 3(支持python3)——语言区别和暂时解决方法

阅读更多关于 Supporting Python 3(支持python3)——语言区别和暂时解决方法

语言区别和暂时解决方法这个附录包含一个Python 2和Python 3的不同之处列表以及能不用2to3转换同时在Python 2和Python 3下运行的示例代码。这个列表是不完整的。在这里列出的只有不包括bug修复的策划变化，即使如此也可能有意外的遗漏。 apply() 2to3 fixer ☑ six support ☐ Python 2的内置apply()在Python 3已经被移除。它用于调用一个函数，但由于你可以直接调用函数它并没有什么用并从Python 2.3起被废弃了。没有替代方案。 buffer() 2to3 fixer ☑ six support ☐ Python 2的buffer()内置函数被Python 3的类memoryview取代了。他们是不完全兼容，所以2to3除非你显示指定buffer固定器否则不会修改这个。这个代码能不用2to3转换在Python 2和Python 3同时运行： >>> import sys >>> if sys.version_info > (3,): ... buffer = memoryview >>> b = buffer('yay!'.encode()) >>> len(b) 4 callable() 2to3 fixer ☑ six support ☑ Python 2的内置callable()在Python 3

Supporting Python 3——不使用2to3转换支持Python 2和Python 3

阅读更多关于 Supporting Python 3——不使用2to3转换支持Python 2和Python 3

不使用2to3转换支持Python 2和Python 3 虽然Python 3的官方文档努阴人们写同时支持Python 2和Python 3的代码，但是在一此情况这是合适的。尤其是你不能放弃支持Python 2.5及更早的版本时，因为Python 2.6引进了相当多的向前兼容。使相同的代码在更新的版本同样运行是有可能的，不过你开始进入Python 3文档中提到的“扭曲”的代码风格。我会使用一些技巧来做这些并且我在本章末尾提到的six模块会提供很多帮助。它甚至在一些比较大的项目中使用，但是我通常不推荐在在型项目中使用。对于小项目或者大项目的一部分，例如引导脚本，不使用2to3来支持老的Python版本是最好的解决的方式。 Python 2.7对Python 3的兼容有一些小改进，但如果你想要在Python 2和Python 3下执行相同的代码，似乎你必须要在将来的一段时间内支持Python 2.6。很多你需要的修改将会被2to3处理，所以开始转换你的代码你事实上需要首先在你的代码上运行2to3并且确保你的代码可以在Python 3下运行。它通常很容易，或者至少在Python 3代码中引入Python 2兼容比在Python 2中引入Python 3代码更不单调。一旦你有一个在Python 3下的项目，偿试在Python 2.6下运行他们。在这一步你可以执行出语法错误

AES加密CBC模式兼容互通四种编程语言平台【PHP、Javascript、Java、C#】

阅读更多关于 AES加密CBC模式兼容互通四种编程语言平台【PHP、Javascript、Java、C#】

由于本人小菜，开始对AES加密并不了解，在网络上花了比较多时间查阅资料整理；先简单从百度找来介绍：密码学中的高级加密标准（Advanced Encryption Standard，AES），又称高级加密标准Rijndael加密法，是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES，已经被多方分析且广为全世界所使用。经过五年的甄选流程，高级加密标准由美国国家标准与技术研究院（NIST）于2001年11月26日发布于FIPS PUB197，并在2002年5月26日成为有效的标准。2006年，高级加密标准已然成为对称密钥加密中最流行的算法之一。该算法为比利时密码学家Joan Daemen和VincentRijmen所设计，结合两位作者的名字，以Rijndael之命名之，投稿高级加密标准的甄选流程。（Rijdael的发音近于 "Rhinedoll"。） AES加密模式和填充方式（其实还有还几种填充方式没写上，开始时候也在这里绕了一下）算法/模式/填充 16字节加密后数据长度不满16字节加密后长度 AES/CBC/NoPadding 16 不支持 AES/CBC/PKCS5Padding 32 16 AES/CBC/ISO10126Padding 32 16 AES/CFB/NoPadding 16 原始数据长度 AES/CFB/PKCS5Padding

五种方法解决Magento中jQuery和Prototype兼容性

阅读更多关于五种方法解决Magento中jQuery和Prototype兼容性

Magento 的发布版本里的JS大多是用Prototype写的，如果需要引入jQuery的话，可能有些变量会冲突，所以需要做些处理来处理jQuery和Prototype的兼容性。第一种情况：先加载Prototype，再加载jQuery 方法一： jQuery 库和它的所有插件都是在jQuery名字空间内的，包括全局变量也是保存在jQuery 名字空间内的。使用jQuery.noConflict();主要作用是在任何时候，只要在jQuery加载后就可以调用，将$符号的使用权返回给其它的js库，jQuery在创建它自己的名字空间时就将其它库的$保存在自己的一个变量当中。 <html> <head> <script src="prototype.js"></script> <script src="jquery.js"></script> <script type="text/javascript" > //各个js库之间的主要冲突在于$的冲突，这个方法是用来处理这个问题的 jQuery.noConflict(); //原本使用jQuery代码部分的$ 用jQuery替代 jQuery(document).ready(function (){ jQuery("div").hide(); }); // Use Prototype with $(...), etc. $('proto'

eclipse和android源码编译应用效果有差异

阅读更多关于 eclipse和android源码编译应用效果有差异

一般来说，eclipse只是IDE开发工具，它虽然能编译apk，但是大多数开发情况下，都会要求必须在源码里编译通过，达到工程化，而不是单单的demo。问题：这次悲催而又诡异的遇到了这么个问题：作者也是在eclipse中建的工程，并调试。因为要放到源码里去编译，所以加了个在根目录里加Android.mk放到源码编译，也编过了。运行时，eclipse的效果如图： android 源码编译的效果为：神奇的事情竟然出现了，焦点框的阴影居然跑到文字上去了！！！我勒个去。这里图片（更多）、文字（游戏），焦点框，都是用canvas画出来的。分析： 1.查看代码，但是很明显代码里画焦点框和阴影都是同时画的，坐标也是一样的，文字那里没有加阴影的代码 void onDrawFocus(Canvas canvas, int left, int top) { //阴影 paint.reset(); paint.setShadowLayer(20f, 10f, 10f, Color.BLACK); RectF focusRectF = new RectF(x - space, y - space, r + space, b + space); canvas.save(); canvas.drawRoundRect(focusRectF, 10f, 10f, paint); canvas

五种方法解决jQuery和Prototype兼容性

阅读更多关于五种方法解决jQuery和Prototype兼容性

第一种情况：先加载 Prototype ，再加载 jQuery 方法一： jQuery 库和它的所有插件都是在 jQuery 名字空间内的，包括全局变量也是保存在jQuery 名字空间内的。使用jQuery.noConflict();主要作用是在任何时候，只要在jQuery加载后就可以调用，将$符号的使用权返回给其它的js库，jQuery在创建它自己的名字空间时就将其它库的$保存在自己的一个变量当中。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 <html> <head> <scriptsrc="prototype.js"></script> <scriptsrc="jquery.js"></script> <scripttype="text/javascript"> //各个js库之间的主要冲突在于$的冲突，这个方法是用来处理这个问题的 jQuery.noConflict(); //原本使用jQuery代码部分的$ 用jQuery替代 jQuery(document).ready(function (){ jQuery("div").hide(); }); // Use Prototype with $(...), etc. $('proto').hide(); </script> </head> <body></body>

CSS hack for IE6/IE7/IE8/Firefox/Chrome/Safari

阅读更多关于 CSS hack for IE6/IE7/IE8/Firefox/Chrome/Safari

每次调css最令人头痛的就是浏览器校正问题，因为每个浏览器对css的解释都不太一样，firefox本身算是比较照规矩来，处理上比较简单，但是遇到微软的ie系列头就大了，虽然都是ie，但是ie6、ie7、ie8各版本对css的解释又不一样，就算你本身已经在ie6调整好，但是在ie7看起来又是不一样，这时我们就得来对各个浏览器设定不同的数值来解决版面移位的问题。网路上有非常多关于css hack的教学文章，当然处理方法也有很多种，接下来要跟大家说明的是属于比较简单的方法，但是以下的校正确无法通过w3c检测，虽然无法通过检测，但是针对各个浏览器校正确是有效的！目前浏览器大宗还是属于ie6的天下，这原因主要是因为xp本身内建ie6，而且很多使用者很喜欢重灌xp，因此ie6仍占走了大半的浏览器天下，不过随着windows7的出现，倒是有非常大的机会解决过气的ie6，因为windows7本身是内建ie8，微软的ie8对css的解释已经越来越标准，当然标准程度仍是不及firefox。另外，如果要处理ie各版本浏览器的相容性问题，那一定要有各版本的ie浏览器可以浏览，但是微软作业系统内并没有让多版本的ie共存，为了让自己电脑内存在多种版本的ie浏览器，那就赶快下载ietester来使用吧！另外，也别忘记下载firefox来修正网页css. 区别ie和firefox 【辨识符号】：

css hack 解决浏览器兼容总结

阅读更多关于 css hack 解决浏览器兼容总结

最近切的页面设计很精致，有那么些难以控制兼容性的问题，没办法，只有用hack解决了，，虽然不赞同hack，但是既然是页面布局，总觉得不要搭上javascript来解决，下面也总结下CSS hack浏览器兼容。区别IE和非IE浏览器 background:blue; /*非IE 背景藍色*/ background:red \9; /*IE6、IE7、IE8背景紅色*/ 区别IE6,IE7,IE8,FF background:blue; /*Firefox 背景变蓝色*/ background:red \9; /*IE8 背景变红色*/ *background:black; /*IE7 背景变黑色*/ _background:orange; /*IE6 背景变橘色*/ 浏览器都能识别「\9」，而IE6和IE7可识别「*」，另外IE6可认识「_」区别IE6、IE7、Firefox 【区别符号】：「*」、「!important」 background:blue; /*Firefox 背景变蓝色*/ *background:green !important; /*IE7 背景变绿色*/ *background:orange; /*IE6 背景变橘色*/ } IE7可以辨识「*」和「!important」，但是IE6只可以辨识「*」，却无法辨识「!important」

【原创】centos自带网卡驱动不兼容硬件，造成hadoop的datanode节点频繁宕机的解...

阅读更多关于【原创】centos自带网卡驱动不兼容硬件，造成hadoop的datanode节点频繁宕机的解...

操作系统：CentOS Linux 6.0（Final）内核： Linux 2.6.32 硬件： HP 3300 Series MT ，内存增加到6G。 Hadoop集群：一台NameNode 同时作为client node、三台DataNode。数据备份为3分，即dif.replication = 3 。笔者在测试hadoop性能过程中，在向hadoop集群中put大量数据（50G）的时候，集群中的datanode节点频繁宕机。并且在centos日志系统中没有关于datanode宕机的错误报告。因为hadoop的测试数据是存放在namenode 中的，所以namenode同时也是client node。经过笔者观察发现，宕机的只是datanode，而client node从来不宕机。在hadoop put数据的过程中，通过ganglia观察到client node的系统负载率要要远远高于datanode 。繁忙的client node不宕机，而相对系统负载率低的datanode却频繁死机，说明了datanode宕机与cpu、内存无关。笔者将目光转向了磁盘I/O和网络I/O。首先，考虑是否因为磁盘I/O频繁操作引起的datanode系统宕机。因为测试数据存放在client node上，所以要在clent node上进行大量的磁盘读取数据操作。client

订阅兼容