Python/Django friendly webhost?

[CJones]

I'm currently on HostGator, and have been pretty happy with them up to this point (no 'CPU quota exceeded' problems like I had on BlueHost).

After reading through Joe's thread about different web scripting languages, I decided to look at Python/Django for the first time. I like its potential. I installed Python 2.6.6 and Django 1.2.3 on a box at work and started tinkering with it. I liked it enough that I thought I would re-do my personal site in Python as a learning project.

I checked cPanel for my HG account and it says they are running Python 2.4.3. I searched their tech forums to see if there was a way to get an upgrade and their (HostGator) basic stance is "don't expect any Python upgrades anytime soon". The only other issue I've ever had with HostGator was that they ran RoR through FastCGI instead of having a 'standard' Rails server running. It made it a pain to transfer the project I had built on a box at home to a 'live' server.

Can anyone recommend a more 'progressive' shared web hosting company? I understand that it is impossible to have the latest and greatest available for every language out there when doing shared hosting, but to be running a Python release from ?2005? seems a bit absurd, not to mention a fairly non-standard setup for RoR which is another popular - and growing - platform.

I don't do any large-scale web projects right now - just hosting my own personal website and my dad's two RV-build websites which he uses WordPress to manage, but I have aspirations to do some work on more 'commercial' web projects in the future.

Any suggestions?

 

[RJM62]

I think certain parts of CentOS and cPanel require the older version.

It's possible to install multiple python versions, but I don't know that I'd want to do that... My experiences with multiple versions in general have not always been joyful.

-Rich

 

[CJones]

I think certain parts of CentOS and cPanel require the older version.

It's possible to install multiple python versions, but I don't know that I'd want to do that... My experiences with multiple versions in general have not always been joyful.

-Rich

I think that was their basis for not upgrading - cPanel wouldn't "auto-install" the new version or something like that..

I downloaded Aptana Studio 3 which has built-in support for the Django framework. When creating a new Django project in AS3, you can choose which version of Python you want to use - I'm just wondering how difficult it will be to learn Python if all the tutorials are written for 2.6 and I'm developing on 2.4?

Eventually, I would like to get to my own dedicated box so I can put whatever the heck I want on it (read 'Screw it up in my own unique way'), but I don't have any sort of financial basis to support a venture like that right now.

And Ed, if you read this - No, I don't have a box at home that will support my own webserver with a static IP.

 

[RJM62]

I think that was their basis for not upgrading - cPanel wouldn't "auto-install" the new version or something like that..

I downloaded Aptana Studio 3 which has built-in support for the Django framework. When creating a new Django project in AS3, you can choose which version of Python you want to use - I'm just wondering how difficult it will be to learn Python if all the tutorials are written for 2.6 and I'm developing on 2.4?

Eventually, I would like to get to my own dedicated box so I can put whatever the heck I want on it (read 'Screw it up in my own unique way'), but I don't have any sort of financial basis to support a venture like that right now.

And Ed, if you read this - No, I don't have a box at home that will support my own webserver with a static IP.

It's not just that. There are a lot of things that hosting companies have to install from source. It's that removing the older version when upgrading will positively break stuff, including parts of CentOS itself (including yum, I think) and parts of cPanel. Again, it's possible to install both versions (calling the new version as python2.6x, for example), but I was strongly advised not to do so when I inquired.

Note that I had to research this for someone a while ago, so things may have changed since then.

Maybe you should consider a small VPS if you want something to break? They're pretty cheap these days, and most provide really easy restores from backup if you really hose the system.

-Rich

 

[jesse]

I think that was their basis for not upgrading - cPanel wouldn't "auto-install" the new version or something like that..

I downloaded Aptana Studio 3 which has built-in support for the Django framework. When creating a new Django project in AS3, you can choose which version of Python you want to use - I'm just wondering how difficult it will be to learn Python if all the tutorials are written for 2.6 and I'm developing on 2.4?

Eventually, I would like to get to my own dedicated box so I can put whatever the heck I want on it (read 'Screw it up in my own unique way'), but I don't have any sort of financial basis to support a venture like that right now.

And Ed, if you read this - No, I don't have a box at home that will support my own webserver with a static IP.

You can get a VPS for $20 a month. It's what I do for Angell Dev - http://www.linode.com

 

[1200AGL]

I use Google AppEngine for a low-traffic, mostly static site. We don't come anywhere near breaking the free quotas, so the price is right, but the environment is far more constrained than a VPS. I haven't had any problems, other than having to explain to people why they need to install software in order to push updates, but YMMV. There are APIs for Python or Java, and they support Django.

Google is still running Python 2.5.x on their server, because I believe their framework is based on the PyPy implementation. The storage API is a little bit strange: it is not a SQL database, but rather sits on top of BigTable. Migrating this site was the first web development I've done since 2000, so it was interesting to see some of the engineering decisions that Google made to expose Python web services to unwashed users in such a large-scale distributed system.

OK, back to the reading for tomorrow's flight lesson...

Paul

 

[ScottM]

Python has issue with upgrades. Not all upgrades are backwards compatible. If you have a bunch of stuff running on 2.6.4 upgrading to say version 3.1.1 will break a bunch of stuff. I am running both versions because I have scripts written under both versions.

 

[jesse]

Python has issue with upgrades. Not all upgrades are backwards compatible. If you have a bunch of stuff running on 2.6.4 upgrading to say version 3.1.1 will break a bunch of stuff. I am running both versions because I have scripts written under both versions.

Same thing is possible in PHP and many other platforms. At some point, in order to advance, you have to deprecate/change things. In general Python has done a good job of maintaining backwards compatibility but the 3.0 release was the first one to break that rule. There was plenty of time for developers to prepare for it - if a script/application broke - it was the fault of the developer.

 

[ScottM]

Same thing is possible in PHP and many other platforms. At some point, in order to advance, you have to deprecate/change things. In general Python has done a good job of maintaining backwards compatibility but the 3.0 release was the first one to break that rule. There was plenty of time for developers to prepare for it - if a script/application broke - it was the fault of the developer.

True but it seemed way worse on Python. When 2.6 came out I had to update a bunch of stuff that I had written in 1.4

As a user, it gets old real quick having to keep updating scripts that I need. I am not paid to keep software up to date. I am paid to produce ideas. Software is but a tool to me. Instead it is far easier to just run multiple versions of Python.

I understand updating new features. But there were somethings that changed in Python 3 that were just plain annoying.

A lot of the field engineers would be very annoyed when tools that they had written to help them troubleshoot equipment stopped functioning with an update to Python. The update delayed their real work while they had to either go back and re-write script or just upload the older version of Python. Which is what they did BTW which is why I mentioned it to Chris. Best intentions should be to move forward, but reality is that you should not break what is already working when there is no reason to upgrade.

 

[Areeda]

I have to say that is what I'd expect.

The way I read version numbers such as M.m.f:

M is a major version which is not compatible with M-1
m is an upgrade that is backward compatible with m-1 but contains features not in m-1
f is a bug fix with no new features.

I agree with Scott, if I have something working, I'd rather keep the old version around and keep using it instead of putting a lot of work to get it to do what it already did just fine, thank you very much.

I also try to do all development with the latest version. Which is what's frustrating me with CentOS these days.

Joe

 

[jesse]

True but it seemed way worse on Python. When 2.6 came out I had to update a bunch of stuff that I had written in 1.4

As a user, it gets old real quick having to keep updating scripts that I need. I am not paid to keep software up to date. I am paid to produce ideas. Software is but a tool to me. Instead it is far easier to just run multiple versions of Python.

I understand updating new features. But there were somethings that changed in Python 3 that were just plain annoying.

A lot of the field engineers would be very annoyed when tools that they had written to help them troubleshoot equipment stopped functioning with an update to Python. The update delayed their real work while they had to either go back and re-write script or just upload the older version of Python. Which is what they did BTW which is why I mentioned it to Chris. Best intentions should be to move forward, but reality is that you should not break what is already working when there is no reason to upgrade.

Software has to be maintained - if it's not maintained it's not going to work forever across upgrades. Someone needs to be responsible for maintaining production code and looking into the future to ensure things will be compatible. You're generally warned years in advance that someone is changing or your using deprecated functions/libraries.

This is the reason enterprise distributions like RHEL/CentOS/Ubuntu LTS exist. You get security upgrades for X years and can count on nothing changing that's going to break your production environment. Eventually support will someday come to an end and then you have to be ready to move onto the next long term support distribution. This works great for some users - less great for others that are on the "cutting-edge" of technology and need newer features.

There are "slower" moving languages where code will probably work much longer without maintenance. Something like Ruby/Python/PHP are not one of those. These are the things you look at when you choose to develop something in X language. If there was no intention of maintaining the code perhaps Python wasn't the best choice.

Considering how Python still maintains Python 2.7 they are giving people PLENTY of time to deal with 3.0 changes (yeaarrs).

 

[ScottM]

Software has to be maintained - if it's not maintained it's not going to work forever across upgrades. Someone needs to be responsible for maintaining production code and looking into the future to ensure things will be compatible. You're generally warned years in advance that someone is changing or your using deprecated functions/libraries.

This is the reason enterprise distributions like RHEL/CentOS/Ubuntu LTS exist. You get security upgrades for X years and can count on nothing changing that's going to break your production environment. Eventually support will someday come to an end and then you have to be ready to move onto the next long term support distribution. This works great for some users - less great for others that are on the "cutting-edge" of technology and need newer features.

You are talking about something different than I am. Not all code that is written is a product. A lot of code in the sciences, engineering world, and tech world is a local tools that facilitate troubleshooting, report generation, investigations, text mining, etc. That type of code needs to be supported in an enterprise or academic environment. If an update needs to be made it needs to be carefully coordinated with the users and not just mandated by the IT department.

I know there are production lines with tons of old HP-Basic/HPIB code. The products that run on that line are not using the code but all of the equipment that tests them are. Updating that code would do nothing but cost money without offering any improvement in production throughput. In a case like that you support the old code and avoid the update.

For production code and software products I agree with what you have written.

All I am saying for Chris' question is that he may not want to pull support for 2.6.4 so quickly. Check to see that his user group can deal with the upgrade before making the change. Just wanting the latest code support is not always the best reason for upgrading.

 

[jesse]

You are talking about something different than I am. Not all code that is written is a product. A lot of code in the sciences, engineering world, and tech world is local tools that facilitate troubleshooting, report generation, investigations, text mining, etc. That type of code needs to be supported in an enterprise or academic environment. If an update needs to be made it needs to be carefully coordinated with the users and not just mandated by the IT department.

I know there are production lines with tons of old HP-Basic/HPIB code. The products that run on that line are not using the code but all of the equipment that tests them are. Updating that code would do nothing but cost money without offering any improvement in production throughput. In a case like that you support the old code and avoid the update.

For production code and software products I agree with what you have written.

All I am saying for Chris' question is that he may not want to pull support for 2.6.4 so quickly. Check to see that his user group can deal with the upgrade before making the change. Just wanting the latest code support is not always the best reason for upgrading.

I agree Scott - what I'm saying - is that it's hard to fault Python for a newer version of their software which they've said will be incompatible for years for breaking scripts that weren't maintained when the newer version was installed.

I am aware of the scripts you speak of - but their dependencies still need to be known and taken into consideration throughout upgrades so that things don't break in the first place. If your business is depending on code, someone needs to be maintaining it and keeping an eye on the future. I don't care if an engineer in a lab wrote it, or the corporate IT programmer. If someone is not maintaining it and someone else upgrades Python (known to break the code for years) and it breaks the code and stops business then a mistake was made and it wasn't Python that made it.

 

[1200AGL]

True but it seemed way worse on Python. When 2.6 came out I had to update a bunch of stuff that I had written in 1.4

As a user, it gets old real quick having to keep updating scripts that I need. I am not paid to keep software up to date. I am paid to produce ideas. Software is but a tool to me. Instead it is far easier to just run multiple versions of Python.

I understand updating new features. But there were somethings that changed in Python 3 that were just plain annoying.

I feel your pain. In Python's defense, though, Guido did institute a moratorium on "all changes to the Python language syntax, semantics, and built-ins for a period of at least two years from the release of Python 3.1."

For me, until the Numpy and wxPython libraries support 3.x, I'm sticking with the 2.x releases.

 

[ScottM]

I feel your pain. In Python's defense, though, Guido did institute a moratorium on "all changes to the Python language syntax, semantics, and built-ins for a period of at least two years from the release of Python 3.1."

For me, until the Numpy and wxPython libraries support 3.x, I'm sticking with the 2.x releases.

I had heard that. I started writing some stuff in 3.1 but then starting having some compatibility issues with some modules I had written in 2.6.4 and did not have the time to rewrite, so I just went back to v 2.x releases

 

[steingar]

I think my python ate a django once.