Code written for Java 2 runs fine on Java 8, with extremely limited exceptions.
Java, just as Windows, is used too much in enteprise apps to lose backward compatibility.
Yes, but it's not the default and it does require special considerations. This means that code written by inexperienced developers (or even more experienced developers who aren't familiar with the ins and outs of Unicode and internationalisation etc) will be more likely to behave incorrectly when presented with anything in a foreign language.
If they have difficulty grasping those concepts, then they shouldn't be working with them. They should rather stick to plain ascii/latin-1 and leave the fancy things to people that know what they're doing. Python3 in this case wouldn't be a silver bullet to make them magically work with unicode better.
Nobody should be sticking to plain ascii/latin-1, and certainly not inexperienced developers. The only valid reason for using anything other than UTF-8 these days is that you are interacting with a legacy system that doesn't support it.
Unicode isn't a "fancy thing" that is best left to "people that know what they're doing." It's the difference between displaying a name such as Siån correctly and as a bunch of hieroglyphics.
Besides, even for experienced developers who know what they're doing, if you're imposing any form of ceremony or special considerations around using Unicode, you're increasing the risk of bugs and mistakes.
That's why I say Unicode should be made the default. It's legacy encodings such as Latin-1 that should be treated on a need-to-know basis.
No, defaults are important. It's the difference between "doing the right thing by default" and "doing the wrong thing by default."
Unicode may be of little relevance to some disciplines, such as scientific computing for example, but in others, such as modern web development, it is a deal breaker.
I don't need to be told that proper handling of Unicode is important. I know it's important.
I also don't need to be told that defaults are important. I know they're important.
But it is still a minor improvement under the scope of a ~6 year migration that has been absolute hell to everyone involved. Under any other circumstance, I'd be right there with you saying It's A Really Good Thing, but if we have to pay this high of a cost for it, then the improvement here looks pretty meh to me.
If you want to insist on evaluating this on some absolute scale irrespective of its cost, then I don't want anything to do with that.
Finally, one might argue that whether this is actually minor or not is irrelevant. What's relevant is that a boatload of people perceive the delta between Python 2 and Python 3 to be incredibly small, and yet, the amount of work to migrate is dauntingly large. There's a discrepancy there regardless of whether you disagree with others' valuations of the improvements in Python 3.
I'm the author. I've never worked at Microsoft (where did you get that?). I'm a Linux guy.
The "lazy people" you refer to is 98% of the Python community.
Python 3 didn't "gain" static type checking. You can (and I do) run pylint against Python 2 code which is just static analysis, not full type checking. The situation here has not changed between Python 2 and 3.
Python is glue code. You write a small piece of Python to tie together external libraries. Moving a smallish piece of Python code from Python 2 to Python 3 often means porting several 3rd party libraries. If you were to move to Ruby, all you'd need to rewrite is your own code, as there are likely already 3rd party libraries which need no porting.
From personal observation I'd say that for every person writing major applications in python you have at least 20 using it for glue code. And having written a major application in python, I'm not really convinced it's a good language for it.
Nope no metrics, I doubt very much they exist. But if I can pile on a second personal observation, a significant proportion of people programming python aren't python programmers. They'er engineers, artists, scientists, analysts and statisticians whom are using python to do their job. So even if you somehow did manage to survey a statistically significant number of python programmers, you'd still be missing a large swath of the python community.
As to the application, it was a largely in house tool for an engineering and company I used to work for.
> even if you somehow did manage to survey a statistically significant number of python programmers, you'd still be missing a large swath of the python community.
Depends on how the survey is done. If those engineers, artists, scientists, etc. are using Python, they're using Python, and there are ways to survey that. For one thing, you could look for users of the major Python frameworks listed in the Wikipedia article I linked to elsewhere in this subthread, like NumPy or SciPy.
If you want to claim that, for example, a scientist using SciPy isn't a real "python programmer" because he is only writing "glue code", I've already answered that in another subthread. Application logic is not "glue code". The scientist's application logic is in Python, so he's programming in Python, even if his job title doesn't say "Python programmer".
This doesn't show how many programmers work on "glue code" vs. "major applications" (which is why I asked if anyone has data on that), but it certainly shows that there is a lot of Python code out there that is not just "glue code". Bear in mind that it's not just the particular packages listed on that page, since many of them are frameworks; there are also plenty of "major applications" written in those frameworks.
(I am counting major websites using a web framework, major numerical applications using NumPy or SciPy, etc., as "major applications", btw, not "glue code". I suspect on re-reading this subthread that the poster I was originally responding to might differ with me on that point, but application logic is not "glue code" in my view.)
In every Python book I read they were recommending me to use Python 2.7 instead of 3.0. Shouldn't it be the role of educators to promote the latest version out there and work with it, so that by the time the new students get into a working environment they are already on the same page with what is required?
Prior to the release of 3.2 (Feb. 2011, 2.5 years after the initial 3.0), that was clearly reasonable advice. The io subsystem in 3.0 was quite slow, making it uncompetitive with 2.6, and while 3.1 fixed that, there were still too many missing libraries (and similar issues).
I wonder what would have happened if the software that was called 3.0 had been released as "Python 3 Preview Release" or something. I guess the thinking was that would have held people back even more from trying it/porting stuff, but maybe scaling back (end user) expectations for those first couple of versions would have been the better path.
> Shouldn't it be the role of educators to promote the latest version out there
I think the main role of authors of books on programming is to help their readers to become more effective in solving their programming tasks. So they do, if they're wise and honest.
According to Distrowatch, out of the top twelve (12) distros, all but #8--Arch--use Python2.
The other 11 in order of popularity are #1 Mint, #2 Ubuntu, #3 Debian, #4 Mageia, #5 Fedora, #6 openSUSE, #7 elementary OS, #9 Zorin OS, #10 Puppy Linux, #11 PCLinuxOS, and #12 CentOS.
That's not quite a complete picture. Those distros include Python 2 as the default "python" executable, but many include Python 3 as python3, and even more have standard python3 packages that just aren't installed by default.
At work, I am writing tools in Python 2.6.6 specifically because the latest version of RHEL comes with only that, and I cannot get aftermarket versions of tools onto our servers. Is that the fault of Python? No, but I'm sure I'm not the only person working at a stuffy organization with crappy open source policy.
So do I (in some cases even stuck on Python 2.4) [RHEL 5]. But at the same time (re: Python 2.6) I never really thought "oh I really need the latest 3.4 or my project will fail". It doesn't offer dramatic speed improvement, concurrency, some nice built-in web framework or anything.
I would take 3.4 if someone else spent the time testing and validating my code against but I just don't have the time to invest because I just don't see an upside to it at the moment.
Why are you assuming the worst possible intent on my part, instead of asking what I meant?
I meant the distros have Python 3 available, not that they make it the default that /usr/bin/python points to. Ubuntu has had Python 3 available for quite a number of releases; I run 12.04 which has Python 3.2 (and I've had it installed since I installed Ubuntu). According to the release notes[1], Ubuntu 14.04 makes Python 3.4 available, and work is ongoing to make it the default Python for Ubuntu. They also advise porting to Python 3.
It looks like CentOS makes Python 3.2 available, but I can't be sure from their online documentation.
But I also didn't say you are spreading lies maliciously. You can spread them unknowingly via mis-communication.
I could post something like "Large parts of the Linux kernel are written in C++". And it would be spreading lies. But it could be just be me being confused as well or thinking that a C++ compiler will compile C and that C is a largely a subset of C++.
> I also didn't say you are spreading lies maliciously
My objection wasn't that you imputed malice; it was that you went straight to "spreading lies" instead of expressing uncertainty about what I meant. And you were wrong about what I meant.
> You can spread them unknowingly via mis-communication.
Which, since you were wrong about what I meant, is what you did when you said I was "spreading lies".
Many distros include both Python 2 and Python 3 support. I think pdonis is saying that distros that support Python 3 are not stuck on 3.0. That is, their Python 3 packages are 3.2 or higher, so comparing 2.7 to 3.0 is unreasonable, since it's not a choice anyone has to make. Which seems to be true. For example, the relatively conservative Debian is currently on Python 3.2, with Python 3.3 in the next version. Ubuntu's python3 is currently 3.4. Fedora appears to be 3.2. Arch has Python 3.4, I think.
So what pdonis was saying is, as far as I can tell, true.
The post I was responding to talked about books on Python for students, presumably students studying programming. Python 3 doesn't need to be the default python for students studying programming to use it; it just needs to be available. If the post had been talking about, say, sysadmins, that would be a different story.
I think it's recommended for distros to modify the shebang to /usr/bin/env python3 for script that are supposed to run under python 3, although this does pose a problem for scripts that want to run under both without modification. If the distro ships with python3 and most of the system scripts run under python3 I'd say its the default.Ubuntu for one is planning on not shipping a python2 or /usr/bin/python binary by default(although it will still be in repos) eventually.
Any script worth it's salt that depends on a newer feature of Python 3 can just check `sys.version_info`. This was a thing one had to consider back when new versions of Python 2.x were coming out, too.
It's not quite that simple. Not all code that runs on Python 2 will be syntax-compatible with Python 3, and vice versa. You can, with some effort, use a subset of the Python syntax that is compatible with both interpreters, but many libraries do not do that, but ship separate Python 2 and Python 3 versions if they support both.
Syntax changes can be an issue for backwards compatibility, but that's not what I was talking about.
It's easy to specify what the minimum version of Python you want to support is. Even if there's syntax which is incompatible with Python 2 in the file, a hashbang that specifies `python3` is pretty clear.
Yes, #!/usr/bin/python3 is clear, but I don't think it addresses the question you were responding to, which was whether the scripts the OP of this subthread was talking about, which he knows will run under Python 2 (because he downloaded them and ran them under Python 2--he mentioned this in another subthread), will know to check for the presence of Python 3 and use it. Any such script will have to check sys.version_info to know which version of Python it is running under (and for at least one version the shebang will be irrelevant anyway since it can only specify python or python3, not both), and it will have to be syntax-compatible with both versions. If the script isn't syntax-compatible with Python 3, then he'll have to go find and download a version that is, if it exists.
There was a link to a Microsoft person in the top right of your page. I mistook it for the author link. Edited post to remove that.
You are right that the same tools work for python 2. However, I mentioned tools there which allow python to do type checking, and type inference because they can be done now. See here on how to use them: http://renesd.blogspot.de/2014/05/statically-checking-python...
You're right in that case where you use several libraries that aren't ported. However, there's 4799 packages registered on pypi as supporting python 3, and most of the popular ones are ported. Considering that most libraries are ported, porting small scripts should be easy most of the time. I don't know if you actually ported any code, but it's often trivial.
If you are running multiple automated eCommerce companies that have their core system written in Python 2 like I do, you'd find that boto/mws and python-excel aren't available for Python 3 (python-excel's porting to Py3 stopped in 2011), which would prevent you from spawning new businesses on Amazon or handling (unfortunately standard) MS Office interchange files quickly.
I actually made the decision to run on Python 2 due to unavailability of these libraries for Python 3 about a year ago (I didn't really care about Python before as I primarily used C++/Java/Asm/GLSL/C#/Haskell in the past) - I was deeply shocked by what Py3 did to its own community and still have that weird feeling that Python is slowly killing itself. I didn't want to write my own Amazon and MS Office wrappers in Python 3 anyway and from all platforms available Py2 seemed to have the least amount of troubles (though I had to write some Py3 code for handling advanced TLS properly).
yup. I think this is the reason so much eCommerce software is Java (& I'm sure there is a bunch of C# but that's not my thing). Java moves like a glacier but damn is it ever stable, and for those who wish to be "cutting edge" there is everything-under-the-sun on the JVM -- Clojure, Scala, Jython, JRuby, slimmer-by-the-minute Java APIs. And the community is just working their lil buns off trying to modernize this stuff while maintaining interop / backwards compatibility.
I think the flack Java gets is for not modernizing fast enough, but I think in a way that makes you stop and smell the roses (the roses being many years' worth of badass JVM features and massive flexibility/reliability in software development).
But Ruby & Python (I am an ex-Ruby guy) take this cutting edge thing wayyy too far & end up with a community of people who can't trust them anymore cuz they all had their damn feet shot off. Sometimes I see the rates for Ruby guys & wonder if they're high cuz its so productive or just cuz its very niche & the stack is shite. On principal, it's hard for me to imagine going back down that road after experiencing the JVM (plus, I'd like to get away from web one day...).
EDIT: Funny thing I just realized actually -- all the Ruby rates I've seen tend to be exactly on par with a lot of FUBAR niche near-extinct Java technologies. The only people I've seen do better than both these camps are down & dirty Linux/Oracle/Java guys. Maybe my view is skewed but I always feel like the rock-solid langs will live on & eventually "modernize" (though lets be real, modernize is kindof a BS term for slim API & lots of MVC tutorials). These other techs are at the mercy of market trends.
I worked at SUN in the distant past, the backwards compatibility was the mantra #1. Both latest Java and Solaris were expected to run the oldest possible code, and they considered it one of the most important assets.
For many people in eCommerce and banking the arrival of Java was a "manna from heaven", as before they had to deal with the crazy complexity of CORBA and similar technologies. Java simplified this significantly and added at the time modern easy-to-program and fairly safe multi-threading that allowed software like Apache etc. This made Java famous and gave it a "huge karma" amongst developers. Without Java we probably wouldn't have experienced the massive expansion of eCommerce, and now we are lucky to see all the Java's issues - a good problem to have ;-)
Java and JVM as a consequence have their share of problems that arose from initial design decisions such as type erasure (which .NET's CLR avoided) that still deforms all languages based on JVM to this day. Massive boilerplating, J2EE's unreadable XML mess, complex design patterns invented to cope with the limitations of the language are some of the other problems. The compatibility with the old code is still there though.
I've never played with Ruby, I've heard it's still used by many young web companies for their frontends (like SoundCloud) and have heard they had some release that broke most of the compatibility which alienated many of their users. From this and from Python's example I would suggest keeping both the old way and introducing the new ways in parallel so that developers don't have to rewrite/reinvent the wheel when somebody decides to change a part of the language. This served C/C++ pretty well, adding slowly new features and instead of forcing users to use the "current right way", they allowed to live multiple different approaches together. I think that would have served Python well as well - even Py3 feels at places like a hack, similar to Py2.
Java is simply becoming the next C. For a reason, in my opinion, since the languages share quite a few traits both on the language level and the ecosystem level. Both are fast. Both have a rock solid execution system which sometimes feels backwards compatible to the first punch card made of rock (gcc vs JVM). Both of them have huge communities having significant infrastructural services and other huge code bases developed in them (linux kernel, application servers, databases in both teams). The big improvement of java would be a higher programmer safety.
And to be fair, neither language is the prettiest, shiniest and fanciest for it's time, but they get the darned job done.
you (& bitL as well) make some fair points but I actually (maybe because I'm newer to Java?) have quite a different experience with it. The XML setup seems minimal now (sure it's all there but most stuff is now handled with reasonable default configs & annotations).
Take Jax-Rs is a good example. Once you understand it you're just like "Ohhhhh this is the same way Rails/whatever framework handles json requests but I can add in all this non-linear logic without forcing it to play nicely within a presumptuous design pattern". Adding many data sources & logic flows is easy.
Bottom line is that I feel like Java can never really be the next C because fundamentally its much safer and becoming way more human readable. It toes the line well -- you can code minimal stuff similar to the scripting languages, or you can drop years of work/research into optimization for high-transaction algorithms knowing that the platform won't abandon you.
(By the way, I am personally hoping for Clojure or node.js to take over the front-end of the stack & then just using Java to do any heavy lifting that is left over)
I just looked at that list and I see several prominent projects that (according to that list) don't support Python 3: MySQL-python, gevent, Twisted, eventlet, oauth2, thrift, nltk, mechanize, etc. I've used more than a few of these libraries over the years.
I mean, yeah, the list is getting smaller. That's understood. But that doesn't render the problem of depending on only-Python 2 libraries moot.
I think the fundamental insight of the OP is that Python X (the purgatory corresponding to code compatible with both Python 2 and 3) is an absolute pain to write. There's plenty you can do to make Python X easier (like the `six` library or ignoring Python 3.{0,1,2}), but the programmer is still left with the burden of writing code compatible with both versions.
There's just no denying that the Python 3 transition is a huge fucking pain that is costing people tons of time and money. With that in mind, it is absolutely reasonable that people are resisting the change.
Yes, I knew most of that. But the fact remains that they aren't complete yet and therefore can't actually be relied on as a dependency.
(N.B. I seem to recall someone telling me that gevent had been ported over a year ago and that all that remained was to just make a release. So count me skeptical until the port is complete.)
And that's just the most popular projects. Imagine what it looks like with the less popular projects? It isn't pretty. This is what the OP was talking about with the "tail" of Python projects.
N.B. I don't personally have this problem with less popular projects. I've always done my best to avoid depending on unmaintained or inactive projects because they tend to rot as time goes on (irrespective of massive changes like Python 2 and 3). But plenty of other people have this problem and it's definitely not an unreasonable problem to have.
Off the top of my head: Twisted and gevent. It was actually the lack of a Python 3 gevent that lead my to create one crucial piece of software for my startup using NodeJs communicating with the main Python application passing messages via Redis.
Look, I'm a Python 3 supporter, but you should never foist the Python 3 fork of gevent on anyone.
I'm pretty sure that, the monkey-patched way most people use it, it's a happy accident when gevent even works correctly on Python 2. This happy accident doesn't happen in an unofficial fork.
To clarify: NLTK develop branch is compatible with Python 3.2+ for more than a year. NLTK 3.0a4 (http://www.nltk.org/nltk3-alpha/) is not released as NLTK 3.0 because of some pending API changes, not because of Python 3 compatibility issues.
i use NLTK with python 3.4 (and before that, 3.3); NLTK has an alpha release for pyhthon 3; i have not had any problems either installing it or using it.
Ok so why would I risk hitting even one incompatible library or have stuff break because those are dev experimental, untested branches. Why? What does Python 3 offer me except risk of breakage?
Did you read the article? The long tail is the critical collection of libraries and most of them will never be ported. People write new Python 2 libraries every day, actually--the list is getting longer, not shorter. That said, gevent is an extremely critical library for a lot of production Python 2 code. There doesn't even seem to be a roadmap to port it to Python 3.
This is affecting other parts of Ubuntu, as we don't always install python2 anymore after porting all the default apps to python3. The lack of python3 launchpadlib means apport (the automatic bug reporting tool) doesn't work on some installations.
Let's assume a modestly sized Python program uses 8 libraries or so. Assuming 80% of libraries are ported, that means 20% aren't. The likelihood of at least one of your 8 libraries not being ported is 1 - (0.8)^8 = 83%. In other words, most people will find that at least one of their cricitcal libraries is not ported. That is certainly the case for me (Bloomberg Python API, for 2.7, and which, btw, only came out 6 months ago). Inevitably the people using Python come from specific domains, and use at least one ___domain specific library, so while all the common "usual suspect" libraries are ported, there is usually a very high chance that one critical library is not.
Perhaps the way the entire question should be thought of is: are there actually many properly useful Python 3 libraries that are not available in Python 2?? I bet the above equation would look much better when inverted.
There's a large number of significant commercial applications that use Python as their scripting and plug-in language. Non of them that I am aware of are showing any interest in Python 3.
Why is that? I think you're misled by OSX's numbering system, which uses .x where other operating systems might use whole numbers. In fact, I misestimated myself...I thought each dot-version represented a year, with Tiger being 4 years old.
It's a common technique to serialize arbitrary data into blob fields in SQL databases--I've seen it for years. Usually, it is considered an anti-pattern. Postgres 9.1 doesn't do much other than verify the JSON data is valid JSON and then stores it unchanged, though successive versions are adding more first-class JSON support.
I think they work off of current robots.txt so if you purchase a ___domain name update the robots.txt to not allow archive.org they delete the entire history.
Yeah, they really ought to work from the version of robots.txt archived along with a given snapshot. If the legal owner of the content wants it taken down, they can submit an explicit request for that.
