Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing Python 2.x support from Django for version 2.0

github.com

Post reply on HN
Print view View original

261–270 of 413 posts

Re: Removing Python 2.x support from Django for version 2.0

#261

Post by tedmiston »

pmontra wrote: post #71
coldtea wrote: post #62

Earlier quoted context omitted.

> It's going to be more and more of a burden for the developers to maintain compatibility with a 7-year old version of Python. That's the version of Python that most of their users actually use -- with no major plans of mass updating.

But the Python developers will abandon v2 sooner or later, so IMHO it's wise to start following the bilingual development guidelines https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef and eventually upgrade to v3. What are the alternatives? Forking the language or switching to another language look to have a higher cost.

Guide announced at PyCon last year that Python 2's end of life is extended to 2020.

https://www.python.org/dev/peps/pep-0373/

Re: Removing Python 2.x support from Django for version 2.0

#262

Post by tedmiston »

ergo14 wrote: post #128
coldtea wrote: post #31

Earlier quoted context omitted.

> its healthy consideration for backwards compatibility Like screwing the huge majority of users with Python 2.x Django projects and having them update or be left behind?

Python 2.7 will not be maintained by PSF soon anyways.

The Python 2.x EOL was extended to 2020.

Re: Removing Python 2.x support from Django for version 2.0

#263

Post by rbistolfi »

metaphorm wrote: post #254
raverbashing wrote: post #66

Earlier quoted context omitted.

> instead of rethinking/refactoring. And breaking backwards compatibility Django is not RoR. Their users rely on being able to upgrade seamlessly. The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them

> there are some rough corners content_types, generic foreign keys, and basically any other uncommon use pattern for RDBMS are very rough in django. Tradeoff of their ORM being heavily streamlined for the 90% use cases (typical SQL selects and upserts).

But you can use other ORM if you want, or no ORM. However, the benefits of using Django come mostly from using their highly integrated components, I admit. In any case, we swapped the ORM with our own implementation of the data layer and we are doing fine. I like the API overall, specially class based views.

Re: Removing Python 2.x support from Django for version 2.0

#264

Post by tedmiston »

osullivj wrote: post #241
Siecje wrote: post #180

Earlier quoted context omitted.

I'm curious why 2.7.8? What is preventing you from using 2.7.9+?

2.7.8 was the latest 2.x when I built the current codebase. Currently I'm testing before a cloud launch. Fixing bugs in my product's functionality is a higher priority than porting to the latest 2.7

Python 2.7.9

Release Date: 2014-12-10

https://www.python.org/downloads/release/python-279/

Re: Removing Python 2.x support from Django for version 2.0

#265

Post by olau »

scrollaway wrote: post #86
nsomaru wrote: post #37

Earlier quoted context omitted.

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 a…

The template system is sometimes a pain, but sometimes the fact that it pushes you to move complexity out of the HTML and into Python code can make for more maintainable code in the long run. That's at least been my experience over the years.

Re: Removing Python 2.x support from Django for version 2.0

#266

Post by raverbashing »

metaphorm wrote: post #254
raverbashing wrote: post #66

Earlier quoted context omitted.

> instead of rethinking/refactoring. And breaking backwards compatibility Django is not RoR. Their users rely on being able to upgrade seamlessly. The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them

> there are some rough corners content_types, generic foreign keys, and basically any other uncommon use pattern for RDBMS are very rough in django. Tradeoff of their ORM being heavily streamlined for the 90% use cases (typical SQL selects and upserts).

Yes

Might be easier to just write SQL in those cases

Re: Removing Python 2.x support from Django for version 2.0

#267

Post by vegabook »

toyg wrote: post #216
vegabook wrote: post #39

Earlier quoted context omitted.

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 wou…

> core base of users Lol. Before Numpy and friends even existed, Python was used mostly by "the web people" and sysadmins. Scientists are one of a number of Python constituencies, and not even the best-paying nor most visible one.

rofl! Numeric was started in 1995.

Re: Removing Python 2.x support from Django for version 2.0

#268

Post by tedmiston »

squeaky-clean wrote: post #230
faitswulff wrote: post #199

Earlier quoted context omitted.

What critical packages still need to be ported to Python 3? Might be a fun project if they're open source.

For me, the google api client libraries, and AWS Lambda. That last one isn't totally Django related, but we use it for certain service calls, and it'd be nicer to be able to maintain one version of the language across the django app and related services. We ended writing a service in PHP to use Google's APIs, and are mostly using Scala or JS instead of Python for the Lambda services because this project is basically…

I agree on Lambda.

There's a "hack" of running Python 3 on AWS Lambda via subprocess until it's officially supported.

http://stackoverflow.com/questions/36143563/using-python-3-w...

Re: Removing Python 2.x support from Django for version 2.0

#269

Post by olau »

nodamage wrote: post #75

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 act…

Well, there are some new nifty things, e.g. not having to write u in front of every string or a more pleasant subprocess API or the fact that dicts in 3.6 keep their insertion order which makes debugging a bit easier. It adds up.

But the big one is that Python 2.7 will go away at some point.

Re: Removing Python 2.x support from Django for version 2.0

#270

Post by sirn »

mangeletti wrote: post #198
ergo14 wrote: post #126

Earlier quoted context omitted.

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.

I always expected Pyramid to offer some performance benefits over Django, given the origins (taking the best of framework X and Y), esp given that you can choose your own ORM (e.g., SQLAlchemy), etc. However, once you're out of the unrealistic scenarios (single query benchmarks, etc.), it doesn't do that well[1]. It's not prohibitively slow, but to make the jump from something as well documented and with as large a c…

> However, once you're out of the unrealistic scenarios (single query benchmarks, etc.), it doesn't do that well[1].

I'm curious about the result since it didn't matched my experience. So I proceed to take a look at the source code for both Pyramid's[1] and Django's[2] benchmarks. From the look of it, I feel like there are too much difference in implementation to call this a realistic comparison.

From a quick glance, Django's benchmark seems to contain a little bit of micro-optimization and is rendering JSON response directly with uJSON[3] (which looks to be a lot faster than native JSON module)[4], while Pyramid's benchmark did not seems to go through any optimizations and is returning a list of SQLAlchemy objects that get passed into a custom renderer[5]¹ and render using native JSON module.

So I don't think it's entirely fair to say Pyramid is slow in a real world scenario based on this benchmark alone.

[1]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/c8a5...

[2]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/c8a5...

[3]: https://pypi.python.org/pypi/ujson

[4]: http://artem.krylysov.com/blog/2015/09/29/benchmark-python-j...

[5]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/c8a5...

¹ Using pyramid.renderers.JSON here probably make more sense, but to match Django's implementation, one can wrap a serialized JSON into `Response` object.

Post reply on HN