惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

J
Java Code Geeks
博客园 - 聂微东
人人都是产品经理
人人都是产品经理
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
博客园_首页
量子位
阮一峰的网络日志
阮一峰的网络日志
酷 壳 – CoolShell
酷 壳 – CoolShell
H
Hackread – Cybersecurity News, Data Breaches, AI and More
云风的 BLOG
云风的 BLOG
D
DataBreaches.Net
B
Blog
L
LangChain Blog
Apple Machine Learning Research
Apple Machine Learning Research
Vercel News
Vercel News
博客园 - 三生石上(FineUI控件)
爱范儿
爱范儿
Microsoft Azure Blog
Microsoft Azure Blog
IT之家
IT之家
aimingoo的专栏
aimingoo的专栏
B
Blog RSS Feed
H
Help Net Security
The Cloudflare Blog
U
Unit 42

Secret Weblog

Becoming More Xee: A Modern XPath and XSLT Engine in Rust Looking for new challenges! Repeat Yourself, A Bit The Curious Case of Quentell The Humble For Loop in Rust The Humble For Loop in JavaScript Don Question Best Practices I Was a 1980s Teenage Programmer Part 5: Achieving Assembly I Was a 1980s Teenage Programmer Part 4: The Call of Assembly The Tooling Shift I Was a 1980s Teenage Programmer Part 3: MSX-2 JavaScript: when you need two ways to do it! Empowering Programming Languages Bloat and Retrofuturism Refreshing my Blog Again Random Rust Impressions Apilar: An Alife System I Was a 1980s Teenage Programmer Part 2: Olivetti M24 I Was a 1980s Teenage Programmer: the Alphatronic SolidJS fits my brain Is premature optimization the root of all evil? Framework Patterns: JavaScript edition Roll Your Own Frameworks Framework Patterns Secret Weblog Highlights Refactoring to Multiple Exit Points mstform: a form library for mobx-state-tree Seven Years: A Very Personal History of the Web
Please don
Martijn Faassen · 2008-03-05 · via Secret Weblog

Update: Guido appears to share my opinion on this.

I've heard murmurs from a bunch of projects over time concerning their transition plans to Python 3.0. These transition plans are naturally vague at this stage. There's one theme I've heard a few times in these murmurs that worries me enough to speak out on it.

People sometimes reason that since Python 3 is going to break people's code anyway, now is a good time to make backwards compatible changes in their libraries too. The reasoning is understandable: people are facing a big change anyway with Python 3, so why break backwards compatibility for them once then, and then another time for your library? Better do it at the same time and make people suffer only once.

There are other reasons that drive projects to break backwards compatibility at this point. As far as I understand, the Python C API will change with Python 3, so that means projects that bind to C libraries need to be adjusted anyway. This might tempt people to make larger scale changes.

I just heard that the current WSGI spec isn't entirely compatible with Python 3. If that is so, and a new version of the spec is needed, then that might give some frameworks that use WSGI an opportunity to clean up some things and break backwards compatibility.

While very understandable, the negative consequence of all this is that the Python 2 to 3 conversion script strategy stops working for code that depends on these libraries and frameworks. This official transition strategy aims to make the transition between Python 2 and Python 3 easier by offering a script that convert your Python 2 code to Python 3 code automatically.

If lots of important libraries and frameworks however also break backwards compatibility in their Python 3 versions, this means that any converted code that depends on them has no chance of working. Instead the developer would need to track all the API changes and make adjustments there too before the code would work again: a much harder task.

So my advice to library and framework maintainers would be: please do not use this opportunity to break backwards compatibility in your library or framework too. I'd like to ask you to resist this temptation. The language changes already make this a major transition for everybody, and you'd make it that much harder by taking away people's ability to automatically convert their Python codebases.