Plan for python upgrade

hubert_star

向superjet道歉

稳定不稳定，其实重要的是看版本和patch

arch的很多东西要你自己去配，比如inkscape，有人说archlinux的有问题，实际上也就是一个版本号升级的问题，升级后就解决了。有个版本确实在gtk处理上有问题，关键看是不是有发行版刚好处于这个版本的阶段。

再比如xorg和kernel，你看在testing里面待了多长时间？

至于社区包，本身就不是arch来负责的，而是靠aur投票，如果觉得什么地方不稳定，去找找别的发行版的patch打上就可以了。

而更应该看到的是aur/社区的优势，在debian里面某个东西没有，你就要自己做deb包，别人做了，也没办法保证重要更新，而aur上一个flag out date你就会知道了。

滚动发行会有它的问题，但是也有优势，我认为优势大于劣势。这么一个问题，如果你在别的发行版里面停留在某个低版本，好吧，那你升级如何处理，现在有几个发行版能够做到长达数年的低版本维护？如果你一直升级的话，那么在升级的那个过程里面，新的版本中所有东西都很稳定的吗？如果配置文件结构发生大变化，很多东西堆在一起让你重新来配置，你愿意吗？

cyf3732

恩，出了问题总会有解决的办法，自是水到渠成的事情

zhong

有什么好讨论呢.共存是肯定的...常有的事. 不要大惊小怪..
不过arch这样更新快的发行版维护可能会麻烦点

poet

Post by 难免有错;1890192

Plan 1:
    python = python3.0
    python2 = python2.6

Plan 2:
    python = python2.6
    python3 = python3.0
   
I am going to go for Plan 1 unless someone convinces me the Plan 2 is a
better plan _long_ term.  I prefer short term pain for long term benefit
rather than long term pain for short term benefit.

既然是转贴，麻烦给个出处，以免读者连该反馈给谁都不知道。

个人不太赞同Allen的做法。如果python坚持在每个版本都进行如此激进的改变的话，永远把python执行文件冠以版本号反倒是个明智的方法，如果从今天开始就把所有python3程序内部都写成python3，将来升级到python4将会异常平滑。

hubert_star

Post by poet;1890695
既然是转贴，麻烦给个出处，以免读者连该反馈给谁都不知道。

个人不太赞同Allen的做法。如果python坚持在每个版本都进行如此激进的改变的话，永远把python执行文件冠以版本号反倒是个明智的方法，如果从今天开始就把所有python3程序内部都写成python3，将来升级到python4将会异常平滑。

转载自archlinux新闻组

不是很清楚了吗？

他也是把后续的回复给贴出来的。

难免有错

Post by hubert_star;1890793
转载自archlinux新闻组

不是很清楚了吗？

他也是把后续的回复给贴出来的。

邮件里面的讨论。

superjet

http://faassen.n--tree.net/blog/view/weblog/2007/6/22/0

个人因系统中有装有大量python相关的东东，在很长一段时间内，为了免除不必要的烦恼，我会把python的版本钉到2.5，也不会去装承前启后的2.6，虽然可能会去做个python3的包

1. 
   
2. Python 2.6
   
3. 
   
4. There will be a "companion" release of Python 2.6, scheduled to be released a few months before 3.0, with an alpha release about 4 months before then (i.e., well after the first 3.0 alpha). The next two sections explain its role. If you're not interested in living on the bleeding edge, 2.6 is going to be next version of Python you'll be using, and it will not be very different from 2.5.
   
5. Compatibility and Transition
   
6. Compatibility
   
7. 
   
8. Python 3.0 will break backwards compatibility. Totally. We're not even aiming for a specific common subset. (Of course there will be a common subset, probably quite large, but we're not aiming to make it convenient or even possible to write significant programs in this subset. It is merely the set of features that happen to be unchanged from 2.6 to 3.0.)
   
9. 
   
10. Python 2.6, on the other hand, will maintain full backwards compatibility with Python 2.5 (and previous versions to the extent possible), but it will also support forward compatibility, in the following ways:
    
11. 
    
12.     * Python 2.6 will support a "Py3k warnings mode" which will warn dynamically (i.e. at runtime) about features that will stop working in Python 3.0, e.g. assuming that range() returns a list.
    
13.     * Python 2.6 will contain backported versions of many Py3k features, either enabled through __future__ statements or simply by allowing old and new syntax to be used side-by-side (if the new syntax would be a syntax error in 2.5).
    
14.     * Complementary to the forward compatibility features in 2.6, there will be a separate source code conversion tool. This tool can do a context-free source-to-source translation. As a (very simply) example, it can translate apply(f, args) into f(*args). However, the tool cannot do data flow analysis or type inferencing, so it simply assumes that apply in this example refers to the old built-in function.
    

复制代码