r/Python • u/upofadown • May 26 '14
Python 3 is killing Python
https://medium.com/@deliciousrobots/5d2ad703365d/16
u/nanogyth May 26 '14
I understand why this is painful for library writers. But if you're just writing an app, why would it matter if you froze on a particular version? 2.7 being out of development and under maintenance seems ideal.
3
u/ggtsu_00 May 26 '14
It sucks. I am forced to write targeting 2.7 because of long tail dependencies on extensions that are non trivial ports. However, I can't use some modern libraries like adding a websocket server to my app because the websocket server libraries are 3.x only or depends on gevent (incompatible with windows)
14
u/flying-sheep May 26 '14
this article is bad and misleading.
Python 3 has some tiny, incremental improvements over Python 2
wrong, it now has multiple hugely useful stdlib libraries that aren’t in python 2 (enums, asyncio, multiple dispatch, …), many performance improvements, better internal string representation minimizing memory footprint, has fixed the broken string handling of python 2 that permitted many errors to propagate unnoticed.
Yes, a lot of libraries have been ported, but ten times as many have not
[citation needed]. i highly doubt this. e.g. the wall of superpowers and PyPI indicate this is no longer true:
[Writing Python 3 applications] is obviously not popular, because if it was, we’d have a lot of Python 3 apps in production, and much of the long tail of Python 2 libraries would be ported. Neither of those things is true. People either continue to write software in Python 2 or they pick another language that did not shoot itself in the face.
false: people do write python 3 applications, and don’t port their python 2 ones, because they are applications, not libraries, and don’t need porting to be useful for everyone.
You might as well ask someone to port their entire codebase to Ruby. Except, that would be cheaper. Now, if you are going to have to rewrite your software either way, would you choose Python 3? No.
the author totally pulled that out of his ass: why the fuck would it be cheaper? also ruby is less popular than python outside of webdev, therefore has less libraries than python, so that perceived problem of the author would be even bigger.
simpler FFI
like CFFI (which is supported on python 2 and 3)?
One solution is to fork Python 2.7
then fucking do it instead of being the 300th person suggesting it. do it, and have fun being ignored. or maybe not, who knows?
reviving Python 2 is so obviously the correct thing to do
no, the obvious solution is of course to stop whining, roll up your sleeves and port shit. i’d do it if i’d have ever perveived that problem, but mysteriously i don’t miss any libraries on python 3.
The community will, by that time, have shrunk dramatically, and lost its former glory. See: Perl
perl 6 is a community driven project alongside the continued, centralized development of perl 5. the developers of python 2 have stopped developing it years ago and moved on to python 3. totally different situation.
bottom line: what did that guy smoke to get to those totally unrealistic conclusions?
9
u/mitsuhiko Flask Creator May 27 '14
There are 44000 python 2 libraries. The version 2 tag js not used as it did not exist until the python 3 tag was added. Less than 10% of libraries are ported.
2
u/fuzz3289 May 27 '14
My favorite part is how he thinks Guido is an idiot. Guido explains very simply why python 3 had to happen. Why do people without basic language theory comprehension think they know better?
2
u/asthasr May 29 '14
Guido has made some weird decisions. His dislike of functional idioms (
map,filter,reduce, and anonymous functions in particular) is really odd, and working with Python after working in Ruby often feels subtly wrong, even though I actually prefer Python intellectually.1
u/pje May 27 '14
it now has multiple hugely useful stdlib libraries that aren’t in python 2 (enums, asyncio, multiple dispatch, …),
Wait, what?
2
u/flying-sheep May 27 '14
1
u/pje May 28 '14
That's single dispatch. Says so right in the name, even.
0
5
u/Renegade__ May 28 '14
For those reading this section in the future: There is a rebuttal published two days later. (reddit link)
1
u/crowseldon Jul 04 '14
I just finished reading and man... that guy can write. Great points and delivery.
Thanks.
73
u/252003 May 26 '14
In the time it took to write that article he could have ported a hundreds of lines of python 2 to python 3. If people spent as much time upgrading as they spent time complaining about having to upgrade we would have made a lot of progress. Is creating a third version of python that is worse than the current one but can use old libraries a good way or is working on moving forward and developing the newest versions of our language the best way.
46
u/mitsuhiko Flask Creator May 26 '14
If people spent as much time upgrading as they spent time complaining about having to upgrade we would have made a lot of progress.
That's a pretty pointless argument for a variety of reasons. The biggest one is that there is no reason to upgrade because Python 3 does not have a business benefit for lots of people.
As a person maintaining open source code Python 3 for me doubles my work for zero benefit as I'm not using Python 3 myself.
As a person working in a company upgrading to Python 3 means that I lose compatibility to the ecosystem and PyPy. If I support both, then why not just continue using Python 2?
Aside of that, there is so much stuff in Python 3 that is barely reviewed because there are no users that it's really damn hard to argue that it's unconditionally a better language.
//EDIT: arguing with "if people" is not useful in general anyways because a system would obviously be most efficient if all actors in it, would share the same ideals. But that's not how the world works. You could use the same argument to ask for why we don't have world peace.
22
u/bastibe May 26 '14
So write your code to be compatible with 2 and 3. In most cases, this is very easy, and the right way to go. Many open source projects do it that way (mine included).
Also, if maintaining a Py3 version doubles your work, you are doing it wrong. Running your tests in a different interpreter should in no way double your work.
20
u/mitsuhiko Flask Creator May 26 '14
Guess I'm doing it wrong then.
10
u/flying-sheep May 26 '14
jup. bilangual python is less fun than python 3, but less work than maintaining two forks.
1
u/marky1991 May 26 '14
I guess so.
3
u/v3ss0n May 27 '14
I do hope You guys know that Mitsuhiko is developer of the popular web microframework Flask...
2
u/marky1991 May 27 '14
That doesn't change anything. A doubling of work implies that you're effectively got two completely independent code flows. If that is the case, you're doing it wrong, whether you're guido, mitsuhiko, Awful coder #4,003 or anyone else.
2
u/v3ss0n May 27 '14
What i mean is he built a successful web framework that supports both py2 and py3 , are you sure he is doing it wrong?
4
u/marky1991 May 27 '14
"A doubling of work implies that you're effectively got two completely independent code flows. If that is the case, you're doing it wrong..."
1
u/crowseldon Jul 04 '14
I don't think he is suggesting that his work is wrong but that he maybe finds fault in something just because he is using the wrong methods that double efforts when he shouldn't have to.
The result will be just as good with less effort.
3
5
u/mfukar May 26 '14 edited May 26 '14
That's a pretty pointless argument for a variety of reasons. The biggest one is that there is no reason to upgrade because Python 3 does not have a business benefit for lots of people.
I would argue that if those people (lots? who are they?) don't have a business reason to upgrade to Python 3, they don't have a business reason to complain about it, either.
4
u/Kaelin May 26 '14
Most people don't complain about it or give a fuck about Python 3. I care about Python 3 as much as I care about Perl 6.
3
u/Categoria May 26 '14
Perl 6 has some interesting stuff I hear. Also it no longer pretends to be the successor to anything.
-5
u/WallyMetropolis May 26 '14
If people would stop committing crimes, we could save a lot of money on police.
0
May 26 '14
[deleted]
11
u/twotime May 26 '14
The business case here is that languages which cannot keep b/w compatibility at reasonable level should not be used for any future projects... Existing projects are either to be mothballed or rewritten in another language..
Welcome to the real world.
0
May 26 '14
[deleted]
4
u/twotime May 26 '14
Such breakage is tolerable for a language which is just starting. It's a suicidal mistake for a language with massive deployed code base.
Two more observations.
A. it's not a binary choice, breaking changes could have been introduced with deprecations/future imports/etc which would have been slower (but then it might still be faster than what we've got with python3 ;-)
B. given that the cost of b/w compatibility breakage is so high, it only should be broken for clear improvements. Python 3 does not meet this requirement IMHO:
B1. print function vs print statement. A wash.
B2. unicode by default. A mess. (as in: it has broken about as many things as it has fixed)
B3. dictionary interface changes. (.keys() is now an iterator). A minor improvement
etc, etc, etc
1
u/john_m_camara May 26 '14
Show me instances where Python 3 is being used in a production environment doing something meaningful. That would be a business case.
1
u/Citrauq May 26 '14
I use python3 for (almost) all new projects at work. We usually write django apps with a REST API for a javascript (angular) frontend.
0
u/john_m_camara May 26 '14
How about providing the name of the company or website so we can have a chance of judging how meaningful your use of Python3 is. So far I have only come across a few small startups and a few individuals using Python 3 in production and in all cases they were very trivial apps to build and most had none to just a couple of dependencies on 3rd party libraries.
0
u/reallyserious May 26 '14
Where are you going with this? Am I supposed to read this as people using py3 don't do meaningful things?
3
u/john_m_camara May 26 '14
I'm honestly interested in finding out at least one serious project using Python 3 in a production environment. Everyone I know that earns a living programming and does Python development refuses to run their apps in production under Python 3. Many of them are willing to provide Python 3 support for libraries they develop so it's not the case that they don't want Python 3 to be successful it just they are not willing to take the risk or can't make the change due to dependencies that are not supported.
3
May 27 '14 edited May 27 '14
Just curious, how much Python code base is related to web development? The reason I ask, it seems these type of arguments I see seem to center around Python being used among web developers. But Python is being used in so many different domains. So it may be true Python 3 may not be used a lot in production in the web development world, but in the scientific and data analysis world, Python 3 is being used widely. I don't have numbers to back it up, but at my Fortune 500 company, we use Python for data or statistical analysis. The Python 3 code we use, use the full scientific stack (et. el. numpy, scipy, matplotlib) without problems. We are using Python 3 for making critical business decisions, which include whether or not our company will issue million+ dollar recalls.
So basically I am trying to say that we should remind ourselves that Python is being used in other domains besides web development.
5
u/mitsuhiko Flask Creator May 27 '14
I work with web and computer games. Everybody i know uses Python 2. I have yet to see a company of significance using Python 3. In fact: i don't know of a single company using Python 3 I think.
4
u/john_m_camara May 27 '14 edited May 27 '14
I generally do only a small amount of web development so my comments are being driven by a combination of my experience in scientific and general software development and also influence by a large number of software developers I know that earn a living using Python.
If we were to bin SW development into web, scientific, dev ops, and general software development I would say the web side of things are supported fairly well in Python 3. Part of what makes it in better shape is that on the front end side of things it's nearly all JS and not influenced by Python 2/3. If you look at the web server functionality it self (ignoring the backend that contains the business logic.), the web frameworks and its closely associated eco system you find that the majority of the libraries have been ported to Python 3. There are exceptions like Paste but there are also alternatives to Paste that work in Python 3. Although there are a lot of Python web frameworks when you look at Python's web eco system there really is not that large number of important/highly used libraries. Since the number of these libraries is "reasonably small" then it should come to no surprise that web development is in reasonable shape.
On the other hand the dev op guys have so little chance of using Python 3 as it seams like every cool tool they would want to use is not supported. Pretty much all the cloud tools are not supported, Fabric is not now but I hear it is in the works, neither is salt, supervisor, etc.
On the scientific side of things, Python 3 support is reasonable good within the core libraries (numpy, scipy, matplotlib) and you can also add scikit-learn. But once you start to get away from these main stream packages support for Python 3 is nearly nonexistent. For instance today I needed Delaunay triangulations but support for it is fairly basic in scipy plus its quit slow so I prefer to use the triangle library which currently does not support Python 3. Now this library is likely fairly trivial to get working with Python 3 but when you come across a dozen or so libraries each month that is not supported who has the time to fix them all plus it doesn't appear to even have a test suite.
When you are doing general SW development or the backend of a web server the issue usually comes down to domain specific libraries that are often not supporting Python 3. So as much as it is great that a good chunk of the top 200 libraries listed in the Python 3 WOS has been ported it it does not come close to being a fair representative to all the thousands of domain specific libraries that are useful to huge numbers of Python developers.
If you have to support Windows have fun. You can run into enough road blocks and issues with Python 2 on Windows but usually most can be worked around. As far as I know there is no option to interface with .NET under Python 3 plus I hear comtypes is hit or miss. Support for both .NET and COM works well in Python 2.
Most Python developers would agree that that Windows support is second class. Why is that? Most developers of libraries use Linux or OS X. They code it under Linux, test it under Linux and if a Windows user reports an issue they do what they can to fix it and when they do so they hope someone with Windows will give them feedback if the fix doesn't work. Now I know some projects support Windows better than that but for the majority of libraries Windows support is like I said second class.
If most Python developers can see Windows has second class support why is it they can't see the same thing with Python 3. Let see the libraries are written by developers who write their code and test it under Python 2. If someone complains about an issue when running under Python 3 they fix it and hope someone will let them know when something else breaks. Sure many more projects have their CI systems test Python 3 compare to testing it under Windows but in the end the libraries are getting very little real use or attention under Python 3.
Now even if all the public libraries get ported over to Python 3 there is still the issue of porting all the non public code. If the benefits of porting don't out weight the costs it highly unlikely to happen. Unfortunately for most projects the negative benefits far exceed the nearly nonexistent positive benefits plus it's going cost a boat load of developer time. Have fun with that conversation with your boss, CEO, or a customer.
→ More replies (0)-9
2
u/anonymouslemming May 27 '14
I'd love to move to Python 3, but it won't be available for production use in my firm until late 2014 / early 2015. Mainly because for what it costs to make it available, it doesn't offer enough extra value over every other project the team who own it are working on.
And if I'm stuck on 2.7 at work, I may as well keep using that for my personal projects too ...
6
u/TankorSmash May 26 '14
The alternative is dealing with those warts that built up. This is a necessary evil!
2
May 27 '14
I used to abuse Python as a faster, more flexible bash, and only recently have begun using it to its full potential. Looking back there were a lot of things I wrote in bash or awk that would have made far more sense in Python (and which would have been more readable for others). Seemed in my ignorance I always asked if I could do something in bash, never if I actually should. Coming from HPC and architecture stuff, OOP was not exactly my forte, but now I've been learning Python to use as something more than the default shell on many of my favorite applications, and I am actually using it to create true software systems in the form of GUI tools that are robust enough to share. It has also been nice fully transitioning away from DSLs for numerical analysis and embracing Python's growing expertise in it. Numpy and Scipy were at Python 3.0 more or less from day one of its release.
I chose to learn Python from the ground up in earnest a couple of years ago completely ignoring Python 2 and writing in Python 3 from day one. My reasoning was that it was the number in its name was bigger, and I it turned out that I liked the print function better... that was about it. I did not know the politics behind this or why narcissists post "[insert contrarian statement here]" on Medium and end up all over Hacker News. In my experience, there has been nothing I have found I could not do with Python 3 libraries. My needs are not especially pressing, but I feel as though we have the bases covered already. If anything, we need more systems to move by Python 3 as a default. In the Linux world, often the libraries are already there, but they are simply waiting to be packaged. I think the main thing standing between Python 3 and wider adoption is the minutia of the final stages of deployment, and yes, probably a health dose of developer inertia, too. Some of my old scripts from before I started really trying my hand at Python would get hung up on something like how I was invoking urllib2 to get a file. Others needed a single extra line to the effect of var_str = str(var, encoding = 'utf-8'). Furthermore, in the process I learned why libraries like urllib were changed the way they were. If anything I have found that the organization of stdlib objects is more consistent now.
My two cents.
1
u/mitsuhiko Flask Creator May 26 '14
Which is so much easier than dealing with all the crap that Python 3 brought in. Very few people review the APIs in Python 3 now because there are barely any users.
0
May 26 '14
[deleted]
3
u/Categoria May 26 '14
I'll be honest, I'm not a fluent python programmer (I've worked with other people's code and hacked some small things together, but my strengths are in other languages). Currently the discussions about 2 vs 3 are scaring me away from investing time into actually learning the language in depth.
This is my decision as well. Although I have a ton of python experience and have used it on and off since 2.2. Luckily most of my work lies in the web development space so there's no problem finding alternatives and python 2.7 is still great.
11
u/mitsuhiko Flask Creator May 26 '14
Python 3 is the playground of the cpython developers which seem incredibly disconnected from the real world by now. A lot of the APIs on Python 3 are just bizarre and badly reviewed or completely miss real world solutions for the same problems that people made before. This goes well beyond the bytes and unicode issue even though that will continue to be a huge problem until someone replaces Python 3 as some of the bad decisions in it's design are now so engraved in the API that they will never go away.
0
May 26 '14
[deleted]
17
u/mitsuhiko Flask Creator May 26 '14
Importlib for me is a prime example of a project that lost all direction. It's driven by one or two people and they are developing it without any real world experience with it. I pretty much gave up supporting any of that stuff because with every Python 3 version it changed in new ways and at this point it has lost all portability for me as I need to support from 2.x to 3.4.
Another good example is the general stream interface. While you could argue that the streams are byte/unicode problems they in themselves are an API problem more than a unicode problem. I waste enormous amounts of time trying to make streams work well but the new API is just inherently more complex than before for very little benefit. For the user the new streams are definitely more complicated than the old ones.
While not Python 3 related, but there is a whole new packaging infrastructure project going on in distlib which is used by nobody (with the exception of pip which uses the semantic version parsing of it) besides the original creator and maybe a handful of other people.
asyncio thankfully had Glyph overseeing it, but even with asyncio there are not enough users for the library to go into the interpreter. We're already at the point where there is going to be an updated version uploaded to PyPI which raises the question why it's built-in in 3.4 in the first place, if it's going to change in 3.5 again.
This iterative development worked in Python 2 because of two reasons: a) stdlib packages came from outside the stdlib and were iterated there and b) they were developed out of a specific need and people used it. I don't see this happening for anything in Python 3.
1
u/donaldstufft May 26 '14
For what it's worth, distlib is just an external library and isn't going to get added to the stdlib any time soon (if at all).
-3
u/ionelmc .ro May 26 '14
What's exactly wrong with importlib and what do you mean
support any of that stuff? It's a py3 carrot - what else do you expect ?Also, it's kinda weird that you complain about the lack of
real world experience. There's a community process and you can get involved in the creation and review of PEPs if you think the PEPs could/should be better.2
u/mitsuhiko Flask Creator May 26 '14
What's exactly wrong with importlib and what do you mean support any of that stuff ? It's a py3 carrot - what else do you expect ?
How good is a carrot nobody supports? 3.4 changed the importlib interfaces again and deprecated a whole bunch when introducing the module specs of stuff but did not provide replacement functionality.
Also, it's kinda weird that you complain about the lack of real world experience. There's a community process and you can get involved in the creation and review of PEPs if you think the PEPs could/should be better.
I am not using Python 3. All my Python 3 experience is coming from porting libraries for a barely existing user base.
-2
u/ionelmc .ro May 26 '14
I am not using Python 3. All my Python 3 experience is coming from porting libraries for a barely existing user base.
I'm pretty sure that's quite enough :)
10
u/mitsuhiko Flask Creator May 26 '14
I have zero interest in investing more time into Python 3. I do not believe Python 3 is something that can be repaired in a way to surpass Python 2 in enjoyability for me.
→ More replies (0)-4
u/Tillsten May 26 '14
Why all dissing of the python developers? Only because you are disagreeing with them? Seriously, what have they done to you to make sentences as
cpython developers which seem incredibly disconnected from the real world by now.
or
It's driven by one or two people and they are developing it without any real world experience with it.
?
They are mostly volunteers, cut them some slack.
0
May 26 '14
[deleted]
7
u/mitsuhiko Flask Creator May 26 '14
Everybody does work across an IO boundary. Python 3 had the idea to hide the boundary from you but that trick did not work, now they added escape hatches in through surrogate escapes and other things and made everything worse in the process.
Most people just produce broken code in Python 3 now because if you don't touch it too much, it seems to work.
Just getting command line arguments is boundary code.
0
May 26 '14
[deleted]
4
May 26 '14
It's an OS issue. CLI arguments and file names are always UTF-16 text on Windows and some unregulated binary stuff on UNIX that may or may not be some text in a system-wide locale that may have been changed by another application through
setlocale. Naturally, choosing one approach somewhat breaks the other.5
u/mitsuhiko Flask Creator May 26 '14
Or you don't pass any ascii characters. Try opening an non ascii file and start your application through upstart for instance.
→ More replies (0)1
May 26 '14
python 3 retains most of python 2's problems/mistakes
3
May 26 '14
examples?
3
May 26 '14
poor equality/value semantics, incoherent concurrency story, poor module system, overcomplicated object model, actively harmful stdlib (
pickle,asyncore,xml.dom.minidom, etc)3
u/ggtsu_00 May 26 '14
The standard lib still needs a huge overhaul. subprocess.Popen still does silly things on windows like turning
--foo="bar, baz"into
"--foo=\"bar, baz\""0
May 26 '14
[deleted]
2
u/tilkau May 27 '14
Python 2.7 is pretty much wart-free compared to every other language out there. If the warts were worse than the cost of going to 3.x, everyone would be on 3.x.
This simply isn't true. Inertia is a huge factor - people justify what they currently do but ultimately the real reason they do it is because that is their habit. Habits are more powerful than cost-benefit analyses, as a rule.
Python 3 would need to be outstandingly and unmistakably better than Python 2 to get the kind of traction you speak of. But Python 3 is merely better.
3
u/john_m_camara May 28 '14
This simply isn't true. Inertia is a huge factor - people justify what they currently do but ultimately the real reason they do it is because that is their habit. Habits are more powerful than cost-benefit analyses, as a rule.
History proves your habit theory is wrong. Over the years the vast majority of Python projects have been migrating to newer versions. I have been using Python since the 1.5.2 days (1999) and only recently have we have seen this phenomenon of large number of production projects not migrating to newer version.
In the past, projects would run on the latest version or the past 2 previous versions. You are always going to have some projects on the bleeding edge while others are going to lag behind. This worked well for well over a decade. Now the majority of projects are on 2.7 and it will be that way until there is a compelling reason to migrate because at the end of the day whether you like it or not cost-benefit analysis do matter.
1
u/tilkau May 28 '14
You appear to be replying to your own misrepresentation of what I said -- I see no other reason why you would feel the need to assert 'cost-benefit analyses do matter'.
Please stop that if possible.
Nice account of history.
4
u/bastibe May 26 '14
How long will you keep saying this? Maybe Py3 already is the right place to go? Maybe library support is already good enough? Maybe most devs already switched over, and all the good stuff is already happening in Py3 these days?
And if so, why are you still living in the past? I keep thinking that those warts you are talking about, they are not language features, they might be developers...
0
May 26 '14
[deleted]
2
u/flying-sheep May 26 '14
It has no way to use undecodable bytes as filenames on Unix (which should be possible)
But that's it AFAIK.
5
u/mitsuhiko Flask Creator May 26 '14
Surrogate escapes are a terrible wart. Way worse than bytes vs unicode in python 2. There is still no good way to deal with surrogate escapes as far as i know.
6
u/georgelulu May 26 '14
If there is any implementation of the python standard that supports 2.x and in addition could add 3.x features producing a python 2.8, it would by PyPy, perhaps more efforts should go towards supporting them.
2
u/kjearns May 26 '14
pypy has exactly the same problem as python3: a ton of cpython2.7 code doesn't work in pypy.
3
u/john_m_camara May 27 '14
Yes it is true that PyPy does not support many extensions that rely on CPython's CAPI but at least it offers some major benefits such as increase speed and smaller GC pauses that for a number of projects make the cost benefit analysis favorable to switching to PyPy.
Now I know a significant number of Python developers and I have yet to know one that is deploying Python 3 apps yet I know 40-60 who are deploying PyPy. There are far more libraries that are compatible with Python 3 than PyPy but yet PyPy's adoption is taking off and Python 3 is going no where. If Python 3 offered benefits that developers were interested in than Python 3 would see it's adoption taking off.
I would like to see the down load number for the various versions of Python 3 vs Python 2. I suspect Python 3 is down loaded less than 5% of Python 2. I would also like to see the down load numbers of say the top 800 packages in pypi and how they break down not in terms of whether or not the package is compatible with Python 3 but to see which version of Python including PyPy they are installed under. Not sure if that would be possible as I don't know if pip and company provide the Python version that is used to execute the install commands. This would provide the hard evidence we all need to see the true story of Python 3's adoption rate.
1
6
3
u/redcalcium May 26 '14
I personally never use python 3 in production environments. But it would be sad if we all stuck with python 2 for foreseeable future. I guess I should start getting into python 3 now.
6
u/oldmanstan May 26 '14
6
u/xkcd_transcriber May 26 '14
Title: Standards
Title-text: Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.
Stats: This comic has been referenced 488 time(s), representing 2.2974% of referenced xkcds.
xkcd.com | xkcd sub/kerfuffle | Problems/Bugs? | Statistics | Stop Replying
8
u/jm_ May 26 '14
It's not like there are alternatives. Don't even mention Golang - it's a piece of dried up crap with arbitrary limitations (error handling from the 90ties, no ability to implement datastructures with native api, no operator overloading). Might as well use Pascal ...
It seems to me that just few bratty library developers (shamed by their users into fixing their shit to support Python 3) are the main detractors.
Now start downvoting ... cause we all love Armin and his unconstructive bitching.
7
u/greyscalehat May 26 '14
Are you honestly saying there are not alternatives to python?
Also just because you don't like Go doesn't mean that 'it's a piece of dried up crap'. I am writing Go at work and loving it, but I am doing my side project in python. They are different tools, one of which is made for writing extremely reliable fast servers and one is really fun to write.
13
u/KagatoLNX May 26 '14
As an aside: I'm not sure why Golang is getting the hate here. Sounds like you've never needed to write systems software. Golang is great for that. It's not shorter; but not much longer, either. It does a number of things very, very right. I suspect just nothing that you have ever needed to do, though.
Complaining Go doesn't have operator overloading is like complaining Python doesn't have type annotations--it isn't written for a use case where they're particularly useful.
5
u/djimbob May 26 '14 edited May 26 '14
go isn't a drop-in replacement for python, but its a well designed, easy-to-read statically typed language with good well-written libraries. It serves a different purpose. (Granted obviously python has many more libraries having a 10+ year head start).
Go misses some nice features (e.g., generics, operator overloading), but granted go was publicly released ~3 years ago -- give it time (python 2.0 didn't have bools, sets, new-style (
objectderived) classes, decorators, generators and iterators,withstatement, nested scopes (beyond two nestings), automatic casting of 32-bit int to arbitrary sized int, etc). Once you get used to it, I really like the panic / recover and explicitness checking for errors. It's a different mindset, but actually works really nice.Not sure what your "no ability to implement data-structures". Are you talking about how
makeonly works onslice,map,chan? This isn't really a limitation, you can easily build on top of those structures; e.g., create a set out of map (go's equivalent to a dict) with values that are zero-byte struct. Yes, python has an underlying C API that you are encouraged to use as python2 would otherwise be unusably slow. As go doesn't have that huge speed difference it would be a bad idea to encourage writing things in a C API on top of go. Granted there still is thecgoif you need to call C library/function from within go, and IMO it is much easier to deal with than python C API (by nature of go being statically typed).2
u/alcalde May 26 '14
Might as well use Pascal ...
Oh now you've done it... now you're going to hear it from the Delphi developers....
It seems to me that just few bratty library developers (shamed by their users into fixing their shit to support Python 3) are the main detractors.
That's not the most diplomatic way of putting it, but it's fairly accurate. One Python library maintainer once said "Why should we ever port to 3 when Python 2's going to be supported FOREVER?" It's just inertia at this point.
2
u/flying-sheep May 26 '14
armin has better points as this guy when he’ bitching. i still don’t agree at all with both, though. see here for my rebuttal.
and the only thing that completely turned me off of golang is the missing generics (your second point). i can’t even implement a tree, wtf.
1
u/ggtsu_00 May 26 '14
I keep hearing so many complaints about generics in go, but interface{} types serve that need pretty well for most cases.
For a tree you could have:
type Node struct { Left *Node Right *Node Data interface{} }4
u/flying-sheep May 26 '14
Type safety.
0
u/ggtsu_00 May 26 '14 edited May 26 '14
What is unsafe about it? You you still need to have type assertions before you can actually use interface{} object as an actual data type and the type assertions give you the type safety. It is not any less safe than a python equivalent if that is where you are coming from.
8
u/Categoria May 27 '14
Why have static types in a language where you need runtime checks to replace all but the simplest uses for a type system. Even java learned this lesson.
0
u/ggtsu_00 May 27 '14
That is also why handling unstructured Json objects with in languages like Java is a huge pain.
2
u/Categoria May 27 '14
Java is more verbose than necessary. For example in Scala there's https://github.com/mandubian/play-json-zipper this for example. But how is it more painful than Go? Json is a very simple type to represent, after all. Whatever Go has can be emulated by pre generics java. After all, their type systems would be equivalent modulo structural typing.
1
4
u/mdipierro May 26 '14
Sadly this is right. Many people see python 2 as the end of the line and python 3 as a different language. The port from python 2 to 3 cannot be automated (who are you kidding!) you must really understand the details of the code to port it without mistakes. This is too expensive. If people must understand code to port it they may as well consider porting it to other languages. Breaking backward compatibility is ok when it does not result in change of behavior. print->print() is fine, except to except/as is pointless but tolerable, but swapping str/unicode for bytes/str is diabolic.
4
May 26 '14
I think the bytes/str change is wonderful. Trying to figure out the mess created by implicit conversion in python2 was hell.
2
u/exhuma Jun 01 '14
... and from my experience, most projects having a hard time porting because of unicode issues is because they have been careless. There are exceptions of course. If I recall correctly, mitsuhiko had a couple of very valid points regarding flask. But that's a corner-case.
In Python 2 you could read from a network socked and just assume it was
ascii. Python 2 did not force you to make the necessary research. Now, with Python 3 you are forced to de/encode data on the appropriate boundaries. This is a very good thing! And making it clear that you getbytesfrom a network socket and not astringis a very important distinction! Reading from such a source andencodingthe result is playing with fire... Yet Python 2 allowed it.Yes, Python 3 has made this more verbose and more of a chore than it was previously (and I reckon that is why people are complaining). But it forces you to at least think about encodings where necessary and may avoid nasty bugs.
2
u/fuzz3289 May 27 '14
Sorry have you read http://legacy.python.org/dev/peps/pep-0461/
Breaking backwards compatibility was necessary. Python 2 has glaring flaws, which doesn't mean 3 is perfect, but no one took the decision lightly. The language is better for it, to deny that is incredibly shortsighted.
1
u/mdipierro May 27 '14
I agree it is a better language (with some caveats). The issues are not technical, they are social. The features added are not worth the cost. At least not yet.
2
u/fuzz3289 May 26 '14
This article is total bullshit.
Seriously this article is INCREDIBLY naive. We needed Python 3 to not be backwards compatibility because Python 2 was suffocating the core devs. There were serious innate problems in the language that made it impossible to make the real important changes we need.
And third party lib support? Python 3 has everything except the libraries that need bytestrings and with python 3.5 we have the support we need for them to move forward as well so that argument is ENTIRELY bogus.
DO NOT upvote this article. It's written by someone who doesn't understand the situation, who doesn't care to understand it, and is just whining about some extra sys-admin stuff they have to do as a result of a change that will ultimately make python a much better language than ever before.
There were arguments against Python 3 in the past but seriously learn to read the PEPs. All the real issues are being addressed and all the crap this article mentioned were arguments from 2-3 years ago. Get up to date, educate yourself on what's going on in the language now-a-days. Python 3 has become a hundred times better than Python 2 ever was. Things like async-io, bytes % formatting, etc are moving us forward in the language not back. Python 2 is no longer a modern language and while there's nothing wrong with using it for the next couple years to ease migration efforts IT IS A DEAD LANGUAGE. There are no longer any arguments supporting it, and the community has moved on. You should too.
2
u/justdweezil May 26 '14 edited May 26 '14
The new Unicode issues in Python 3 are a non-starter for my work - if there was a definitive guide to sorting those issues out I'd seriously consider it, but judging from the low quality answers to Armin Ronacher's posts about Unicode in Python 3, it won't be any time soon.
That being said, this article is hilariously unproductive. The idea of forking Python 2 and just "taking Python 3 out back" makes no sense at all... smoothing the transition from 2 to 3, or adding killer features to 3 is the way to go. We could do with less articles like this.
0
u/mouseroot May 26 '14
After doing some research I do agree with this comment. This article seems to be about 2 years late.
0
u/kimvais May 26 '14
If a 3rd partuy library doesn't have not even an experimental/partial Python 3 support, it is IMO by definition, abandoned by maintainers.
6
u/kjearns May 27 '14
Unfortunately your definition does not correspond to reality. It would be nice if it did.
0
u/kimvais May 27 '14
Can you give me a few examples of widely used modules that are being actively maintained but do not have any level of Python 3 support?
2
-2
u/mouseroot May 26 '14
I agree with this article, When I first started python i assumed the latest was the best, as is true with just about everything else only to find out print is print() and at the time none of the libraries i was looking at were even supported. so much like when I was trying out DevC++ and trying Cout << "hello world" instead of cout << "hello world" it was very frustrating to learn that not only is python 3.X not recommended its almost like windows ME...just a really really bad idea and for people who are looking to intro into python chances are they will go down the same road and in most cases give up altogether.
Porting isn't the answer in my opinion, I think killing off the 3.X branch and possibly adding more "batteries" to python 2.X would be the best idea or maybe focusing on fixing the issues with 2.X or hell fork 2.X and call it 4.X the biggest issue i still see is package management pip is boss why the hell isnt it part of standard python? node has npm, ruby has gems, python should ship with pip. and people saying "its getting there" the facts are its been getting there since its inception its time to move on.
most Linux distros ship with python 2.X (if any python at all) after using 3.X there really isnt that much that makes it "the new python" besides some incompatibilities from 2 to 3 its not faster, its not any more efficient its just dead weight.
and if this continues python will probably lose alot more users then it gains which is really sad its a kickass langauge.
5
u/donaldstufft May 26 '14
Python 3.4 ships with pip more or less.
3
u/mouseroot May 26 '14
that's my ignorance then, I believe i used 3.2 or 3.1 and didn't even know about pip at the time. for me it was manually downloading the files and placing them in site-packages, much ignorance back then :/
0
May 26 '14
[deleted]
4
u/mouseroot May 26 '14 edited May 26 '14
well that's true, but I was referring to your average starting out programmer who just wants to bang out some code from an example article/blog and see "hello world" show up. he will more then likely if not guided by someone choose the latest.
-1
May 26 '14
[removed] — view removed comment
2
u/mouseroot May 26 '14
no not my main issue, but the issue for someone trying to pickup python as a first langauge. as its usually suggested. its just the most common example. i mean why change it in the first place? was it not working correctly? it seemed fine to me. a good example of something that was "fixed" while never truly being broken.
0
May 26 '14
[removed] — view removed comment
3
u/mouseroot May 26 '14
Ah I didn't even consider that, I guess my "print" example doesn't fit that use case. and after doing a bit more research it seems a lot of the 3rd party libs are just about ported to python 3 at this point. However I still don't see any real benefit with python3 over 2 but perhaps that's just my ignorance again. all I do know is, unless forced to switch to 3 ill stick with 2.7 and not lose any sleep over it.
-4
u/rabc May 26 '14
Yeah, let us all create an entire new branch in the tree just because people are lazy and don't want to migrate. It can’t do any harm, right COBOL?
0
May 26 '14
[deleted]
2
u/kjearns May 27 '14
You must live a charmed life if you never need to dig up and make use of old ill maintained code. You must be truly blessed if you also have time to port all your dependencies (and then maintain those ports).
0
May 27 '14
[deleted]
3
u/kjearns May 27 '14
Most recently? The MKL optimizations from continuum don't work with python3 on osx.
More generally? Everyone I work with is writing python2.7. All of my code is in python2.7. Nothing in python3 is compelling enough to warrant the pain of switching.
If someone made a python2.8 that backported new things from 3.x to 2.x in a backwards compatible way I'd be all over it, but I agree with the article in the OP. Python3 asks an awful lot and doesn't bring much to the table.
69
u/willm May 26 '14
I may have agreed with this a year or two ago. Not now though. The situation is way better than it used to be, and only improving.
Developing a new module to run on both Python 2 and Python 3 is also much less of a pain than it used to be. Particularly if you follow the advice on (http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/). It does make your code less beautiful than a pure Python 3 code base, but that is the price you pay for compatibility.
My biggest porting headache was adding Python 3 support to PyFilesystem. It was tricky because this library is an abstraction layer for files, which work quite differently in Python 3, and we didn't want to have to write everything from scratch. I have ported another, much larger project, in a day. It was tedious work, but no major issues.
But these problems only effect library developers. If you're building an application, just use Python 3. Most libraries have Python 3 support, and most of the ones that don't are probably not actively maintained any more.