Why would I ask that question?
Python 3 has been available for some time now, yet uptake is slow. There aren't a whole lot of packages in the package index shop for Python 3. It seems there just isn't a demand for Python 3 libraries.
Google have released a new language, even though they hired the BDFL, and started the Unladen Swallow project (which coincidentally, does not target Python 3). Why?
Finally, despite my best efforts to move a project across to Python 3 from Python 2.6, I've been sabotaged by undocumented differences in the behaviour of the select module. I've decided to move back to 2.6 for the time being, rather than change code which has worked for a long time. Who knows what else might come out of the woodwork to raise strange exceptions in the middle of the night?
I think Python 3 suffers from attempting to be compatible with Python 2. It should have been a clean break with major repairs and reconstruction, as the original Python 3000 was intended to be. Hang the expense, let's make this language _right_, and Python 2 be damned.
Is it too late to remedy this situation?
Subscribe to:
Post Comments (Atom)
Popular Posts
-
These are the robots I've been working on for the last 12 months. They each weigh about 11 tonnes and have a 17 meter reach. The control... -
This hard-to-see screenshot is a Generic Node Graph Editing framework I'm building. I'm hoping it can be used for any kind of node... -
So, you've created a car prefab using WheelCollider components, and now you can apply a motorTorque to make the whole thing move along. ... -
After my last post, I decided to benchmark the scaling properties of Stackless, Kamaelia, Fibra using the same hackysack algorithm. Left axi... -
It is about 8 degrees C this morning. So cold, especially when last week we had high twenties. To help solve the problem, a friend suggeste...
-
Why would I ask that question? Python 3 has been available for some time now, yet uptake is slow. There aren't a whole lot of packages i...
-
MiddleMan: A Pub/Sub and Request/Response server in Go. This is my first Go project. It is a rewrite of an existing Python server, based o...
-
I'm now using bzr instead of svn. I'm pushing my repositories to: http://exactlysimilar.org/bzr/ I'm also auto publishing docume...
-
I've just read a newspaper article (courtesy of Kranzky ) from WA Business News documenting the malfeasance, gross negligence and misc...
-
I've just uploaded Fibra 2 to the cheeseshop. Fibra 2 includes the promised non-blocking plugin, which allows a generator based task to...
21 comments:
And what are those undocumented differences that you've encountered?
I think that the transition to Python 3 will succeed, but that it is a great cost for the language to have risked taking at the very point where we have a chance of real growth.
Why has uptake been slow? Because the basic tools for development work — virtualenv, distribute, nose / py.test, and coverage — have only recently started working under Python 3. Until those basic building blocks were in place, frameworks and libraries could not really think of migrating over. And they will have to lead the way — only once the libraries and frameworks are supporting Python 3 will the rest of us be ready to follow.
+1 agree on that...
Let 2.x branch takes care of the little thing and make Python an even better (new) language on the 3.x branch.
Unfortunalty, I think the debate is already over :)
The Google Go argument is a straw man. Python 3 is really good, but it is not the one language to replace them all.. Google is putting effort into technology wide in all directions, and that is just great.
Other than that I think the movement is just really really slow. No word about PyGTK yet, but I hope it will come.
As Brandon says, some modules you really needed was ported only this fall. Transitioning to Python 3 has only just started.
Go is not a competitor to Python, it's a slightly modernized version of C.
Although development on it has been glacial, IMO PyPy has the right idea: migrate away from CPython's C-based extensions and over to [R]Python code that doesn't need recompiled between versions and can be optimized (JITted). In an ideal setting, switching between Python versions should not involve recompiling C libraries.
I wonder how much research you did on the mater, if any?
It's been documented in quite a few places that I've read that the transition is expected to take 3+ years. From the 3.0 release.
There isn't a rush, its better in the long run but if people start dumping 2.x now they are in for a world of pain.
Disclaimer: I'm just a user (not a core or library developer)
This kind of talk gives me fits. I've actually been working with Python 3.0 at work and 3.1 at home. Granted, it's not high powered stuff - text processing, weighted averages, more text processing, but still.
After making an effort to switch to the new print function and string formatting, not to mention the new string binary storage, I couldn't imagine anything worse than the death of Python 3.
I hope the calls of defeat are premature. If nothing else, I've learned a little about bytes and Unicode from using Python 3.1 and 3.0.
Do i understand you correctly? You are claiming python3 tries to be too backwards compatible, based on the select module. Of course this may not be a backwards compatibility thing, just a "wrapper around a common syscall" thing. Just sayin.
Another thing I don't quite get: You start by complaining about select and lack of bakwards compatibility , and end by complaining that it doesn't break enough backwards compatibility.
It is amazing how the clowns just keep getting out of that tiny little car. There goes another one....
Perfect time to ditch python entirely. Sweet.
It will do wonderful. The moratorium is a great idea. They should not do a clear break. Perl has done a clean break with Perl 6 and while some good things have been backported it has been a marketing nightmare.
What they are doing now make me excited about Python's future.
@Anonymous:
Another thing I don't quite get: You start by complaining about select and lack of bakwards compatibility , and end by complaining that it doesn't break enough backwards compatibility.
Yeah, I guess I'm feeling rather ambivalent about the Python 3 move, and that shows in my post. If I didn't expect any backwards compatibility at all, I would take a different approach to porting my software, which would have resulted in more success.
You expect the world to adopt Python 3 in 11 months? Sorry to shoot your pony, but your entire post comes off as so much whining.
@Martin
No, I'm not expecting the world to adopt Python3 in 11 months.
The point I'm trying to make that Python3 adoption may have been helped by a more severe break from Python2. Its just an opinion that fits my personal experience.
I, for one, am going to switch to 3.0 after Google, NASA and facebook have switched. Until then you can be sure python 2.x will go on living as healthy as never before ;)
The rest is an attempt to manipulate the public opinion for obvious reasons.
Personally I just have no interest in Python 3. I've still not heard of any concrete benefit it will give me, while my confidence in the language's progression in usefulness has reduced due to the lack of interest in tackling issues important to me - removing the GIL, adding modern multimedia capabilities to the standard library, and making a sane C API so that extensions don't have to be recompiled every time there's a minor version upgrade being the top 3. Better support for concurrency via the Actor model would be welcome but there seems to be little movement on that front either.
The C API issue is a major problem but one that tends to be ignored by the Unix-only people who are happy recompiling everything every time they upgrade. Many people are still using Python 2.4 or 2.5 because upgrading will break their native code extensions - why would anybody expect them to want to move to 3.0?
New is over-rated.
Why is Python 3 adoption slow?
It's backwards incompatible.
A lot of young developers want new, fresh, exciting.
Fact is, almost 10 years of software development happened on 2.x. Nobody wants to go back and re-write that unless there is a damn good reason.
Python 3 isn't that reason. It's a marginal syntactic improvement on the language. BFD. The first implementation was slow. The latest implementation isn't much better. Nobody really cares that much for the new features.
Python 2.x works just fine right now and has a tonne of software available.
The only way migration to Python 3 is going to pick up is if the implementation becomes significantly faster and more reliable than the 2.x series.
Until then, you're going to see glacially slow adoption. Porting backwards incompatible code is BOOOOOORING. I certainly have better things to do, don't you?
Also Python 3.1 has not been given a chance to show off.
By show off, I mean, there isn't a project that is built 3.1 only, sorta like a "champion".
Imagine a fictional 3jango project - Python 3.1 - now that would get people interested.
Maybe we should try *pimping* 3.1 with something like that.
Python is a general-purpose high-level programming language. Its design philosophy emphasizes code readability. Python supports multiple programming paradigms (primarily object oriented, imperative, and functional) and features a fully dynamic type system and automatic memory management, similar to Perl, Ruby, Scheme, and Tcl. Like other dynamic languages, Python is often used as a scripting language.
Post a Comment