Windows could be the first platform to ship Python3 without having ever shipped python2. Total clean slate, perfect opportunity, they could sell it as MS "aligning with the cloud" and offer something special -- if I could start and provision a Windows cloud instance from any python3 repl without having to bother with devops tool (Vagrant, Packer, Ansible and whatnot), I would switch tomorrow.
Better handling of Unicode is inevitably how Python3 kills Python2. Also it's a good reason to have not supported Python2.
Aside from Unicode, I don't like some of the other changes. The overkill on the "one obvious way" bugs me in particular, e.g. the removal of reduce as a core function.
The existence of "one obvious way" isn't set in stone. It depends on context, and it's like the language developers didn't realize that when making their decision.
Moving reduce into functools was more than justified: almost nobody liked it, most people disliked it and if you really want to use if for whatever reason an import is hardly difficult. The decision was made because of the context, not in disregard to it.
The move of reduce to functools makes sense. But it's also inconsistent. map and filter should also be in the functools package tools right alongside partial and reduce. But instead, they're in __builtins__ because .... they're more popular I guess?
I'd actually be OK if map and filter were also in the functools package, but the only way to be consistent while maintaining backwards compatibility is going from the functools package to built-in.
You could quite easily use a process like the one described in the article to select the 'top' 1,000 Python packages, and then scan each of those for occurrences of calls to each of map, filter and reduce, and that way build up a fairly reasonable picture of how commonly each function is used.
While I use reduce a lot, I would guess that even with comprehensions making most uses of map and filter obsolete, that reduce is still the least commonly called of the three.
Better handling of Unicode was also why Python3 adoption has been slow. Upgrading a library or project from Py2 to Py3 is very simple if you already handle bytes vs unicode carefully everywhere in your program.
But for projects that mix unicode and byte strings, and hope for the best (it works okay as long as it is ASCII or UTF8), the upgrade requires substantial work.
Some of the reasons were technical, some were very "we should be more standard."
I agree with the Python3 team, here. Mostly because it's more obvious what Python is doing now. But, it's also cleaner in my opinion.
It makes things harder, sure, 100%. But that's not always a problem or a bad thing. In this case, the more work comes with clarity and less chance for bugs (less edge cases).
Wow. Now that would be something. Writing desktop apps in Python would actually become viable. You'd essentially only have to distribute your source code and dependencies instead of bloated binaries containing a Python interpreter.
I've found, building Python binaries for Windows, the interpreter and standard library takes up a negligible amount of space (a few MB). Most of the space was taken up by dependencies anyway, e.g. wxPython something like 15 MB! (I think I got it down to 7 MB using UPX to compress the DLLs.)
UPX is not magic -- it compresses machine code and makes sure unpacking code is run every time the executable is loaded. So if you only care about the size of the binaries in transit, don't use UPX, just use eg NSIS with lzma compression. You'll probably end up with a smaller package this way.
People already do this - e.g. the original bittorrent app was written in Python. Many users on Windows didn't notice - if you package it correctly it works just like any other app.
Have always hated the half-ass integration Windows has. Half the stuff does not work as it should or is broken, no one tests on Windows and I doubt they will start now. Never been fun doing anything with non-MS stuff on Windows. I doubt it ever will be. As for writing anything, I don't know why I would bother with non-MS stuff on Windows platform, it usually does not come out well. C# is a great language and Visual Studio is great for using it. And it's free.
> Have always hated the half-ass integration Windows has. Half the stuff does not work as it should or is broken, no one tests on Windows and I doubt they will start now.
What? Python has been one of the significant exceptions on this front because Enthought actually shipped a product which was expected to work on Windows. Python also goes out of its way to make sure that things work in sane ways even when Windows has no real equivalent.
I also suspect this is one of the reasons for Python's ascendancy over other scripting languages. By being one of the few scripting languages that runs decently on Windows, you gain an automatic user population advantage.
Maybe I'm dreaming this... Trying to install some Python package on Windows 8.1 and 'the usual' stuff didn't work.
I'm a python newb and maybe I wasn't doing something right. I'm more used to Linux/Perl and doing "Perl -M CPAN ..." which just works. 'pip ...' just didn't.
I was not left with the feeling that Python ran as well on Windows as on Linux.
pip is unfortunately a a bit hit and miss on Windows. The (IMO) 'correct' way to install package on windows is to first install Anaconda Python (https://www.continuum.io/downloads) and then:
0) Check if the package came preinstalled with Anaconda
It definitely doesn't. People writing Python packages make reasonable assumptions like that you've got a POSIX command line, a UTF-8-compatible terminal, and a C compiler that's compatible with the Python development headers. On Windows, you probably don't.
It'd be nice if Windows made an effort to provide a sane environment for Python, because the Python devs certainly aren't doing anything to make things sane on Windows.
Ubuntu server VM in vbox with shared folders works better than anything I've tried to get things working well I native Windows. Sure it's not impossible, but the tax isn't worth it IMO.
You need to manually add the directory containing pip and other tools to the path.
If it is not, you can often do python -mpip install xxxxx
And you're right there are some gotchas - for instance pip install -U pip won't work to update pip itself as on Windows a program can't seem to overwrite it's own executable.
AFAIK (and I have dozens of virtualenvs running on a Windows box) you can upgrade pip, it's just one of a handful of packages that throws an error at the end because it was unable to delete the folder it created during the install process. The upgrade works, it just looks like it doesn't. But maybe that's only true inside a virtualenv.
I'm under the (quite possibly mistaken memory) impression that the Enthought guys (ScipPy and NumPy) hid installation stuff behind a GUI for Windows people.
I could be wrong as it's been a long time since I helped anybody with that on Windows.
That hasn't been my experience. It depends on the kind of app you are writing. Are you writing a desktop UI app or game? Yes, C# apps tend to be better and you can use XAML or whatever. But I've written a bunch of build tools and network apps that work flawlessly on Windows and Unix family systems. Not everyone wants to switch to Microsoft tooling for their entire project just to support one more platform.
By comparison, C# tooling makes some things really difficult on Unix-like systems. For example, try spawning a process and redirecting file #3 to a pipe. I honestly do not know how to do that in C#. Python is fantastic at being cross-platform glue.
I've never really had issues with using Python 3 on Windows, as for .NET you can always give IronPython a shot as well, though it has yet to make the leap to "3" in a while, at least last I checked, same with Jython.
It still blows my mind how badly the Python and Perl developers misunderstood their languages' roles. Many developers viewed them as Unix infrastructure like C, sed, and awk: a stable foundation upon which to build long-lasting programs. But the core devs got bored and decided to either break most things for very minor improvements (Python), or break everything to provide all things to all people (Perl).
The Perl folks eventually admitted that version 6 was a separate language; we'll see how that turns out. The Python ones can't make the same move, since version 3 offers no major benefits/changes over version 2, so they simply have to continue the beatings until... everyone moves to version 3. What a colossal waste of time!
The Python developers built the language they wanted to build. They were never obligated to do anything else. They are largely unpaid volunteers working on open-source software, and you're complaining that they're wasting... who's time are they wasting, again?
Here we go with this absurd argument again: "They're giving it away for free, so they can do whatever they want, and you can't complain." Sure, we're all free to develop software and dump it on the internet for everyone to use. Many people do, and most of it is useless and ignored. However people who want others to use their software, as I think the Python devs do, need to provide some value to their users. The value they get in return is less concrete, but it's there: reputation boosts, job opportunities, warm feelings from sharing, license to verbally abuse people on mailing lists.
Developers aren't obligated to please their users in exactly the same way that users aren't obligated to use their software. Just because there's no money, it doesn't mean there's no transaction, and popular free software is based on benefits to both parties.
If they want to help Python users, they should improve performance and add backward-compatible features. If they want to have fun experimenting with programming languages, they should change "Python's" syntax and semantics whenever they want. Either would be better than the current approach.
Well 1) it took us 5 years to get those features, 3.0 just broke shit and ran slowly for no discernible benefit to the end user.
And 2) I know of no reason those features couldn't be implemented in Python2 other than "we don't want to, because otherwise few people will ever upgrade to 3"
That doesn't actually help the "py3k was a good idea" argument. 3.3 came out 4 years after 3.0. 4 years to become a reasonable choice is kind of pathetic, especially given the fact that python2 was put into bugfix-only mode 2 years after the 3.0 release
I think that's backwards. The developers of unix packaging systems (the Debian packagers in particular) misunderstood the roles of these languages. Writing unix-like tools is a small niche, Python is exceedingly useful outside that niche, and Python 3 is necessary for a lot of very useful things that developers build. Java has been extraordinarily successful despite having hardly any system tools written in it, and I think part of that's the sheer good luck (due to accidents of licensing history) of the likes of Debian not trying to integrate Java deeply into their OS; Python and Perl would be much better off had the same approach been followed.
I think I was unclear about my main point. Python and Perl have many applications outside Unix tooling, but then again so does C. Both sort of started out as "better shell script," and both were seen as such, but they were also seen as stable foundations for serious, long-lived software.
You can build stuff on top of C, Fortran, POSIX, etc. in 2016, and be pretty confident that it will still work with their 2026 versions. That's not valuable if your slapping together an MVP that no one will care about and will die in a few months, but it's incredibly valuable for developing big, complicated software. Or for little personal utilities you want to write once, then not have to maintain. Perl and Python moved away from that longevity, each in its own way. Maybe that will make them better suited to a world of continuous Cloud-based churn, but there's more to life than that.
I find the conservatism of C, Fortran and POSIX has made them almost useless for developing big, complicated software. Compatibility is important but so is evolution. Certainly I think the deprecation cycle for Python is not overly short.
Is anybody surprised by this? Everybody knew the transition was going to take a long time, and that it would be a gradual process. It may be that it's actually been even slower and more gradual than people expected, but by and large everything seems to be proceeding nicely.
And actually, that may be a great sign of a healthy, mature community. Python has reached and held a level of maturity at which change happens slowly and methodically.
In fact, Google Trends [1] seems to indicate that, too. After what was probably an initial stomach-drop of broken compatibility, python is picking up a lot of new developers again.
Haha maybe it's just the HN effect but I was very surprised to see Java at ~20%, having increased ~5% over the last year (I guess Android is Java, though).
That, and the facts that Rust is ahead of Go, and that the two of them sit at only ~0.4% usage combined.
Yeah, some of that stuff just doesn't seem realistic. Look at some of the languages that are ahead of Scala for example, and note that Clojure isn't even in the top 50 right now. That seems like a real stretch to me.
I mean, you have D WAY ahead of Clojure? Seriously? Not to knock D, or @walterbright, but does anybody buy that D has significantly more industry adoption than Clojure does?
Hey, maybe I'm wrong, or maybe it is the "HN effect", but that's why I say that I consider the Tiobe Index "suspect". For the top 10 or so, it's probably a decent approximation, but beyond that I think it's highly, highly questionable.
You might need to rebase your assumptions. Big banking, big governments, big everything is big and use a lot of Java I guess.
I don't get what you're saying. I didn't say anything about Java being on top, except to specifically say that Tiobe is probably a reasonable approximation near the top. It's the "long tail" that I think gets especially hinky.
I guess I misread you as supporting andrewstuart2 and I'm sorry for that.
I have however not downvoted you, so if anyone did it was somebody else.
(btw: seems I've crossed some magical threshold and people seems to be upvoting almost anything I write now. Might be time to create a new account, again :-P)
> Not to knock D, or @walterbright, but does anybody buy that D has significantly more industry adoption than Clojure does?
Yes. D has a very clear use case and makes sense for it (and didn't have a lot of competition there until the rise of Rust). Clojure has a lot of (often vocal) fans but in practice the compelling case over the more popular Scala just isn't there - at least that's what I've seen in multiple-languages-but-JVM shops (biased by the fact that I'm a Scala programmer myself). You'd get a few Clojure fans who would talk the language up, but nothing in actual use.
I dunno... I never hear of anybody using "D" other than Facebook. In fact, I never hear D mentioned at all except here on HN. OTOH, I know people actually using Clojure in industry. There also seems to be more Clojure activity on Github, which I take as something of a proxy for interest in the language.
Of course, my view may be tainted by the fact that I live very near Relevance and know and interact with a few of the Relevance people.
Anyway, this isn't specifically about D or Clojure. I just generally think that the long tail of the Tiobe index looks pretty fishy at times.
Though Clojure fans like various aspects of the language, Clojure's use case is being a Java replacement (or else integrating very well with Java) in non-free-software enterprise shops, specifically for when you need multithreading while working on large amounts of data.
And for exactly that use case, there is industry adoption.
But Scala has better Java integration, and is very good at working with large amounts of data. (Also the space where you need multithreading but not distribution is extremely narrow, and when you go distributed Spark is fantastic).
I can actually see that as being real. There is a lot of legacy code out there (especially in larger corporations) and, while these languages are rarely featured in the news, many people are required to use them at work.
I know someone whose job is to maintain COBOL code for the State of Texas. Government organizations have even more difficulty upgrading IT infrastructure than large corporations do, and there are a lot more of them that can survive a lot longer than there are large corporations.
It's the defacto language to learn at the university level. And many large companies use it on the backend (Google and Amazon). Small companies who outsource to cheap labor overseas will probably have their work done in Java on the server-side (though this is changing).
Go may be recognized in the Valley. But it doesn't have much usage outside the startup world (and Google). And only a portion of startups here use it too.
Swift is the de-facto future replacement of Objective-C for Apple ecosystem. It's got a while to go yet - a stable ABI for one - but once that happens (with Swift 3 later this year) then you'll start to see it take off. Plus, since it was open sourced it has been made to run on Linux and Raspberry Pi devices and has attracted a hugely varied and vocal community.
I don't think anyone expected a lengthy transition at the onset of the version 3 release. It's taken a long time and the 2.X releases that have come along since have helped make the transition easier by showing developers some of the benefits from version 3 releases.
I was on the "Python 3000" mailing list while it was being planned, and the prevailing attitude seemed to be "it'll probably take 5 years before the community moves to Python 3". (That's paraphrased and not a direct quote, though I saw people say that sort of thing almost word for word a few times.)
This was optimistic, but at least we see that the community is indeed gradually moving to Python 3, even if it's taking a few more years.
Technically the goal was a majority of new projects started using Python 3 in 5 years. Regardless, everyone knew it would take several years to reach a point like this.
I switched from Perl to Python at version 3.4, and while it might be popular for people already invested in Python 2 to downplay the syntactic improvements, they were a big deal in convincing me to switch to Python as my go-to infrastructure language.
This is true, but currently, most of developers of Python acknowledge some mistakes in the Python 3 transition. Specifically the fact that such an abrupt compatibility break was underestimated. And that's why Python 4 won't break compatibility with Python 3.
In any case, I'm very happy to see the Python 3 transition moving forward. And let's hope this does not happen again.
Python's back-porting of 3.x features caused Python 3 adoption to take even longer (no pain, no gain). But, I think this was a necessary evil, because if PSF had forced everyone with a "upgrade or perish" attitude, I think many would have abandoned Python.
Pretty sure there would be a fork. Many large tech companies (Google, Dropbox for two) are deeply invested in Python 2, and some of us already have some modifications to CPython. Python 2 is Too Big to Fail.
I disagree. The main thing holding back Python 3 use has been library support. Library developers do no want to maintain two separate codebases, so it is very important that a certain subset of the language works under both 2 and 3. The backported features in Python 2 and some backwards compatibility added to Python 3 in recent years have really helped with that.
If Python Software Foundation would create a serious initiative to double (or more) the speed of cPython, specifically for Python 3.5+, I'd donate at least $100, and I'm sure there are a vast many other individuals (and companies) that would donate as well. In the meantime, my Python-related donations go to Django.
I think that speed can't be treated like a niche feature (e.g., via PyPy, Cython, etc.) any longer; not with tools like Go out there.
There's actually been a lot of work the past few months to speed up CPython 3.6. I expect there will be more news coming out of PyCon US on stuff related to this.
I wonder why Dropbox is focusing Pyston (https://github.com/dropbox/pyston) only on 2.7 atm. With PyPy supporting 2.7 very well, it'd seem a greater benefit to the community to target 3.
That said, I'm sure there are specific things Dropbox needs to solve for 2.7 which PyPy doesn't do.
Pyston has a goal of full C-API compatibility, unlike PyPy. Dropbox are almost certainly not trying to create the greatest benefit for the community, but rather the greatest benefit for themselves, and they have huge amounts of Python 2 code in production. As such, Python 2.7 with full C-API compatibility makes sense for them to focus on.
The Python Software Foundation is about promoting Python and has nothing to do with coding. It does not deserve any credit whatsoever for the existing CPython codebase. All coding is done by individuals because they feel like it.
Interesting. Whilst it is slightly embarrassing how long it's taken, recently I feel that Python 3 conversion is gaining critical mass, and I now hope / expect these adoption lines to go non-linear in the coming year or so...
fabric is that lone holdout that went against all conventional wisdom and decided on a complete rewrite when a small few simple changes would have been enough. fabric's developer has made promises over the last few years for their rewrite to be beta ready and it's nowhere yet.
I say that with all the appreciation in the world for the work that went into original fabric, which is a wonderful tool. Criticism may be harsh but it's not inaccurate. What's amazing is that the forks to bring fabric to python3 haven't really caught on and I think that's partly because fabric is something you do not use inside your application. It's used in deploy and configuration scripts. It being python 2 hasn't been a problem for most people since most distros and platforms ship with python 2 support. It's just that the people who want to stop writing python 2 for everything including their deploy scripts who are the most vocal and it's not a big enough group.
The fabric dev basically has until platforms start to abandon python 2, and who knows when that will be, so maybe they have forever for their great rewrite.
> Warning...While fully usable, Invoke is still pre-1.0 software and has no backwards compatibility guarantees until the 1.0 release occurs! Please make sure to read the changelog carefully anytime you upgrade!
And if I recall, it's only half of fabric's feature set.
I am skeptical of the link entirely. It says gevent does not support Python 3, yet if you look at the PyPI page [0], it says "Gevent runs on Python >= 2.6, Python >= 3.3, or PyPy >= 4.0.1 (but not PyPy3)". Is the lack of PyPy3 really worth saying Gevent doesn't run on Python 3 (the language, not CPython specifically)? Perhaps this website is out-of-date in some respects, and helps contribute to the confusion.
On an unrelated note, a lot of people I have encountered claim Gevent as the reason they haven't switched yet. For now I guess such claims are shaky, assuming the PyPI page isn't false advertising.
pyreadiness.org uses https://github.com/brettcannon/caniusepython3 to figure out if a project supported Python 3. The issue is that gevent doesn't specify their support through a trove classifier on PyPI. There is a hand curated overrides file, though, that I just edited to list as supported (https://github.com/brettcannon/caniusepython3/blob/master/ca...). I don't know how often py3readiness.org updates, but the issue should resolve itself the next time they update the data on the site.
This is actually very informative. Combined with mangeletti's answer, it does explain the discrepancy. Thank you for sharing this. It's interesting (and also sad) that this tool has evolved up to version 3.3.0 over the years since we had Python 3.0.
Their PyPI page explicitly says otherwise: https://pypi.python.org/pypi/supervisor . It looks like there is support in their repository but not in any official release (yet).
To add to this article, here is the Python 3 Wall of Superpowers. It is a list of the most popular packages on PyPI, and shows if they support Python 3.
meh, there isn't (still) any reason to really jump onboard python 3, 2.7 is good enough for me
the only real selling point is that strings are unicode by default. Unless I'm missing something python 3 just doesn't really seem to be worth the effort, yet.
Very few people still program in 77 and only if they really have to. Everybody who has a choice has moved on to at least Fortran 90 and you won't find anybody seriously arguing that Fortran 90 isn't a massive improvement over 77.
They weren't saying that in 1993. At least, not as I recall from the time. It took a while for that consensus to build.
I believe that many of not most Python 3.5 users consider it a massive improvement over Python 2.7. My examples come from the core developers, so is highly suspect to bias.
I recently decided to make an effort and use python 3.5 for a couple of new projects and I've so far found zero things that I consider a practical improvement over doing the same thing in 2.7. Now it's obviously not worse than 2.7, but saying that the new thing is just not worse than the old thing is hardly a great selling point.
Language level async will probably be a reason to switch once there is a bit more support for it and I have a project that really needs it. Same with type hinting, once the tools and libraries are there it might be useful. But as of today and the work I do (mainly data analysis and modelling making heavy use of numpy/scipy and friends) I have yet to find anything in 3.5 that in itself would be a reason for me to switch.
Personally I quite like Pyhton 3, but the original comparison was flawed simply because with Fortran 77 you can just take your 30-40 years code recompile it with a new compiler and in 99% of cases will work.
While with Pyhton 2 to Python 3 there is usually a non trivial amount of work you need to put into migrating an old codebase.
> meh, there isn't (still) any reason to really jump onboard python 3, 2.7 is good enough for me
You're siding with a shrinking ecosystem (Python 2) over a growing ecosystem. Depending on your use case, this could range from inconsequential to inconvenient to disastrous.
If you have an existing codebase in Python 2, then perhaps the conversion to 3 isn't worth the effort. But if you're developing new software, the question is why not make the minimal investment to make your work compatible with the future of the language? When I see a new library and the author couldn't be bothered to adopt Python 3, it's a big red flag.
My main concern that's stopping me from using Python 3 for all new projects is the risk of being in the middle of the project, and finding yourself needing a library only to find out that it only works on Python 2.
Couple that with 2.7 being good enough just makes the situation "worse" for 3.
I was a staunch Python 3 supporter until I encountered such a thing. I avoid Python 3 now because I don't want to be forced to make a decision between writing the requisite library myself (a huge undertaking), abandoning the project entirely, or rewriting everything into Python 2 again. Better to just start with Python 2 in the first place.
If you're using any language other than C you'll always occasionally find yourself in the situation of "there's this useful library that only exists in C". But for many languages the library ecosystem is large enough, and the language better by C than enough, for the tradeoff to be worth it.
Also that's kind of what this post is about. Pretty soon there'll be a bigger risk of finding that some library you want is Python3-only than finding that some library you want is Python2-only.
Even when writing C you still occasionally find yourself in the situation of "there's this useful library that only exists in Java". There's no language that can directly use every single specialized niche library written by a domain expert.
A head-to-head comparison of 1.6 against 2.7 and 2.7 against 3.5 will quickly make it clear it's not the same thing. Python 2.7 is not only "good enough" by itself, there's also no compelling reason to move to 3. Bad incentives from both directions. I wouldn't necessarily say Py3 is inferior as the author wondered, it's just insufficiently superior, and not having Library X available for years is just an additional thorn in the side of people attracted to Python in the first place for the ability to get stuff done that's still readable years later. Py3 really just doesn't offer anything killer for tons of programmers. Things that would have appealed to me: massive performance increases, or a worthwhile standard library improvement, or an impressive syntax upgrade, and only by migrating can you get those nice things... Some other people get hot for static typing too, so I guess they might finally be happy.
This always bugged me about Python:
>>> exit
Use exit() or Ctrl-D (i.e. EOF) to exit
You know god damn well what I mean Python, so just do it instead of nitpicking me. Python 3 doesn't fix this, and makes it worse. Case in point (using a web repl as I'm not at a computer with Py3 on it at the moment):
>>> range 4
Traceback (most recent call last):
File "python", line 1
range 4
^
SyntaxError: unexpected EOF while parsing
Okay, reasonable enough...
>>> print 4
Traceback (most recent call last):
File "python", line 1
print 4
^
SyntaxError: Missing parentheses in call to 'print'
You know god damn well what I mean, Python. You know what you could have done to have your precious sys.stdout.write(repr(arg) + "\n"[, extras]) as a smaller replaceable built-in function that wouldn't break everyone and make them sad? Called it Echo. Puts. Print3. Println. Nope, just breaking the most basic things, for no real good reason since it's not like Python is going the Lisp route of killing the distinction between statement/expression in favor of everything being an expression.
> You know god damn well what I mean Python, so just do it instead of nitpicking me
Python has no idea that's what you mean.
>>> repr(exit)
'Use exit() or Ctrl-D (i.e. EOF) to exit'
It's just the exit function has a __repr__ that returns that. Why the hell would Python make just 'exit' exit the interpreter? That's unlike anything else in the language.
>>> print 4
SyntaxError: Missing parentheses in call to 'print'
This is a special case to help with the transition from 'print' to 'print()'. Should 'i 1' have a message saying a parenthesis is missing? I could mean 'i + 1', or 'i, 1'.
Honestly after using Scala for 3 or 4 years I couldn't go back to a language that doesn't allow an "object method argument" style of doing method calls. Superficial perhaps, but it can make code so much more readable.
Sorry I hit a nerve. You insisted it 'wasn't the same' but didn't give an example.
If you don't need what Py2 provides, I don't know why it wouldn't be 'good enough'. And since I built a lot of complex stuff in Py1, I can't imagine why anyone would think it is not good enough for building complex stuff.
When I moved to Py3, it was the thing that got me most often. It was annoying. But three things changed to make that less annoying:
1. I got used to it, fairly quickly. That made me care less.
2. I used print-statement debugging less, and unit tests more. This was a good thing generally.
3. For those times when I did need print to debug, I found I could drop in pprint:
import pprint
print = pprint.pprint
which is very useful. That won me over.
I've rarely needed naked print to do anything but quick testing and debugging (because by the time I have a command line script, I want at least to have a -q option, so I need to run output through some kind of proxy function). The standard arguments for print() (i.e. composability, extra arguments), I've not needed, but the ability to replace it, I rely on totally now.
python prompt isn't much of a development shell, use ipython
it lets you type exit and if you turn on autocall (%autocall) it lets you run functions without parens(hint this isn't valid python).
print isn't a statement in python 3 and range was never a statement
More consistent division and integer/long handling, but yeah it's minor except for the strings/bytes thing. The thing is the only "effort" is in fixing strings/bytes issues - but the cases where you have those issues are precisely the cases where what python 3 does is so important! If you're not doing any string/bytes stuff then upgrading to python 3 is a triviality. If you are writing code that mixes strings and bytes then you need to clarify what you're doing (if you want your code to ever be maintainable), and python 3 will give you a great deal of help with that.
When will support stop for Python 2.7? Once it stops being patched/supported, it represents a security risk (in my book).
Additionally, eventually new libraries will also stop supporting 2.7, with the same issues as well as making development harder (or not as easy as your peers/competitors)
The Python development team will cease supporting Python 2.7 in 2020. After that you will have to buy support from someone like Red Hat or Continuum Analytics.
Open source support is not a centrally governed entity. FOSS support for Python 2.7 will continue after 2020. You will certainly still have the option of paying someone for support.
Sure, there's a chance people will pick up the mantle and essentially fork Python 2.7 to do unofficial bugfix releases past 2020; as you pointed out, it's open source and people can do what they want. But my point is there is no guarantee that will happen, nor that those unofficial releases will be of quality either. RH and Continuum on the other hand will most likely have financial incentives to make sure any maintenance they do meets the needs of their paying customers and thus are of a certain level of quality. IOW one possible future is more of a certain than the other.
It will have taken 8 years for Python3 supporting uploads to have outpaced Python2. If that's not lack of enthusiasm, I don't know what is. This is really a pitiful display.
It's not a surprise though. This all stems back to the original reasons why Python3 was a bad idea. Some things to keep in mind regarding Python2/3.
- Python3 is pure technical churn, nothing there is true technical innovation. They simply mixed the pot to their liking. Unicode is supported in Python2.
- It is slower than Python2 for most people. Though there are crafty arguments out there that it's a wash. It's really not.
- CPython3 was adopted to benefit the core development team, to make it easier to maintain. Not the community on the whole. The community has paid the price by doing a lot of unnecessary ports.
- CPython3 was deliberately created to not support Python2 code even though modern VMs can easily support this. The CLR is a great example. They did it this way for their good, not for the community.
- In most things in life, you'd always want to be using the latest supported version. That isn't the case here. It may still effectively "fail" with a permanent split. This migration is not even close to being completely in the books and won't be for another 10 to 20 years. So why punish yourself moving before it's in your best interests. The syntactic differences are so slight, it's extremely easy to switch to Python3 if it ever truly reaches Python's momentum (this article does not convey momentum holistically, that includes package downloads and the majority of employers using 3).
- Related to the bullet above, almost all job opportunities are still Python2.
- The ecosystem can't keep up, PyPy is still only production-ready on Python2. Python 3.2 support is essentially experimental by comparison.
- Many changes and additions are being made and they aren't being vetted by the larger community. No significant userbase for Python3 has created this situation. Mistakes are being made and no one is around to speak up because the core devs don't care.
- Python3 is feature-soup. There is now a new 4th and possibly 5th string formatting method in 3.6 incoming. Really jumped the shark on that one. See Mark Lutz's great insight on this topic and more.[0]
- Downloads are still dramatically in Python2's favor, to this day. Judging from downloads, there's a ~10% community userate of Python3.
- The bullet above means that the Python3 packages you do use are far less vetted and tested than the Python2 equivalent.
- CPython3 was slopped together. The initial 3.0 release was mostly pure Python in effort to get it out the door. Many parts of the standard library that are written in C are slower than the modules used in the CPython 2.7 counterpart, to this day. It was not and is not being tested. The users are not there to test it either.
- Community trust has been broken, I'm not sure anyone really believes another big break isn't incoming regardless of statements to the contrary. The core dev team is going to do what they want and you're going to like it, period.
- Python3 zealots have done a lot of harm by not accepting valid criticism, and aggressively attacking those who do what is in their best interests (which we should all do, this should not just apply to the CPython core devs), and continue using Python2 all these years. Watch for downvotes instead of countering my points.
- The 2020 date is a just a big political stunt and scare tactic. Code will continue working after 2020. As noted, it works better in CPython2 and PyPy today, and likely will in 2021 as well.
- Python3 lives off of and is pushed by PSF propaganda. No way around it as there is no innovation involved. Which is what should determine if new technologies are adopted or not.
- Usually when people make mistakes, such as Python3's existence, or the inability to mix Python2 and 3 code in the same VM- they go back and fix them. That has not happened with CPython3.
- Even back in 2014 projects such as Pyston from GvR's employer (Dropbox), were Python(2)-only. It's still Python2 today, which says it all.
All that said about this trainwreck, I'm in favor of getting back to a single major version of Python for the community. I'm using 3.5 for a single project myself but I will still plainly state the truth about the Python3 transition. It was a bad idea, for all the wrong reasons to benefit a rogue band of developers who believe since you aren't paying them- you as a community do not matter and should shutup and get to porting.
I love Python but will eagerly embrace Pythonic language alternatives as more are released. In particular, I'd love to see a Pythonic Erlang variety similar to Elixir. Or better yet, just a concise, minimum featured version of Python without all the extra. Picking 1 string formatting method would suffice, the basics but done well, stable in feature-set like Go and compiled. Something similar to a Pythonic Lua would suit me and would be the ideal case for a Python-reboot. Making it a subset of Python2 would make a lot of sense.
Lesson learned and bottom line is that we should overthrow all BDFLs.
That "rogue band of developers" consists of the Python core committers - the people who have been volunteering their time and energy for years to bring you Python in the first place.
"nothing there is true technical innovation" - There is so much innovation in 3.x, I could write for an hour and not list everything.
"CPython3 was slopped together" - From my perspective, most of it has been extremely well thought out. That is not to say that everything turned out perfect. What software project on this scale has NOT has things that, in retrospect, turned out to be mistakes? Hindsight is 20/20.
It's like you are looking at all the many, many, many aspects of the change from Python from 2 to 3, positive and negative, and only seeing the bad things. If that's your mindset, I feel really sorry for you.
Probably my favorite single thing, which is really a collection of things, is that Python 3 makes many classes of previously obscure bugs more immediate and obvious. hasattr() no longer masks exceptions; object comparisons without ordering methods defined will raise a TypeError, instead of being based on object ID (which is a race condition); two exceptions raised in succession will give you two stack traces, instead of just the last one. These and similar changes make bugs more likely to be found and fixed quickly, during development, instead of lurking until they're deployed. More info here: http://migrateup.com/main-difference-python-3/
That said, it depends on what you mean by "innovation". To me the above is a worthwhile improvement, and more important than (say) asyncio. It's also a "nice to have", in the exact same sense that 2.7's features are a nice-to-have compared to what's in 2.5. At the end of the day, if you want to continue coding in 2.7, that's what you should do.
Small improvements. Don't get me wrong: the things you listed are all nice and useful (+1 for keeping more than one stack trace). But I don't think anyone's definitions of "innovation" includes fixing exception reporting and changing the semantics of object comparisons. No disrespect intended but your earlier statement was clearly meant to convey what a boatload of innovation there was in Python3, and your response to the request for an example just bolsters the counter claim, frankly.
Not without breaking backwards compatibility. Although I guess they could have done a slower transition, with 2.8 giving depreciated warnings by default (with a flag to make them errors), 2.9 giving errors by default (with a flag to make them warnings) and 2.10 finally breaking backwards compatibility.
I tried to outline a bunch of things at http://www.snarky.ca/how-to-pitch-python-3-to-management . But what one person considers an "innovation" while another considers just something "nice to have" is going to vary from person to person, problem to problem.
I'm confused when you say the syntactic differences between the two are slight, and then follow it up with "but all the jobs are in Python2".
If the syntax differences really are that slight, wouldn't the type of python you're fluent in not matter? Feels like you're saying something like, the differences between the two languages is like Australian versus American English, but that all the jobs are in American English?
Not sure why you are being downvoted, you argued your case well.
I would say, really fundamentally python is an extremely 'opinionated' language driven by an extremely 'opinionated' BDFL... this isn't necessarily a bad thing, just saying given the guiding principles of the language it really shouldnt be so shocking that a lot of work has gone into rolling out a 'pythonic' version of python that doesnt bring all that much to the table that isnt subjective...
Downvote all you like, but if you read this and don't feel sting from at least a few of these points, you're fooling yourself.
There is now a new 4th and possibly 5th string formatting method in 3.6 incoming
/me lets out epic sigh~
FFS. Yes, indeed.
For what it's worth, you are not alone in your irritation at the situation.
...but what can we tangibly do?
The best bet is still to write new code in python3, and slowly depreciate python2 code and replace it whole scale with new code either in python3 or 'more appropriate language x here'.
A new python-like compiled language which was a subset of python2 without the standard library would be a welcome breath of fresh air. We can certainly daydream...
- Call it PythonCore instead of Python4. Avoids any possible trademark issues if it does take off, and the semblance between "four" and "core" rings nicely.
- PythonCore should be just what we the people need, rather than feature soup with community promise of compatibility like Go. Python2 subset, removing some extraneous features and removing the std lib.
- One could start with CPython 2.7.11 and disable all the keyword features that weren't wanted or strictly needed. I would go about this by asking the guys behind PyCoders Weekly would send out a survey asking Python developers a series of questions on what to keep. Combined with surveying a few recognized Python experts (not Guido). I think at this point in Python history, we know what we definitely do and do not need.
- As well, ditching the standard library and putting it all as strictly package imports. Forcing it all to compete with other solutions on equal footing but still being there for reference. That would be the basis of the new 'PythonCore' and give people something they could rely on as a stable, unchanging featureset for years. New features would be imported, extremely rarely added to the core.
- This would be declared as a continuation of Python2. Though clearly not supporting all existing code, it may require little more than changing your string formatting in the end.
- After this, two main efforts would be involved. Initially ditching the CPython 2.7.11 base implementation for a compiled alternative. Nuitka would be an interesting solution to look really hard at, PythonCore may be the language that Nuitka has been waiting for to really shine. This shouldn't take long to get up and running considering Nuitka is already working and should compile a strict Python2 subset just as well as it does the entire language today.
- The second and I think most important, and time consuming effort would be in duplicating the success of NPM for PythonCore. This would make or break it.
- You could do the same for a Python3 subset but I think what many, many folks (and businesses) want is some option to continue on Python2. This would be a way forward that could be supported relatively easily as the supported core would always remain small. But it still retains the POSIX oriented nature that we all love about Python rather than the Microsoft/JVM/CLR unicode by default decision with Python3. I like many Python2 users, stick to retro OSes without a text / binary distinction. If it was good enough for Kernigan and Richie, it was good enough for Joe Ossanna, it was good enough for Robert Pike. Well, it's good enough for me.
- In sum, influences would be Lua, Nuitka, CPython2.7, NPM.
Believe it or not, you don't even have to change your workflow to try out python 3. If you're on a Red Hat/Ubuntu-based system just add a '3' to everything (python3, pip3, pdb3, etc)
I've been bitten by Poe's Law[1], despite the winky. Blast!
Edit: Really though, it's a problem of apathy. I'm supposed to care about python 3? Why? When I type "python" on the command line (and everyone else that doesn't care, which is most every "filthy casual", right?), I--and everyone else with a default install of Ubuntu and CentOS/RedHat--gets python 2. Fix that, and overnight you'll have massive python 3 uptake.
In fact, you're suggesting I set myself up to be stuck with the problem Maven is in, which is that everyone has an "m2" repository even though they're onto Maven 3. I'm supposed to hardcode "3" into everything? C'mon.
If you're an application developer rather than a library developer then yeah that may well have been the correct decision. But if you intend to maintain your application for more than 3 months then it's time to switch to Python 3 now.
I honestly can't tell if you are joking or think that using "Python 4" as the name of such a thing is a good idea (no way will the Python Software Foundation let you use their trademark, so if you are serious, you are just setting yourself up for hassles).
