Reason for not allowing import twice but allowing reload()

[Chris Angelico]

On Wed, Mar 2, 2016 at 8:53 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Mar 1, 2016 4:41 AM, "Chris Angelico" <rosuav at gmail.com> wrote:
>>
>> On Tue, Mar 1, 2016 at 10:18 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
>> > I cannot imagine why you would want to reload() in production code. That
>> > would imply that your production code is modifying already-imported
>> > modules, then wanting to import them again. Why would anyone in their
> right
>> > mind do that? Possibly because they lost a bet?
>>
>> BartC and I have both done this exact thing, though neither of us used
>> Python for it. It's not so insane as you might think; sometimes you
>> want to update code, but you don't want to restart a process. Just
>> because you've never had a process that hits a year of uptime doesn't
>> mean nobody else does. :)
>
> I have a hard time understanding the appeal of super-long uptimes. I'm not
> even comfortable running a single kernel version that long. What's so awful
> about 5 minutes of announced downtime in the middle of the night once a
> month while the system restarts?

It kicks connections off, which may not matter to web sites, but it
matters to servers that are designed for long-running connections. But
more importantly, five minutes once a month isn't enough to do all
your updates - so a live-update system would be required even with a
regular monthly reset. I tend to have announced outages for kernel
updates and such (eg a couple weeks ago), but in between, I want to be
able to keep everything going, even though I'm making changes.

Maybe I don't get to a year all that often (from memory, I think I've
just twice achieved >1y uptime), but I certainly have multi-day
uptimes, despite making changes multiple times a day. And I want to be
able to deploy changes in the middle of a game, not leave off until
the next scheduled downtime. So, yes, I need to be able to modify an
already-imported module.

ChrisA