Most popular Python packages now support Python 3
py3readiness.org
py3readiness.org
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)
Though I would say that it's the stretch to say it might 'need no further changes' if it doesn't work with the latest version of python.
[0] https://github.com/Supervisor/supervisor [1] https://github.com/Supervisor/supervisor/pull/901
[1] https://github.com/Supervisor/supervisor/blob/master/README....
[2] https://github.com/Supervisor/supervisor/labels/python%203
https://github.com/Supervisor/supervisor/blob/master/setup.p...
(It's not getting picked up by pypi because they haven't made a release with the trove classifier yet.)
there is experimental python3 support since 2.2 though.
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.
python3 /usr/bin/ansible $cmd
/edit: there is actually a source for that, go figure: http://docs.ansible.com/ansible/latest/python_3_support.html
There is a fork with Python 3 support: https://github.com/mathiasertl/fabric/
If you use fabtools, I maintain a fork of it for fabric3: https://github.com/develtech/fabtools/tree/fabric3
Also, the fabric author has been making a lot of progress on Fabric 2, which works on Python 3.
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).
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.
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.
1: sets; in this day and age, not having sets as native, stdlib-provided data types is simply unacceptable.[ß]
2: The ease of python's "in" keyword; being able to test for a key in a map (or set!) without any indirection is crucial
ß: granted, IIRC python moved sets into native stdlib types only somewhere in 2.x but better late than never
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.
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'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
} for k := range s1 {
if s2.Contains(k) {
result.Add(k)
}
}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
Btw, in the above code example I have deliberately omitted a trivial optimisation. Let's leave that as an exercise for the reader. :)
return functools.reduce(lambda x,y: x&y, ALL_SETS)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 the answer is to generate the Go, then we should be having human beings focus on the more powerful language controlling that generator.
Built-in set objects were added in Python 2.4:
https://docs.python.org/2/whatsnew/2.4.html#pep-218-built-in...
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.
Sure there is: Python 2 isn't going to change on me again. Python 3 might.
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?
What Scheme implementation do you use that has never broken compatibility and continues to be maintained?
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.
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.
- 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.
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 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.)
Yes, Python 3 was initially a risky endeavor, but in the past couple of years it has cemented its position as the true and only version of Python.
Anyways, the fiasco is over and Python 3 has emerged as the victor, so there really is no use discussing the issue anymore imo.
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'.
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.
- 2008-2012 Python 3 as a language becoming usable
- 2012-2016 Libraries gaining Python 2 compatibility (and dropping 2.4 and below)
- 2016-2020 Applications porting now that most libraries are compatible.
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.
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).
It's the applications and plugins that still need work. Here's the status in Fedora: http://fedora.portingdb.xyz
And history: http://fedora.portingdb.xyz/history/?expand=1
After almost 10 years, the old version is still in use, and the new version isn't even that much better.
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 quite like Python 3, and most of the backward-incompatible changes it introduced.
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.
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.
(Which is a shame, graphite is something that always feels older than it should be.)
Carbon has Python 3 support in Github, it just hasn't been released to pypi yet. https://github.com/graphite-project/carbon/blob/master/setup...
On the side note, glad to know that my small effort (I operate that site) is useful for people I highly respect.
I was very surprised when I saw it on HN front page today.
> Hack allows programmers to use both dynamic typing and static typing. This kind of a type system is called gradual typing...
I wasn't aware of such a type system, and there're many languages which use both:
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.
Interesting.
I haven't used type hints yet.
Side note: Languages like Ruby have had this for a long time. Better late than never, Python!
It has many many python3 crash bugs, especially on the MWS side. I have had an open PR for like a year to fix one of them, and it has been ignored.
This makes me not very hopeful that being on the list means anything.
(I am exclusively python3, but I have to wrestle with this a fair bit still)
Be wary adventurer, while boto3 is super neat and a python3 treat, there unsteady footings beneath your feet (api differences).
Until it does, either boto should be "fixed", or perhaps the MWS piece spun off.
Until it does, either boto should be "fixed", or perhaps the MWS piece spun off.
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).
And you'll save yourself a lot of 2-to-3 fatigue we've all been struggling with.
Tip: there's a Chrome/Firefox extension to redirect all Google results from Python 2 documentation to their corresponding entries in Python 3 docs.
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.
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!"
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.
- 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.
Pick wisely.
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.