Hacker Newsnew | past | comments | ask | show | jobs | submit | aYsY4dDQ2NrcNzA's favoriteslogin

I highly recommend getting a continuous glucose monitor and wearing it for at least a few weeks. I was able to find a model at about $35/week, which required a prescription (US).

You can quickly get a good idea about how different foods and exercises affect your blood glucose. For me it was fun and motivating. It's helped a lot to put my diabetes into complete remission. The improvement in my daily quality of life is not subtle.

Since an improvement in your insulin levels can easily add healthy years to your life, it's worth doing even if you have no diagnosis of (pre)diabetes.


Interesting. I imagine what may have to happen is someone will (perhaps for profit) do all of the heavy lifting here so companies can use their server for old packages.

I get expecting that everyone will do this on their own, I just don’t think it will happen that way.


Would I have to do anything special aside from installing an older version? I’m not familiar with the back end of pip - in particular whether it talks to a package server or not.

If history tells us anything, the forcing function will come in the form of lots of noise once deployments begin to break.

Why won’t new deployments break? If they are using ‘pip’ to install 2.x libraries, my understanding is it will now fail.

edit: wrongness

It’s the closest example I could think of to draw on.

This is a good example of what I was talking about. Python 2.x isn’t “going away very quickly now.”


I have a background in systems engineering, working on a commercial operating system. I code in several languages. To me, it’s just a given that adoption extends the lifetime of something, even if it is not under active development. There’s a strange phenomenon with Python in particular, where it is upsetting for some reason to be told that Python 2.x will still be in use after we retire. To me this is just the natural way things work. There is so much stuff out there using Python 2.x where there’s no programmer around to do porting work and because things work, there’s no reason to invest. Normally when this sort of thing has happened to say, a language like VB, it doesn’t really matter because the end result is something compiled with a runtime. As long as the environment the app runs in has consistent behavior (app compat) there’s nothing to do. But with Python that isn’t precompiled you need the toolchain and dependencies. Python 2.x isn’t going anywhere, so I think Pip will ultimately have to keep and “freeze” support for Python 2.x, rather than not supporting it. If you are reading this and infuriated, perhaps ask some old hands you know, instead of taking my word for it. Flash is perhaps the closest example I can think of. Flash was “over” ages ago but browsers have had to keep support for an awful long time.

I give their decision a week before they revert and come up with an alternative.


You assume they will move forward, when they most likely won’t. It’s not a tax, it’s a product targeted at a guaranteed line of revenue. If 3.x were ever deprecated, they would start charging for that version. There probably aren’t enough users for their 3.x version yet, so it’s free to try and gain adoption.

That creates a good business model for someone to come along and charge a premium to fix security bugs in old code. I think it’s more likely something like that will happen, than everyone moving their code to work on 3.x.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: