1. Obsolete. Either explicitly so (e.g. Google API) or abandoned, without even a minor/patch release (initools, 2010) or in some cases a code commit (e.g. pathtools, 2012) for five years or more. I suspect that they will never be Py3, the community will just move on to alternatives.
2. Working hard to bring support (e.g. ansible).
3. Part of the graphite ecosystem. If the base library won't change, none of its ecosystem will.
4. Not on public version control / issue tracking, so who knows (e.g. supervisord)
A brief look around the supervisor site indicates that they have public version control and issue tracking on their github page[0] and that they have a merged PR[1] to add python 3 testing (which appears to be passing).
In addition, Fabric doesn't support Python 3. The feedback I've gotten back on when Python 3 will be supported and how much of the legacy fabric API's will be supported is even more limited.
Lack of commit activity doesn't necessarily mean a package is obsolete. A small set of well defined functionality can be "done" at some point and need no further changes.
All software rots because even if the functionality never needs to change, the world (and the APIs) around it will. Some code just rots slower than others.
If you do need supervisord, a (from my experience) suitable alternative is circusd. Though I’ve since moved to having either the operating system’s process manager (usually systemd anymore) or docker become my process manager.
Huh. I know if I have a server that only has python3, Ansible can configure that server with only the python3 interpreter available. So Ansible can use python3 on the box it's configuring, but not the host it's running from?
I believe they just haven't officially defined Ansible as Python 3 compliant because there are still open issues in Github related to Python 2.
I have been using Ansible exclusively with Python 3 for over a year and only stumbled into incompatible code once, a simple case of string VS bytes literals that got quickly fixed.
Open source can mean that the source is available on request, or is available after purchasing a licence. It doesn't have to be publicly available to be open source, though in practice it pretty much always is.
Even with the GPL, the source doesn't need to be publicly available for everyone to read. Only paying customers are guaranteed the right to the code. (Some car makers have GPL software and only give out the source code to verified car owners.)
Yup at this point there is no reason to not use Python 3 for new projects. What I'm finding actually is that some companies that have their codebase in Python 2 have actually started migrating to Golang rather than Python 3, because of the increased performance benefits.
I'm kind of sad about this, but I think that Golang will eventually replace Python as the go-to back-end server language (maybe even data processing).
Sets don't need to be native in languages that are both fast and have a proper type system. For example, rust and OCaml have a standard set in their stdlib, but it's not builtin.
Of course, go lacking generics makes it impossible to implement a decent set type in it.
I wouldn't hold up OCaml as an example of how to structure your standard library, the lack of standardisation in its standard library is one of the remaining weak points of an otherwise excellent language. For those that don't know, there are multiple standard libraries for OCaml, each with different trade-offs, leading to unnecessary fragmentation.
Agreed, some things are still missing (in particular my pet peeve, iterators; also unicode strings). But for what it provides, OCaml's stdlib is reasonably well designed and performs well.
Sets, if you mean a collection that contains no more than 1 of something, are easy. Use a map with struct{}{} values. If ordering is important, it's ~30 lines of simple code to encase a slice and a map in a struct and define your desired interface.
Testing for a key's existence is easy as well. Accessing a map returns two variables--the 1st is the value itself. The 2nd variable is that "exists" variable you're asking for. It's true when the key is present in the map and false if not. Often you'll see the 2nd variable omitted, but if you need to test for existence it's there for you to use.
Testing membership is the easy part of sets. What about subset, superset, union, intersection, difference? So many problems are trivial thanks to sets.
I'd sooner give up regex support in python than the set type, that is how useful they are.
type Strings map[string]stdext.Unit
[…]
func (a Strings) Intersection(b Strings) Strings {
result := NewStrings()
for as, _ := range a {
for bs, _ := range b {
if as == bs {
result.Add(as)
break
}
}
}
return result
}
You have N groups of something (persons, sales units, cars, tools, whatever). Find the values that are present in all of them. This problem comes up, all the time, in some form.
With sets it's trivial. Take the first set, and calculate a cascading intersection with every other set. At the end you're left with only the values that appeared in every one. In very clear python the code might look like this:
common = ALL_SETS[0]
for _set in ALL_SETS[1:]:
common = common.intersection(_set)
return common
Now, you can argue that underneath the hood that's still going to do N expensive iterations and you'd be right. This is where proper optimisations come in - when provided by a robust stdlib, we expect the set operations to be implemented with bitmaps.[0, 1] These are not something you'd see in a casual implementation.
Btw, in the above code example I have deliberately omitted a trivial optimisation. Let's leave that as an exercise for the reader. :)
If sets are a good match for your problem (and I agree, they tend to be for many common ones), you definitely should use them in Go. Just write the fucking code.
Even if you use the most obvious, naive code to implement fundamental set operation in Go, the resulting program is probably still faster than whatever you're going to write in Python.
In the absolute worst case, you need to generate an extra copy to use with some other type. Mildly annoying for sure, but easily dealt with.
If a hundred people need to write that code anew a thousand times, somebody's going to screw it up. Widely used and heavily tested code is how we get a more powerful foundation to build on.
If the answer is to generate the Go, then we should be having human beings focus on the more powerful language controlling that generator.
Yes you can hack sets into most any modern language, but mostly involves writing annoying looking boilerplate, or pulling in external libraries.
I think parent is looking for a native set type (which I agree with). I don't know if it has a place in golang, but I always sigh and roll my eyes when I have to implement a set in most languages.
I'm currently using Go (and Python - we did go from Python 2 to Go, but later continued using Python 3) at work, but for all of the hoopla about it's concurrency, the reality is I'd rather have Rust's superior runtime safety and metaprogramming. A few things have impeded on Rust adoption at work:
- Learning curve. Rust is not as bad for learning as C++, but any language with strong metaprogramming and unfamiliar or relatively new language concepts are bound to be stumbling blocks.
- Ecosystem. The Go ecosystem by and large is awesome. Rust's is getting up there, though. It'd be really cool if Mozillas work with Servo meant there would be pure Rust HTML rendering and JavaScript interpreter code though! So far, impressed with minimal but powerful libraries like Iron.
- Maturity. Rust itself is pretty good, even nightly feels stable, but the developer tools are still shaping up. Until recently, rustup crashed on my Win10. Things are a lot better today, especially with the Rust Language Server.
- Marketing. Rust has a ways to go on its marketing. This has improved recently as well and I'm glad. Some underestimate the importance of having good PR for a programming language - people need to be really confident to adopt a programming language for critical components, and Go is in a place where many would trust it just because of its reputation. Also good for convincing your coworkers to give it a shot.
That being said, while Go makes concurrency easy and generally acts as a great simplistic language to develop services in, I really feel as though Rust's potential is enormous. The 'simplicity debt' of Go can be taxing sometimes.
I still love Go, though. I am just struggling to figure out which tool to use for which jobs. Though there's large areas of overlap, there are definitely things that feel nicer in either than the other.
I kind of like the idea of Rust, but I don't really have much belief in complex programming languages. C++ only has a large following because it piggy backed on C, which people already knew, then it gradually grew its complexity.
It is quite a different challenge to get people to use an entirely new language with high complexity.
Companies are going to be negative towards adopting a language with a steep learning curve for its employees. That represents too much risk and money.
I think Swift is a much better alternative to those who want something like Rust. Much easier to learn and you still got native code and strict typing without a need for a garbage collector.
People also know they can trust it in the sense that they know Apple supports it and all Apple development is switching to it. That takes a way a big risk factor for companies.
I don't think that's why C++ is popular - I think that C++ started as "C with Classes" is what got it off the ground, but if it were just that it wouldn't be around today. Similarly, Objective C doesn't enjoy much adoption outside of it's creator's domain, despite the obviously more elegant integration of object oriented programming.
I think, rather, C++'s brand of metaprogramming ended up being a big deal. C++ template metaprogramming and now const_expr allow for doing a lot of work at compile time, allowing higher level constructs to compile away to virtually nothing.
That it's compatible with C definitely helps still though, since it means you can still use C libraries and APIs, including the APIs of most operating systems.
In C++ there were programming styles that were "memory safe," relying on a combination of stack based lifetime and 'smart' pointers. While in practice most C++ code is very far from memory safe, I'd say this alone vastly improved software quality over C for big projects.
Rust represents an opportunity to do all the things C++ did right in a fresh language that is actually memory safe and doesn't suffer from the syntax C++ has. To me it's no surprise it was developed by the same people who write browsers - these are people that "get" it when it comes to huge, mission critical codebases. The complexity of Rust isn't a bug, it's a feature.
Go's simplicity is it's biggest strength and weakness, in my opinion. Code generation isn't cutting it as a substition for good low cost abstractions. Don't you hate when you end up in scenarios where you wish things could be typesafe but you realize to get there you'd need to write a codegen? I.E. there's a typesafe GraphQL library for Rust, but the equivalent library in Go will drop you back to interface{} constantly.
I would implore people to try to look past the instinct that simple is better in some cases. There's a balance to strike that yields the best benefits of 'simple' and 'featureful' and I personally believe Rust is closer to it than Go or C++.
I will still be coming back to Go and look forward to Go 2.0, but it'll be hard to look past some of the shortcomings when I'm writing performance critical code and wish I had more safety and control.
(Sidenote: I have a performance critical piece of code at my work written in Go, and it ends up using a ton of memory as a property of the GC. Go's low latency GC is cool, but there are definitely trade offs.)
(Sidenote 2: I wasn't enticed by Swift enough to give it a try, so I have no comments to make on Swift. I'm sure it's fine. It doesn't seem to be what I'm looking for.)
For network glue, Go is a wonderful and super useful language. Not just in how efficient it is, or how easy FFI calls are, but also in how easy it is to deploy.
I don't see Go replacing anything that isn't a lightweight server or really small data processing script, though. Anything Tensorflow or numpy of any notable complexity will probably remain Python afaict.
The key question is how many lines of code would Kubernetes have if Go was an expressive language, but I don't have big hopes for a hypothetical Go 2.0.
However Python is getting attacked by new language in all areas where it is being used. Go attacks just one area.
Julia is a much better language for data science than Python. It was essentially designed for it, while for Python it was an afterthought.
Python has a head start today with a large selection of packages and mindshare, but as we've seen with Go, I think that will start eroding in the future.
Python simply can't keep up with the development pace and possibilities offered with Julia. For Data Science and AI packages in Python to have acceptable performance they need to be written in C/C++, this means slow development. Julia has high enough performance that all these packages can be developed in Julia itself. And this is what people in this area is observing. That package development is moving much faster in the Julia community than in Python.
You can also combine these packages in ways that are simply impossible to do in Python. The need to interface with C/C++ creates a lot of artificial restrictions. E.g. processing lots of data fast requires big NumPy buffers with plain data types.
In Julia you can e.g. create a an image buffer made up of color objects and process it fast.
Unlike Go, Julia offers the ability of a gradual transition to Julia from Python, since Python packages can be used in Julia.
To me, Julia feels clunky as all hell. The other thing is that Julia doesn't help for deep learning, where something like 99.99% of the computation time is actually CUDA kernels.
I don't know; I actually really like the optional typing of Julia in theory, I don't know why I find the language so unpleasant.
Agreed. I think the reason is because the programming mindset for data science is different than for normal software engineering. In data science, you write a program, find the answer, write your paper, and throw the program away. Python fits this usage pattern very well.
It is still not installed by default on Macs and that is a sufficient reason not to use it for me. It is far better to be able to tell users they can simply download and run your app without external dependencies. It is also important that downloads be small (i.e. I’m not embedding an entire Python 3 interpreter into my download if the preinstalled Python 2 works as well as it needs to).
Why on earth do people downvote that? I want a language that isn't going to change. Every single other language community seems to understand that, but something about it pisses off Python people.
You're claiming to know the future of Python better than "Python people" know the future of Python.
Python has changed incompatibly once in 26 years, and never plans to do it again, yet you're making it sound like an ongoing pattern. What language are you going to run to that has that kind of track record?
> Python has changed incompatibly once in 26 years
That's not true. Every change breaks some behavior, even if it's not throwing an Exception where one used to be thrown. Things are still being deprecated and removed in new releases.
On top of that, by adding new syntax in 3.7+, libraries may become incompatible with the system-provided installation. That won't happen with 2.7 libraries.
30 years later, scheme is still scheme. A different report has come out, and some compilers choose to implement it. But the language hasn't changed. See my point?
I particularly don't see your point when it comes to Scheme. The Scheme I learned in 2002 (MIT Scheme) is all but abandoned. I was one of the people hired to rewrite MIT's course code from MIT Scheme to DrScheme, which was definitely not compatible. DrScheme itself has been superseded by Racket, except at that point MIT changed all their CS courses and rewrote everything again in Python.
What Scheme implementation do you use that has never broken compatibility and continues to be maintained?
Of course code being data in Scheme you could easily write program that processes scheme code and transforms it to a different syntax. I would assume this would be harder with Python code.
Not particularly. Like any sane programming language, Python has an AST. That's code as data. For porting, it doesn't particularly matter to be able to treat code as data while running that code.
There are tools that use the AST to translate Python 2 to Python 3, such as python-future. (Unfortunately, one of the things the core Python devs botched about the transition is that they put an awful, incomplete, broken one of these named 2to3 in the standard Python distribution.)
Racket's approach is rather different; they just support all the different Scheme/Racket syntaxes and standard libraries PLT has ever supported, with the same runtime. This doesn't include MIT Scheme but there is a syntax for the subset of it used in SICP. I don't think they have anything that converts code between the syntaxes.
I wouldn't mind seeing Python also use that approach -- a Python 3 runtime that runs Python 2 code (and maybe borks your Unicode, which is fine because people who stay on Python 2 clearly don't care that much about Unicode, and that's their prerogative). I'm convinced the only reason no such thing exists is that the first person who makes it would become responsible for everybody's awful old Python 2 code. Maybe in 2020 someone will make it and charge money for it.
If you read the original Scheme report, you'll notice that it's full of example programs, zero of which run on modern Schemes. They're full of operators that Scheme doesn't have anymore, like BLOCK, PROGN, CATCH, ASET, -$, *$, //$, EVALUATE!UNINTERRUPTIBLY, START!PROCESS, etc.
I have extreme Python 2-vs-3 fatigue and that's only from seeing the topic on news aggregators for years on end. I can't fathom how tedious the topic must be for those actually in the Python community for the whole time.
Rather heavy Python user here, though a little bit less over the last year: I think the whole thing is largely overblown. I've fully migrated to Python3 three years ago, was expecting horror given all the articles and 2vs3 drama, yet it was done very quickly and painlessly.
I've gone through migrations that were much more tedious and painful. Not so much with languages but with dependencies/frameworks: the like of Django, Django-rest-framework, Unity 3D, and pretty much anything javascript (apart from javascript itself).
I feel like it's the news that are tedious mostly. Py3 has been an exciting upgrade, but almost a non-event in the grand scheme of things. At least in my Python dev life.
Community might have, but industry hasn't. You're right, the dust has settled. If you haven't migrated to Python 3 yet, you likely never will. All the reasons to use 2 or 3 have already been established. I doubt there will be any more new information that will sway people from the stance they've already taken.
It's not really bad anymore. I moved to 3 about two years ago now, and haven't looked back. There was a brief period of working with polyfilled six hacks, but currently the community and momentum are largely behind 3.
There was a point where there was some FUD around the migration, painting it as a sequel to PERL 6. However, the community managed to turn it around. To their credit, orchestrating large breaking changes to a popular language with a diverse set of use cases is fundamentally a very challenging task.
The main holdouts for Python 2 are large organizations which have a lot of existing/working legacy code. The majority of new Python projects seem to be using Python 3.
Now that the work is nearly done, we can all enjoy a better Python.
I very recently moved to 3.6, from 3.5. There's a saying that a luxury once sampled becomes a necessity, which sums up my opinion on the new f-string syntax.
For me, completely outside the Python community, I really can't fathom how migrating to the next major version of the language can protract for so long...
And I have been in some painful migrations in my life...
Java 1.4 to 5 in a >1M loc "enterprise" application.
From an object oriented database to oracle in the same application.
But it didn't last for close to 10 years.
It's simply a complete nonsense to my eyes.
It's not 10 years, just 2-3 years. Python3 for the longest time was not useable. Only with 3.3 it became stable enough, and it took until 3.5 until it was even good enough and many libs were ported.
On top of it, Python2 works so well and python3 introduces so few advantages that doing an expensive port is just not feasable for many codebases.
And I guess that python is used mostly by smaller companys with constantly lacking manpower and money plays also an important role.
I think the main reason was a lack of agreement between the community and the language maintainer(s) (see: Guido the BDFL). I highly doubt something like this would have happened if the community had been involved. The language maintainers themselves have clarified that introducing breaking changes was a mistake in hindsight and that it will never happen again.
Anyways, the fiasco is over and Python 3 has emerged as the victor, so there really is no use discussing the issue anymore imo.
>The language maintainers themselves have clarified that introducing breaking changes was a mistake in hindsight and that it will never happen again.
What are you referring to? I haven't heard or read any core developers say anything close to 'introducing breaking changes was a mistake in hindsight'.
There's a big difference between 'Python 3 was a mistake' and 'we won't make Python 4 like Python 3'. This article is saying the latter (and implicitly argues against the former).
I think the reasonable middleground for most Python devs right now: if a medium or large project already written in Python 2 is working well, you can keep it as is, but new projects should be written in Python 3. That unfortunately isn't an option for many people in corporate and other bureaucratic environments, but when it is an option there's no reason not to do so.
Yes. My friend is employed at Redhat and he told me that he also works on porting 2 to 3 (although not fulltime), and it is a huge amount of work. They work on it several years already, and it is still far from finished.
Python 3 is a case study on how you should never create a new version of a language implementation that can't load and interface with code written for the old version.
After almost 10 years, the old version is still in use, and the new version isn't even that much better.
I don't know. The introduction of Python 3 caused massive headaches and fractured communities, but the alternative of dealing with unattractive warts in a language until eternity is also not very attractive.
I quite like Python 3, and most of the backward-incompatible changes it introduced.
but the alternative of dealing with unattractive warts in a language until eternity is also not very attractive.
The problem is that the only significant wart that got fixed was Unicode. We still have the GIL, a very slow runtime, convoluted packaging, barely-usable lambdas, and limited typing. That's a pretty lousy payoff for 10 years and probably millions of engineer-hours.
The people who work on CPython were not trying to "fix" any of the things you listed in Python 3. They seem happy with the GIL and the tradeoffs they've made in the runtime. Guido has never liked lambdas and their poor state in Python is not an accident.
Python might be making bad calls, but it's hard to criticized a process for failing to accomplish things it wasn't trying to accomplish.
If py3 never happened, then py2 would have also have evolved at an equal pace. Nobody can accurately calculate missed opportunity cost, but "almost there, everyone please use py3 now, its not a problem anymore" after 10 years is as high as it gets.
Given the Python versioning effective convention, it would be strange for the developers to go from 3.9 -> 4.0 because they've run out of digits. Probably better to go to 3.10 to avoid confusion and stay on 3.X while there's no backwards-compatible breaks.
Yup. They eventually decided they might go to 3.10 after 3.9.
From the article above:
> Update: After this post was originally written back in 2014, subsequent discussions on the core python-dev mailing list led to the conclusion that the release after 3.9 will probably just be 3.10. However, a 4.0 will presumably still happen some day, and the premise of this article is expected to hold for that release: it will be held to the same backwards compatibility obligations as a Python 3.X to 3.X+1 update.
I would like to know if fellow HNers who regularly code in Python are using f-strings and type hints in your production code or otherwise. I often find myself inclined to use type hinting.
F-strings are super convenient, especially for transient expressions such as debugging statements, but also for things like error messages (I often shy away from them on library code for backwards compatibility, though). I wish they were available as a __future__ import.
I have use type hinting in all my Python code since the beginning of the year. And, I run mypy checking (with --ignore-missing for now) on it too.
It's been pretty great with a few exceptions in a couple weird case. And, I've only had to use the `# type: ignore` escape hatch on like less than 10 lines in a thousand roughly.
Before type hinting I was getting really down on Python and using a lot of Go. But, since then it's evened out more.
I don't think I could've survived engineering in Python without type hints. I came from a big 5 and engineering in C++ for several years and had to run a team of 5 not-so-great engineers in a python codebase. The hit that dynamic typing causes to readability, maintainability, bug risk, etc is _huge_, and type hinting goes some way towards fixing that.
No, I'm sorry, the way I wrote that was misleading. When I was at the bigco, I was quite happy with the quality of engineers around me. I joined a tiny startup after that and was the lead eng on a Python codebase, and that's where all the headaches of a dynamic codebase with untalented engineers came into play.
Yes, I'm using F-strings exclusively for new (Py3.6-based) projects, and type hinting quite extensively (also for old projects still based on Python 2.7 - using the '# type: ...' workaround).
Love the f strings but I sometimes don't use them if I'm worried that the code won't necessarily be run in Python 3.6. Unless it's a self contained docker container - I'm wary of using the f strings everywhere just due to compatibility issues.
Side note: Languages like Ruby have had this for a long time. Better late than never, Python!
boto is effectively a deprecated package. Use boto3, which has a far better architecture, is rigorously tested and maintained with lots of community activity.
I agree with you - MWS should be spun off. It's not part of AWS and the API has many differences (but because there are also lots of similarities, it would probably make sense to build a replacement using some of the botocore utility classes).
Nice work everyone! I’d be curious to see what a “Python 2 deprecation” page would look like (although deprecating Python 2 support shouldn’t be the goal of course)
Based on having worked for 3 corporations using python I can tell you it's not going to happen by 2020. Python 2.7 will live on in big companies for a couple more decades. I will end my career before python 3 is adopted. It's more likely that by that time some other scripting language will be more popular.
Was it just the time that the ecosystem needed to adapt to the Python 3 changes or were there essential changes in the 3.x versions up to 3.6 that made it easier to switch from Python 2?
Some of both (for example, % formatting got added back to bytes objects in 3.5).
Also, supporting 2.5 (or even 2.4) together with Python 3 was particularly inconvenient, so things sped up after people stopped caring about those (which took a long time because some people were running extended-support enterprise distributions).
Yes. But there are very few differences anyway. The only thing is that there is not 100% backward compatibility, which is why we get articles like this. For computers that is a Big Deal, but for humans it is really easy.
While many companies still use Python 2.X, they are sufficiently similar that I would recommend learning 3 and retrofitting your knowledge set if necessary later on.
You got many rational reasons for starting learning Python with Python 2:
- It is easier syntax and string-handling for beginners. Else, look for someone who started learning Python with Python 3 and ask them about their experience. You probably won't find many here.
- There are more resources online for learning Python 2. Many MOOCs happily teach Python 2.
- ~5% of very popular libraries are not ported yet. Many unpopular libraries will never see a port. Some use this as an argument for switching to Python 3, but that is like being blind and being told to be happy that the number of inaccessible websites went from 10% to 5%, telling you there is no reason to look at those inaccessible websites.
- Many companies still use Python 2.
- Many distributions come with Python 2 installed.
- Switching from Python 2 to Python 3 is but a minor annoyance, mostly in paying the print-tax. Switching from Python 3-exclusive code to Python 2 is downright hell.
The reasons not to learn Python 2 and start with Python 3 are:
- Python 2 is deemed legacy and will see no security patches after 2020.
- Python 2/3 is painful for some developers and maintainers. They'll cloud this is in a "move Python forward" that is reminiscent of the "move the web forward"-movement (by deliberately breaking designs for older browsers, or forcing the user to download a font to make their layout work properly).
- Python 3 proponents don't care about you learning a new language, they care about adding 1 to the dwindling adoption count of Python 3. They see Python 2 as competition, a ghost from the past. Here the reasons they give you have nothing to do with you wanting the easiest path to mastering Python. These are either political or selfish reasons.
You'll be in the minority on HN if you go Python 2. But realize that HN's stance on Python is not a beginners stance. They use features of the language that you won't use for another 2 years. They have very strong opinions on 2 vs. 3, alternating between calling it a completely different language, and the same (but improved) language, whenever it suits their argument.
As someone who asked the same question a few years back (and gladly received the answer: Python 2), I'd suggest you learn both.
Does not matter which language you start in, as long as you can write Python 2/3 compatible code. Perhaps starting with Python 2 (and the fantastic "LearnPythonTheHardWay") helps with this. You'll just have to unlearn a few Py2 warts like xrange and using print statements with ellipses.
You are not being progressive, nor doing your users a favor, if you go exclusively Python 3. Even if the language owners decided not to be backwards compatible, your code still can be (and, IMO, proudly should).
As you arrive to a point where you want to use Python 3 exclusive language features, you'll be at least advanced in Python enough, to form your own well-informed opinion on the matter. I myself don't feel like library support for Python 3 should be the deciding factor for a switch. That's like switching to exclusively designing for a certain browser version, because most websites render just fine, leaving users stuck on IE6 without accessible content.
I'd suggest OP learns Python 3 and try really hard not to look at Python 2 ever, which hopefully shouldn't be too hard in 2017.
> as long as you can write Python 2/3 compatible code
Maintaining a Python 2 and 3 compatible codebase in a PITA. OP wants to learn a new language, presumably to build things with it. But your advice is that they acquire insight of all the mistakes of a language that was released 7 years ago (that's for 2.7, 2.0 was release in 2000) and will reach end-of-life in 2 years.
I'd really like to understand why in the world you would want to learn Python 2 and its “warts“, to then discover that all this stuff are just unnecessary pain points that were removed/refactored/cleaned up in Python 3.
In my opinion, Python 2 and 3 are two different languages and should be treated like so.
> [not] doing your users a favor, if you go exclusively Python 3
Actually you are. If you start a project today and make it Python 2 + 3, you are forcing your users (most of whom in 2017 would be proud Python 3 users anyway) to cope with a. all the bugs introduced by the compat code you have to write and b. the delayed releases/bugfixes caused by the subtle Python 2/3 discrepancies you'll face one day or the other.
I will make no comment on the IE6 comparison: this isn't about corporate employees or banking apps from the 90's.
> Maintaining a Python 2 and 3 compatible codebase in a PITA.
I maintain multiple Py 2-3 compatible codebases, both academically and commercially. It's not hard, because I develop in Python 2, while writing Python 3 compatible code.
Python 2 is a beautiful language as powerful as:
import antigravity
print "Hello, world!"
There is nothing a beginner can't do in Python 2 that he/she can do in Python 3.
If Python is a different language and should be treated like so, then I don't want to switch to this other language, or have a project support two different languages (I'd switch to Go if having to switch languages). For all intents and purposes: Python 2 works just fine. Google did not need Python 3 when they first released TensorFlow a year back.
> If you start a project today and make it Python 2 + 3
Then you are compatible will the largest amount of users. That's what matters to me: Somebody on a fresh install being able to pip install my library, no matter if it is Python 2.7+ or 3.4+. All other reasons are politics.
> this isn't about corporate employees or banking apps from the 90's.
No, it's about banking apps from the 00's and 10's.
Python 3 killed Python?
Feels like the Perl story again, lack of backwards compatibility or "next version will be perfect" killed the language.
And people still complain about Java, C# and others being too slow to deprecate old apis.
It's great that finally the popular packages are pretty much all supported.
But the question is, is that really the problem? It's a bit like Microsoft Word: so many alternative word processors implement all the popular features. So what's the problem? The problem is, nearly everybody has some obscure feature they depend on. So even if an alternative has all the popular features, still almost nobody can use it. I think the constant referral to how many "popular" packages support python3 leads to a bit of false sense of optimism in the python world: it's perfectly possible to support all the popular packages with Python 3 and yet have it be unusable for a large percentage of users.
I was burned by that problem two years ago, but I tried again recently and absolutely everything was supported. Heck, it's starting to be the case that py2 is not supported anymore..
1. Obsolete. Either explicitly so (e.g. Google API) or abandoned, without even a minor/patch release (initools, 2010) or in some cases a code commit (e.g. pathtools, 2012) for five years or more. I suspect that they will never be Py3, the community will just move on to alternatives.
2. Working hard to bring support (e.g. ansible).
3. Part of the graphite ecosystem. If the base library won't change, none of its ecosystem will.
4. Not on public version control / issue tracking, so who knows (e.g. supervisord)