I've grow to highly respect the Django project for its good documentation, its healthy consideration for backwards compatibility, security, steady improvements and all round goodness.
Interestingly, I have the exact opposite view on Django.
I hate their API and overall architecture, which I find to be the result of glueing features on top of features for many years.
The internal code also is just like that: looks like every single method is riddled with out-of-band conditionals, which is the result of a community that prefers to hack things to work, instead of rethinking/refactoring.
I'd prefer to hold judgement on the internals of Django, however as a developer using the API, I also think it's a pleasure to use. There is a very high level of consistency, similar patterns used throughout, and the architecture results in a project structure that I can explain to a new developer who has never used Django before in minutes. I find few frameworks really scale in terms of structure and consistency, and working on a large web application, Django has proven to be very valuable for us.
I'm curious, what's an example of a framework that you think has a better architecture, and in what context are you evaluating this?
I would bet my horse on https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.
Pyramid is great, but for years they had a ridiculous Iron Maiden- heavy metal like branding [0] which make it hard to sell it in the corporate world. I'm glad they evolved on this point.
Not to mention, a few parts / typical components of pyramid are just nuts, like auth. Colander is also a struggle to use.
Still my go-to framework though. The websauna framework linked above might be something I have to try.
As I build more and more side projects I find myself wishing pyramid were just a bit more opinionated so I could get the basics up and running a tad faster. At this point I mostly cut up old projects and port them to each next one, heh
I agree, but you know what; I think the new branding is worse :(
It's a shame, because I've wanted to try Pyramid since I watched their talk at PyCon 2011, but the branding (including the new 99 Designs looking logo / theme) has always made me think, "This will never really take off."
I don't mind the artwork (and actually like it), but I think the real issue is the text:
Use Pyrapid Like a Pro
"Like a pro(fessional)" implies that you, the target audience, are not "professionals". However, if you use it in the corporate world, you do use it as a professional.
This makes it sound like an advanced toy rather than a bullet-proof work of engineering you can rely on. Which is really a pity, because Pyramid _is_ a framework you can rely on.
When you say "Django is not RoR", are you saying Django doesn't break backwards compatibility but Ruby on Rails does?
If so, I have to very strongly disagree. It's almost mind boggling to me how much they break backwards compatibility as a framework. They usually warn users with a deprecation warning in one version and then they make the backwards incompatible change in the next version, but the sheer amount of these kind of changes makes upgrading an infuriating process. Especially when upgrading a large codebase.
That is, by definition, breaking backwards compatibility. I.e., the code that I wrote against version X will not run against version X + n. They just give a warning about it in version X + (n - 1). Backwards compatibility means that my code will run against X + n for all values of n >= 0 without modifications.
> That's exactly how _not_ to break backwards compatibility.
No, no, no. Backwards compatibility means that there are no breaking changes at all - announced by deprecation warnings or not. Think Linux's public API.
How else would you introduce backwards incompatible changes?
Especially with the LTS upgrade path that alasdairnicol mentioned I wonder what there is still to improve.
If you want to be backwards compatible, then you "simply" do not introduce such changes, there's no "how", you don't.
A platform that works hard to be backwards compatible does only additions and extensions, and keeps maintaining the old API as well so that old apps run without changes; possibly keeping around multiple depreciated ways to do the same thing (e.g. as win32 does).
It is debatable whether backwards compatibility is worth that cost (and it often isn't), but it's certainly a choice.
Agreed 1.4 LTS to 1.8 LTS was tricky, but future LTS to LTS upgrades like 1.8 to 1.11 should be easier. From 1.8 onwards, if your code runs without depreciation warnings in one LTS, then it should work on the next.
Could you give a description of some subsystem that has been architectured in this way, and then provide a concrete example of some methods that implement this pattern and why it is bad?
We are users of Django, and it helps us to deliver projects, quickly. Interested to know how you think things could be improved.
I disagree with the parent post; Django's codebase is overall pretty high quality. It definitely used not to be that way, though.
But there are components that fit that. The entire form subsystem is awful to work with. Working with Javascript, webpack apps etc is a huge pain.
The template syntax is also a failed design experiment, based on the premise that backend coders and template authors are not the same people and should not have the same level of power -- some of this is based on a good idea at its core, but Django ended up backtracking on that half-way and we're now with a very inconsistent template system and having to implement kludgy template tags and filters or new object methods that do not take parameters whenever we want to do anything remotely complex.. At this point I wish it'd just move towards supporting Jinja syntax (that is, alongside the regular syntax, not as a separate engine like it's currently possible).
Not sure what it's like now, but the insides of the admin used to be fairly terrible (generating HTML with strings for instance).
There was a patch to change this to use templates, but it was rejected at the time as it slowed things down too much.
FormWizard (which I hear doesn't exist now), was a nightmare to use for any sort of complex form - I tried to do just this and had to call many private methods.
I understand metaclasses, but found the implementation of the ORM a little overcomplex.
Trying to use the ORM API to work out the structure of the DB was a bit of a pain last time I tried (had to call private APIs).
The core Django developers will (and have) freely admit that the admin interface implementation is a bit of a mess. There is an enormous amount of technical debt in it. It is however not a "core" part of Django and there are many alternatives. I think most people would agree that the correct long term solution to the admin interface is a complete rewrite, however the cost of doing so is too high.
The html forms (used in the admin and everywhere else) have until now been generated from strings, however the next realise 1.11 (went to alpha yesterday) this has been changed to using the template tools.
While the admin code is kinda messy it's still easy to extend and customize. I'd be somewhat surprised if you could make something that dynamic and not be at least a bit messy.
I myself and also other people I know have written quite some domain-specific applications almost entirely within the Django admin, which are as a result: secure, fast and easy to use, which in some cases are not just a bit better than the existing commercial tooling in these domains.
Not sure why you hate it? It is one thing to say Django is bad at x and then specify x and other thing is to say I hate Django because it its internals are shit and shoot your points like a machine gun. The second approach is not going to be helpful to anyone.
> Last time I looked a lot of the insides were terrible.
But is it really? Speaking from personal experience it is easy to compare project with large featureset (and one with heritage) to one with scope on doing single thing and come with conclusion that smaller, focused codebase is more consistent and better implemented. At the end of day what matters is if those terriblenesses actually bite back:
- is this code changed frequently? Does it need to be changed frequently?
- is it written in a way that that makes fixes and improvement unbearably costful?
- is it written in way that allows it to be put apart? How costful are those individual parts to improve?
Django is large codebase that is worked on by different people and when time permits this, which means different parts differ in their age, practices, and ultimately, quiality. This eventually results in codebase that may give appearance of being messy.
Joel Spolsky explains this nicely in his article about old and large codebases appearing as hairy and messy to developers:
Celery is an interesting one. The code looks well written, but I found contributing to be a real pain and documentation a mess, especially compared to Django's docs.
Also, up until recently it was a one man job by Ask Solem. He's done incredible work making this project live and I am grateful for that. However I fear others have found it hard to maintain as well, slowing down progress on a very popular backend python project.
Things were a little bit hairy back in the 1.3 days, but they've done a ton of cleanup in modern times. I find the source much easier to follow these days. Many of the systems have been more clearly isolated to allow for replacement.
It was pretty clear for multiple years that Django would eventually migrate to python3 only. Even regarding library support, I've started going python3-only with my Django projects at the beginning of 2015 and had practically zero problems, as only some esoteric packages were not supporting python3 (and then I wouldn't have used them for client projects anyway, because esoteric).
I still have one customer with a Django/python2 code base. When migrating to Django 1.11 in 2017, that project gets security updates until at least 2020. Plenty of time to gradually transition to py3. I honestly don't see the problem.
Well it has been on the roadmap for around 3 years, and they will have support for Python 2 in active maintenance for the next ~3 years, so I think this is actually fantastic support from the core team.
I know that there are domains that are mostly on Python 2, and of course you'll always have legacy / unmaintained things lying around. But "zeee majoritie is Python 2.7!!1111" does not become true by some people chanting it over and over again. The simple fact that frameworks and libraries are moving away from Python 2 already proves that the majority does, in fact, not use Python 2. Otherwise maintainers would also be in an approximate majority to block/veto such changes.
> there are actual numbers for Pypi supporting that. What do you have to counter these?
99% of Pypi traffic is composed of mirrors and bots. Python 3 toolchains are more likely to use tools like devpi, wheel, and Docker to cache their packages, while Python 2 toolchains are often going to hit Pypi directly.
We're concerned about which version has the majority of users, not about which has more downloads on Pypi.
We'll just have to see. That's the beauty of this. Don't want to upgrade? Stick with Django 1.11, since you don't want or need new things. It's LTS, so you won't miss out on critical fixes.
When I started with Python - around 2011ish - Python 2.7 on Windows (with Qt 4) was a reasonable choice. Not much later almost everything I did was on Python 3. No regrets, no looking back, and no missed opportunities.
This call has been made a while back, and it makes perfect sense. Python 2 is slowly being EOL'd and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore.
Sure legacy projects still need support and for that they get the 1.11 LTS, but otherwise it's really time to move on.
I code against both Django and Tornado. My Tornado based HTTP servers call C extension while they're handling GETs and POSTs. And that's why I'm staying on 2.7.8 until a customer pays me to port to 3.
My experience is that it is drastically easier to port C extensions than to port python code itself - the C API hasn't really changed a lot and it's usually very easy to reason about C code due to it being more strongly typed than python.
The only reason why it might be hard is you are unfamiliar with the extension's code and/or C
There are a couple #if PY3K, but not much, really.
I ported a bunch of extension modules, total a couple thousand LOC, and it was pretty much a matter of reading the docs (see guide at https://docs.python.org/3/howto/cporting.html ) and adding a few #ifs. Total time maybe an hour or two.
Oh my god stop. You're all over this thread. What bit you?
This is the price you pay for staying on an old version. You do not get to stick to an old version AND demand that others do too.
You CAN stay on Python 2. You CAN stay on Django 1.11. It's LTS. So is Python 2.7. You get to use both until 2020 with no issues. After that, not upgrading is a technical debt that will start to accrue, faster and faster as you can no longer use recent versions of various software.
You are free to make your infrastructure immutable; you then become responsible for it of course. And the money you're not willing to spend porting to Python 3 today will be money you spend on costs related to being on outdated infrastructure, years in the future. That's a tradeoff. Banks do it a lot I hear. A bunch of companies still use ancient hardware and technologies nobody would think of starting a business with today. These companies make billions.
You know what the employees of these companies aren't doing? They're not bitching on HN that the tech they're using is no longer supported.
>Oh my god stop. You're all over this thread. What bit you?
As someone who has 6 comments in this thread yourself, I don't think you are in position to complaint.
I also find "what bit you" and "please stop" rude. You don't get to dictate what others opinion should be.
>This is the price you pay for staying on an old version. You do not get to stick to an old version AND demand that others do too.
7+ years on and the "old" version has more users than the new one. That's a fact supported by numbers. So maybe you want to recheck with reality whether the transition was a success instead of arguing with me?
Not all transitions go well, the Perl 6 transition killed Perl, the PHP 4 to 5 transition (another major one) went quite smoothly.
> As someone who has 6 comments in this thread yourself, I don't think you are in position to complaint.
This isn't a numbers contest. Unlike yours, none of my comments are shitting on the efforts of volunteers that are doing their best to keep people like you happy and making money using a project you're not paying for.
> So maybe you want to recheck with reality whether the transition was a success instead of arguing with me?
And yet you complained about my many comments. If you just had an issue with their content, you could have said so instead of that, and with specific arguments not just "stop" and "lalala hands in the ears, I don't want to hear you".
>Unlike yours, none of my comments are shitting on the efforts of volunteers that are doing their best to keep people like you happy and making money using a project you're not paying for.
You don't know what I've paid or what I've donated to the PSF since 1998 that I've been using the language, or what the companies I've worked for have done for Python. So it's not your business to talk about me personally as I've not talked about you. Can you stop being rude and ad hominem?
(And of course, any user who has evangelized, worked with, and devoted time to a language pays the opportunity cost, whether he pays for its development directly or not).
The community of a language's users can, and do, have an opinion on its progress and the changes that happen to it, whether it goes against the ideas of the volunteers working on it, or not (and it's not all volunteers, a lot of programmers are paid by corporations to work on OSS projects, including Guido who was paid by Google and now Dropbox, and that way companies often get a say on the direction a project takes).
> If you just had an issue with their content, you could have said so
I did. I did not think I needed an argument to ask you to stop bringing such an incredibly negative attitude to the table.
> You don't know what I've paid
I was referring to Django, to be clear. And whatever you've paid, it's in donations -- that's great! But if you want to see support, you'll need to directly pay people to maintain that support. I believe in fact you yourself said that before, here on HN, about other tech.
> The community of a language's users can, and do, have an opinion on its progress and the changes that happen to it
"as long as that opinion is the same as mine", right?
I mean, here is one of your comments for example:
> Some of us have 10+ years of codebases to maintain, and we don't care for Python 3 features
This is basically saying "I do not care for python 3 features, therefore Python 2 should continue being supported even longer [because I have an old codebase to maintain]".
The argument in a nutshell is that because the transition is hard, the Python team should just give up on the transition and support both. It's an argument I've heard before. The reason it doesn't hold water is because doing so would completely kill the language, for good.
We all, as the python community, collectively admitted that the Python 3 transition was awful. It still is pretty bad, although it has improved a lot. Could still be better! But now, we're on the final stretch and the remaining complaints are from people in similar situations as you: Large Python 2 codebase to maintain, therefore can't switch, therefore "please give us more time, and by more time I mean just forget Python 3 ever happened and come back".
Another place I've heard that argument is back when IE6 went EOL. And went EOL again. And a third time for good measure. And then MS had to declare it dead for good. It was holding the web back and we've been better since. We had the same sort of people back then, asking for "more time", "more leeway", "more support" and "please add ActiveX back to the web we promise we'll switch eventually". Do I need to give an argument why that didn't hold water then?
I am sorry that you have to deal with that. It sucks. I've been in this position before (different language) and back then, FWIW, we bit the bullet and we migrated. It sucked for two months, and then it didn't. The longer we'd have waited, the longer it would have sucked. I can only recommend you do the same; it's a good long term investment.
At the end of the day, you can try to pull all the numbers you want, the Python team isn't going to suddenly go back on the plan they've been making very clear and insisted on for several years now. Because it would be a betrayal to the rest of the Python community and would severely harm the language and its future. I do believe it's extremely selfish of you at this point to ask that they cater to the group you happen to be a part of, rather than the overall good of the community.
>> and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore.
> Why on earth will you go to Python 3 at huge rewriting costs?
If you're starting a brand new Django project you're not rewriting anything. If you're rewriting something, it's not really new.
My company is a Django shop and while we have no intention of upgrading Python 2.x codebases to 3, we do start all our new projects on Python 3. It just doesn't make sense not to do it.
Says who?? Someone with delusions of grandeur, obviously. Because that's not up to anyone to say. Python 2 is obviously NOT going away any time soon. You can't just look at reality and claim the opposite just because it pleases you. Python 2 is here to stay and is in MUCH better shape than Python 3, in terms of actual production usage globally. Python 3 is a bad joke that someone wants to force down people's throats for NO good reason at all.
Nope, Python 3 is a sane upgrade to a sane language bringing many enhancements to the consistency and reliability of Python. And it is being used in many production systems already.
Claiming people have been brainwashed because you happen to have a different use case than them is not appropriate for HN, nor anywhere.
And speaking to your earlier point as somebody using Python 3 in production, says me. Nobody in here cares whether you in particular gets to see the advantages of the new version; but you don't get to say "nobody is using it in production", you don't get to say it's "forced down people's throats" when there's years-long support for it and you certainly don't get to say "no good reason at all" if you're the only one unable to grasp the improvements the language is getting.
Good. I've been getting into python a bit because i have an interest in datascience. I'm mostly a Java dev. I have to say the python2/3 divide is a real turn off. Many of the science libs want to use seem to be in 2.7 with no signs of moving.
Is there any hope of other libraries and OSes doing the same thing?
I used to work on a GUI app in Python. I ported it to Python 3, then switched OSes for various reasons. 5 years on, on Ubuntu Xenial (so new I can't even use it in Travis, but that's a separate whine), I install pykdeuic4 and it's using Python 2. So I've basically abandoned that project for 5 years now, because every time I looked at it I thought "surely Python 3 will be here in a few months, I don't want to port backwards to Python 2".
(Serious question: is there a PPA or anything I can use to get these things for Python 3? I need PyQwt as well as PyKDE)
I'm not going to port to tkinter. I like KDE, I like Qt Designer, and I have a working GUI. If tkinter is the only thing that works in Python I'll abandon the language (I mostly work in Scala these days anyway) and find one with working Qt bindings.
At least the science libraries have a better reason for staying. They often require bigger fixes of the modules compiled from other languages. Still, it's good to see larger projects moving on.
I am data scientist who uses both pythons and the only lib I had issues with was the first release of tensorflow (and that was fixed very soon). Otherwise I find it hard to believe that there exist any maintained libraries that do not support both versions.
I do a lot of data science/ML work and it is almost exclusively done with Python3 so I'm not sure what libraries you are referring to as I haven't had any issues.
I have a Python 2.7 project that has been running smoothly for many years now and I'm having trouble finding a reason to upgrade to Python 3. The project uses the unicode type to represent all strings, and encodes/decodes as necessary (usually to UTF-8) when doing I/O. I haven't really had any of the Unicode handling problems that people seem to complain about in Python 2.
Can someone explain what benefit I would actually gain from upgrading to Python 3 if I'm already "handling Unicode properly" in Python 2? So far it still seems rather minimal at the moment, and the risk of breaking something during the upgrade process (either in my own code or in one of my dependencies) doesn't seem like it's worth the effort.
You gain access to continued language support in 2020. New features involving strings will have less risk of bugs. The "range" function is more memory efficient. Integer division automatically floors, reducing bug risk. Dictionaries with guaranteed ordering. Thousands separator in string formatting. Bit length on integers. Combinations with replacement on itertools. New, faster I/O library and faster json. Concurrent futures module. Ability to define stable ABI for extensions. New CLI option parsing module. Dictionary-based logging configuration. Index and count on ranges. Barrier synchronization for threads. Faster sorting via internal upgrade to Timsort. Async I/O. Support for spawn and forkserver in multiprocessing. Child context in multuprocessing. Has collision cost reduced. Significantly faster startup. Type hints. Faster directory traversal. Faster regular expression parsing. Faster I/O for bytes. Faster dumps. Reduced method memory usage through better caching. Dramatically less memory usage by random. Faster string manipulation. Faster propert calls. Formatted string literals (interpolated strings). Asynchronous generators. Asynchronous comprehensions.
How much faster might your code run just by upgrading to Python 3? How much memory might you save?
What py3 does is it enforces the things that py2 only suggests as far as unicode goes. That means on py2 you can go for the proper handling and if you did do everything right, then py3 migration should be almost boring.
The difference is when you didn't handle all the cases correctly. In that situation Py2 will silently do either the right, or the wrong thing and you'll never know. Py3 will likely throw an extension and tell you where the issue is.
So if you're handling lots of unicode text and think you've handled all the string correctly already - that's the reason to move. Now you'll be sure it's correct. The problem with py2 wasn't so much that it was handling anything badly - it was that the default, easy way was incorrect and just waiting to blow up in peoples' faces. (or maybe just silently corrupt something)
I'm fairly sure I'm handling strings correctly under Python 2. What I'm not sure of is the risk of something breaking if I upgrade to Python 3, especially when it comes to upgrading external dependencies. Even if it's just non-backwards compatible API changes, it's more risk to deal with.
You're fairly certain, but with Python 3 you can be completely certain. That's the magic of it.
Python 2 will allow this to sometimes work, Python 3 will make sure this never works, because there's a bytes/text mismatch. It's nice to rule out entire classes of bugs like this
from sys import argv
import json
with open(argv[1], 'rb') as f:
json.loads(f.read())
Porting is still difficult. But when we ported from Py2 to Py3, we found a couple issues like this (despite dealing with weird encodings all the time).
It has always seemed to me that Python 3 was mainly a fix on the philosophy of handling strings, but that it didn't offered a clear practical advantage for programmers already handling strings with care. I don't think there is a practical reason to upgrade to Python 3 in terms of language design. The reason will be in term of survival as the community seems to be willing to follow the Python 3 movement and official support for Python 2 ends in 2020.
There are a lot of reasons to upgrade! There is so much more useful stuff in python 3!
Even if you think you would not use those features, other libraries you may use might benefit a lot from it.
A few features: async/await, lists (and others) use iterators, no var leaking in list comprehensions, super().my_method() instead of super(MyClass, self).my_method(), class MyClass: instead of class MyClass(object):, improved exception handling, required arguments, ", ".join(["etc"]* 1000)
Besides that: a much improved standard library, although that technically not is language design.
ah well, it was just a geeky way to say etc etc etc.... no python3 stuff intended to be used there. Sorry :)
This one then, althoug it sort of works in python 2 as well..
That's pretty much true of any django release... you can stay on it if you so choose to. It will get security updates/bug fixes for a bit and then they will stop coming. You're free to stay where you are if you want.
It turns out that most developers have a desire to move to the next version if it's not too hard. There's still COBOL programmers out there too and that's perfectly fine.
Django has made the process as smooth as it can be. You can upgrade to python3 while maintaining your Django version. Then update to the next Django version as a separate step. It's fine to have waited until now. You can keep waiting if you want but it's getting to the point where you should really just do it. It's not so bad.
We switched and python2 --> python3 was bumpier and more work than most Django updates we've done (we've done pretty much every one since 1.0) but it was still entirely reasonable. We're much happier now.
My feeling is that you want to be using dependencies that are actively being maintained. These probably already support py3 - or there's a newer / maintained alternative available.
What's annoying is discovering that it's a struggle to upgrade to a newer OS because you're using some old python dependency that has some C component linking to some library that you're going to spend a week getting working (and then have to continue to maintain).
It sounds like you might not have too much trouble upgrading anyway. The strings and missing libs are the places most people get caught out and it sounds like you're already handling the worst of those.
If I were you, I'd try switching to python3 and see what breaks. When I did it, it took about a day to get up and running again on a reasonably complex project (numpy, scipy etc). One of the main things I ran into was places where python3 had swapped lists to generators etc (eg, some_dict.keys()[0] no longer works).
Can we expect the async/await introduced from Python 3 for async request handling or maybe some heavy operations ? Something like sanic: https://github.com/channelcat/sanic
This is the beginning of the Python 3 nonsense, not the end yet. It will end when the Python 3 joke is scrapped and replaced with Python 4 as a SEAMLESS continuation of Python 2.
So, after a poor evolution strategy that lead the Python world to be split in two and forces maintainers to offer two versions for the same library, and upstream maintainers to offer support for two different python versions, the same is happening for Django!
I speculate that the latest Django 1.x will remain used - and possibly the most used - for a lot, lot of time.
I disagree, I think Django dropping support for 2 will actually push more open source projects to do the same. This will create the momentum and incentive necessary to nudge people over the edge and upgrade.
There is an awful lot of hyperbole around the difficulty of upgrading from python 2 to 3, however with the latest changes in 2.7 and 3.6 the gap isn't as big as you expect. I converted our (admittedly not massive) 35,000loc Django project from 2 to 3 in about four hours, starting with with 2to3 tool then working though test failures it wasn't nearly as bad as I was expecting. Most of the issues were as I expected around the new string handling, but as soon as something broke, I knew before looking at the code what the problem was.
Agreed. We've got a ~100k line Django project and I'm fairly confident it won't be more than a day or so of work to migrate. The only thing keeping us on 2.x is our dependencies most of which already have Python 3 support so it's really just a matter of us upgrading dependencies.
> forces [...] to offer two versions [...] the same is happening for Django!
That's not what the announcement is about. Django worked with python 3.x for a long time already. Now they're actually going to drop 2.7, so back to one supported version.
No core Python dev will support Python 2 after EOL. Some corps may continue to do so sure, just like there are Java 1.4 codebases still in production. I will work on a Java 1.4 codebase if you are prepared to pay for my accrued personal obsolesce as well. If your Java 1.4 job is the last job I'll do it has to pay for the next 15 years lost income as well. The same will go for Python 2.
I think whatever goodies Django 2.x will have, they'll be backported to 1.x by somebody.
At my last job they were still using Django 1.6 when I quit last year. Updating to a new version takes a lot of manhours. Rewriting the codebase in a new language (which basically what Python 2 -> Python 3 transition is) would be completely out of the question.
Yep. I've done 1.6->1.7->1.8->1.9 at my current workplace and 1.6->1.7 with Django migrations was the biggest one by a long way. The documentation for upgrades is great too.
Python 3 is a seriously misguided project. It's got tons of newer-to-Python fans (your HN downvoter demographic), and tons of silent-majority "real-world" users especially in scientific programming who just don't like it. I moved to 3.4 a year ago and, as a data scientist, I have to say I find nothing in 3 to be better than 2, other than the extremely marginal default float arithmetic. I may be wrong for web development etc with asyncio whatever, but for me all I get from 3 is Unicode and xrange cruft that simply complicates my code for zero benefit. Personally am hoping that something new emerges that will take over from Python altogether as the default in data science, or that some big entity will sponsor a fork of 2.7 to shutdown this ridiculous "eol" dictatorship.
So what you're saying is that Python 3 changed some small stuff that you see no benefits in, but moved a year ago, and you're now on Py 3.4. And because of that small no-benefit update, you want to move to completely different language that will start with: no scientific libraries, no community, and will likely require rewrite of everything you work with?
the benefit is that all the wasted energy that went into all the useless 3.x stuff, could have been spent on advancing Python's speed, multicore, or GPU programming capabilities. Instead, for the single use case where Python is clearly the dominant language (for pure network-effect reasons), namely scientific programming, we have been at a standstill for years. In other words, under current stewardship, Python is going down a path where I don't see a long term future for it in my domain, and therefore, I am looking elsewhere already.
I am also almost 100% certain that if scientific programmers leave Python, the language will stall, and the current 3.x pushers are dangerously looking a gift horse in the mouth. This is particularly true given that Go is rapidly eating Python's lunch in all non-science use cases.
> I am also almost 100% certain that if scientific programmers leave Python, the language will stall, and the current 3.x pushers are dangerously looking a gift horse in the mouth.
This sounds like such similar sour grapes to the systemd escapades. Huge initial outroar as certain things happened, followed by a gradual diminishing, then [mostly] acceptance.
This is what is happening with Python 3 and a smaller, doom-and-gloom subset of the userbase. Most of us are thankful that Python is striving to improve, and that we continue to pay nothing to use it. The alarmists are far more noisy than those that are happily continuing to build stuff.
Python will remain massively used in the sciences. It's simple, easy to learn, expressive, and has an excellent ecosystem of modules (which now mostly work on Python 3).
>This sounds like such similar sour grapes to the systemd escapades. Huge initial outroar as certain things happened, followed by a gradual diminishing, then [mostly] acceptance.
Only here we don't have mere service scripts, but millions of lines of code people have written in perfectly fine 2.x Python.
And also here we don't have any significant uptake -- Python 2.x is still over 60% of what's used (according to PyPi stats and everything we've seen), and that's after 6+ years that Python 3 had its chances.
Except that personally I see the benefit of Systemd every time I boot my linux computer. It just works, fast, and clean. I don't partake in the philosophical arguments. I just want it to work. Py3 by contrast, simply throws cruft curveballs at me. No tangible benefit. This is not a systemd-style issue.
And yes Python will likely continue massively to be used in the sciences, 3 bears like me notwithstanding, so it would be good if the current stewards would actually recognize the fact that this is their core base of users and please could they focus on them instead of the web people who are much more fickle and moving already.
> core base of users and please could they focus on them instead of the web people who are much more fickle and moving already.
Ahhh, I see what's going on now. You may be vastly underestimating the size of variety of the Python userbase. This is one of the absolute most popular languages on the planet. Your science subset is but one of many. And it's not even the biggest if we're talking sheer user counts.
Python must be steered for the good of the majority of the userbase. Not just for vegabook. The fact that you described them as "useless" to me just speaks to someone being impatient and dismissive of a ton of excellent work by the contributors. These changes weren't made just for the hell of it. Particularly the Unicode example that you gave above.
If you want help understanding the rationale behind some of these changes, feel free to ask here. Someone with more familiarity will chime in and help clear up the confusion or angst.
Interesting that you're looking for those improvements in CPython. From your list (IMO): speed and multicore are going to stay where they are in CPython - GIL is unlikely to be removed, because it's basically part of the behaviour right now. There were a few attempts, but it seems nobody even tries anymore. (and I'm fine with that) Maybe pypy, grumpy, or others will do this instead.
I'm not sure why you expect GPU from the python itself though. That's completely up to libraries and they can exist for either 2.x or 3.x. Was there ever a CPython GPU related project?
The GIL is encoded into practically every C API of the interpreter. It's not going away in CPython, and at the very least any Python implementation supporting CPython extensions will have a global lock for calls into extensions.
And even if (there were patches for removing the GIL already around in the 90s): All of the approaches and patches shown so far significantly degraded single-threaded performance, which matters to way more applications than the GIL, which typically is not a significant limit to using multiple cores/processors.
"Teh GIL" is a very, very overblown issue, and is -- I don't want to be condescending here, but well -- usually brought up by people that have little experience writing software that makes effective use of multiple-many cores.
Yeah, you are a bit condescending here. Part of the topic was multicore. If you're interested in actually cutting down the data transfers without resorting to explicit shared memory, GIL and threads are very much on topic. Whether it's an overblown issue depends specifically on your workload and reasons why you're still using python if you care about multicore.
To me, unicode alone was worth the switch. I will go to great length to avoid the hell that is unicode in Python 2.
Besides speed, I never seen any good argument that would make me start a new project on 2.7, rather than the latest v3 release. I get that there was a series of data science libraries that wasn't supported initially, but seems to have been solved at this point. So I really do see why people continue to hate Python 3.
I'm not going to argue that the transition couldn't have been handled more smoothly, the period of broken libraries and terrible performance was a little too long.
If you don't care about the Python 3 features, then don't migrate. I suspect that the issue is that you want at least some of the features, but the cost of moving 10+ years of Python 2 to Python 3 just aren't worth the benefits of those new features.
While I do believe that your point is still valid, one also have to accept that Python 2 will be a legacy platform at some point. In the long run I don't view that as much different than people complaining about Visual Basic 6 being deprecated.
Python 3.0 was released in 2008. Python 2 will EOL in 2020. You've had about 9 years to start the transition to 3.0, and you still have 3 more years before EOL. A 12-year upgrade window sounds pretty reasonable.
>You've had about 9 years to start the transition to 3.0, and you still have 3 more years before EOL.
Most of those years library support was non-existent or lacking. And still today the majority uses Python 2.x (Pypi stats).
So it's not like the migration was some great success since the start, and all those years were just wasted by some minority not migrating.
In the end, it's not a discussion on HN or what the "BDFL" says about an official EOL that will settle the matter, but actual adoption in the field. But in addition to the low adoption rate, we've even seen people leave Python for Go and Node/JS.
I'm not seeing signs of these kinds of widespread issues out in the wild. The popularity of the language has continued to increase, and numerous warts and flaws were wiped out in Python 3.
That Unicode "cruft" is especially appreciated by the rest of the world that exists outside of the US. Python 2's approach to bytes and encoding is naive and horrible for 2017.
I'm outside of the US and Python 2 has worked wonderfully for ages. Its unicode support is good. You work with strings as unicode, then at I/O boundaries (and exceptions) you convert to bytes. What specifically do you find "naive and horrible" about its bytes and encodings?
Python 3 can use less memory for unicode strings (a cool optimization introduced in py3.3, IIRC), and it did away with the "narrow/wide build" distinction (same release). That's about the only every-day advantage I can think of. But I suspect that's too technical, or do you mean that?
For what it's worth, as someone who ha been working with Python for 11 years, Python 3 is a huge improvement over Python 2 and is certainly very popular with my peers.
The fact that you personally weren't particularly affected by the problems in 2 doesn't mean the problems weren't serious.
Please, don't tell me how "Python3 is good" - I know everything. I just still don't approve the way the transition was made - if we got to Python 3 through progressive deprecation and evolution via python 2.8 and 2.9, we wouldn't be where we are now.
The Django project has added Python 3 compatibility in Django 1.5 as experimental. It remained experimental in 1.6. It became supported in 1.7. They announced around that time that Django 2.0 would only support Python 3.
Then, they released a first 3.x compatible LTS with Django 1.8. Then they released 1.9, compatible with 3.4 and 3.5.
They then release 1.10. And they are releasing 1.11 soon as an LTS, which they previously announced would be the last in the 1.x branch and the last to support Python 2. It will be supported for AT LEAST THREE YEARS after its released.
Good lord. If the deprecation and evolution gets any more progressive, it'll compete with darwinism. And yet,
alanfranzoni complains about it. And YOU COMPLAIN ABOUT IT elsewhere in the thread, saying they're "screwing their userbase" and "leaving their users in the dust".
Don't you think you're being a little fricking entitled? This is an open source project and they're doing quite literally everything right.
I couldn't agree more. This transition and their release management in general has been handled excellently for years. Anyone complaining here is quite literally whining.
You talk as if Python 3 were a dialect of Lisp. It's still Python, looks like Python and feels like Python. In fact, I think most of my Python 3 code runs on Python 2.
The Python ecosystem would have been better served if they killed support for Python 2 much earlier, so that we can avoid wasting time on this tired debate, and more time writing useful code
Making the transition more "progressive" would just decrease the incentive of developers and companies to move even more.
Ultimately, they are the ones who maintain, care for Python and have grown the community to its current size. I totally respect their decision. Even if py3 was complete useless, I would just stop using python, not complain about how they are not doing things the way I like it.
What would you do in 2.8, 2.9 that 2.6, 2.7 didn't achieve? 3.0 was released almost at the same time as 2.6, and together with 2.7 they got a lot of backported 3.x functionality. Sounds like what you're asking for.
Pretty much the only people that are working towards splitting the community are people like you, who spread FUD and sprinkle snide, bitter and wrong remarks across threads.
Notice how I made a pragmatic observation (that it's already a fork), which one might agree or disagree with, and you went for name-calling about FUD, snide, bitter, "people like you", etc.
That's, like I said, my general observation from reading like a dozen comments from you just on this item. You're literally bickering on about this in pretty much every Python-related item on HN. It is very hard not to notice your comments if one frequents this site. I stand by my comment above.
>You're literally bickering on about this in pretty much every Python-related item on HN.
And others are bickering for the opposite opinion, so?
Did someone die and gave you authority on what others should think about Python 2 vs 3 transition?
>It is very hard not to notice your comments if one frequents this site.
I guess tolerating the presence of a counter opinion is hard.
That said, it's a open discussion, and the comments are not directed at you in any way. Maybe skip them if they upset you?
The problem is that Python 2 cannot evolve freely alongside Python 3, because even if someone wants to maintain it and keep releasing versions, the Python Software Foundation won't let them use the name Python (there was a post some weeks ago about someone who actually tried). So there is no free competition between 2 and 3. 2 has been basically killed by a decision from above.
Don't get me wrong, I'm no Python 3 hater. In fact, I have some projects in Python 3 and I would leave Python 2 if I could. But I, like many people, have to code stuff that has dependencies on Python 2, and the way they have handled the update bothers us for no good reason. In fact, the whole schism fiasco is making me use less Python and more Java, where my stone-age code still runs, lately.
Python 3 is not a fork. It is a major release. A continuation of the same language, by the same people, with very little change in the core concepts. A major release with some backward incompatibilities doesn't constitute a fork.
The previous version is being sunsetted, as is common for legacy software. By the time 2.7 is EOL'd, it will have enjoyed a decade of active development and maintenance. That's just one version of Python.
If there were a compelling enough argument for a fork, it would happen and a new name would be chosen. But alas, it makes very little sense for the wider world.
It's not difficult to write software that works with Python 2 and 3. It's just becoming less and less worth it, as evident by announcements like this Django 2.0 one. The scales have tipped towards Python 3.
The Python Software Foundation are the people who have earned the reputation that the name "Python" has - they're the ones who get to use it. And their judgement is that Python 3 is the future of Python. A fork under a different name can earn its own reputation based on the technical merits of its decisions.
Py2 or PyClassic. They don't own those, and they sure could link to python to py2/PyClassic for people who want to install it. They don't own the letters py.
Seriously? The entire change to "unsupport" the majority of Python code is a mass delete of from __future__ import unicode_literals and utf-8 encoding? Is that really the extent of the "too difficult to maintain" code? There will be a split.
Django was designed for making content based sites and CMS's quickly. It wasn't designed for webapps and REST APIs, and it can be used in those cases, but it's not great. I'd look at other options.
https://www.djangoproject.com/weblog/2015/jun/25/roadmap/
I've grow to highly respect the Django project for its good documentation, its healthy consideration for backwards compatibility, security, steady improvements and all round goodness.
reply