Using alpha software in production [was Re: Trying tcompile an use the Python 3.4a]
steve+comp.lang.python at pearwood.info
Thu Nov 14 03:00:41 CET 2013
On Thu, 14 Nov 2013 12:27:58 +1100, Chris Angelico wrote:
> On Thu, Nov 14, 2013 at 12:14 PM, Denis McMahon
> <denismfmcmahon at gmail.com> wrote:
>> Nobody is so stupid as to run alpha software on a production server
>> are they?
>>  In this context, "production server" means any system facing the
>> public internet upon which python code is executed in response to
>> inputs from the public internet.
Surely the answer to that is, "define stupid"?
What are the consequences of breakage? If the consequences are minor, why
wouldn't I use alpha software? Hypothetically speaking, even if the
machine were totally compromised, I might just shrug and rebuild it
(hopefully having reported the security vulnerability that allowed the
compromise, and having it fixed).
But specifically in this case, I agree with your implication, and
question the wisdom of the OP upgrading from a stable version of 3.3 to
an alpha version of 3.4.
> I don't know that that's necessarily stupid. For a lot of my work, I've
> been using a trunk version of Pike (7.9.11 currently), and if I were
> working more heavily with Python on my servers, I would consider using
> alpha versions if there were features that I wanted (or fixes that I
> needed). It's not stupid, but it does require a "hand on the tiller" so
> to speak; running alpha code - or, for that matter, any code you
> compiled yourself - in production means taking responsibility for it.
Yes, this! A master craftsman knows when to break the rules. I personally
would not run a public web app using alpha software because I know my
limitations, but I'm sure there are those who have both the skill to
manage it and the wisdom to know whether or not to risk it.
> I'm confident of my own ability to keep up with changes, but for most
> people, I would strongly recommend taking, in order: (1) the Python that
> your distro provides; (2) a python.org published stable version; (3) a
> preproduction (eg RC) version; and finally (4) anything else, including
> straight from Mercurial. The further down that list you go, the more
> work you have to do yourself to ensure compatibility, dependency
> management, etcetera.
More information about the Python-list