Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #103686 > unrolled thread

Reason for not allowing import twice but allowing reload()

Back to article view | Back to comp.lang.python

Contents

  Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-02-28 22:40 -0800
    Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-02-29 18:01 +1100
      Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-01 22:18 +1100
        Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-03-01 22:39 +1100
          Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-02 04:11 +1100
            Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-03-02 05:04 +1100
        Re: Reason for not allowing import twice but allowing reload() Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-01 14:53 -0700
        Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-03-02 09:02 +1100
        Re: Reason for not allowing import twice but allowing reload() Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-01 15:29 -0700
          Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-02 12:19 +1100
            Re: Reason for not allowing import twice but allowing reload() Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-01 19:22 -0700
              Re: Reason for not allowing import twice but allowing reload() Rustom Mody <rustompmody@gmail.com> - 2016-03-02 02:15 -0800
                Re: Reason for not allowing import twice but allowing reload() Rustom Mody <rustompmody@gmail.com> - 2016-03-02 02:19 -0800
              Re: Reason for not allowing import twice but allowing reload() Grant Edwards <invalid@invalid.invalid> - 2016-03-02 15:15 +0000
        Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-03-02 11:13 +1100
    Re: Reason for not allowing import twice but allowing reload() Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-29 00:02 -0700
    Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-02-29 18:11 +1100
      Re: Reason for not allowing import twice but allowing reload() BartC <bc@freeuk.com> - 2016-02-29 15:33 +0000
        Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-03-01 03:05 +1100
    Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Rustom Mody <rustompmody@gmail.com> - 2016-02-29 04:42 -0800
      Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Terry Reedy <tjreedy@udel.edu> - 2016-03-01 01:52 -0500
        Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Rustom Mody <rustompmody@gmail.com> - 2016-03-02 07:22 -0800
          Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Terry Reedy <tjreedy@udel.edu> - 2016-03-02 21:40 -0500
            Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Rustom Mody <rustompmody@gmail.com> - 2016-03-02 20:07 -0800
              Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Rustom Mody <rustompmody@gmail.com> - 2016-03-02 20:17 -0800
    Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-02-29 05:00 -0800
    Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-02-29 05:22 -0800
      Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-02-29 05:25 -0800
        Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-02 04:00 +1100
          Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-03-05 04:51 -0800
            Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-10 00:53 +1100
      Reason for not allowing import twice but allowing reload() Rustom Mody <rustompmody@gmail.com> - 2016-02-29 05:51 -0800
        Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-02-29 07:13 -0800
      Re: Reason for not allowing import twice but allowing reload() Terry Reedy <tjreedy@udel.edu> - 2016-03-01 02:04 -0500
    Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-03-06 00:20 -0800
      Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-07 01:50 +1100
    Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-03-06 00:31 -0800

Page 1 of 2  [1] 2  Next page →

#103686 — Reason for not allowing import twice but allowing reload()

Hello list,

We can not import a module twice in a session of Python (subsequent attempts to import same module don't result in any error though, but it is not-effective).

However after making change to module, we can reload() it (if not reload(), we could possibly have reimport statement) to get the updates in module.

I am a newbie in Python (learning via IDLE) and trying to understand

- what is extra (special) that import does, that reload() doesn't?
- if both do the same internally and externally, why subsequent imports of same module are ineffective?
- if subsequent imports of same module in a session are not effective, why not simply flag those attempts as an error, rather than letting them go effect-less.

Kindly help me understand the reasons behind.

Regards
Sandeep

[toc] | [next] | [standalone]

#103687

On Mon, Feb 29, 2016 at 5:40 PM,  <alien2utoo@gmail.com> wrote:
> We can not import a module twice in a session of Python (subsequent attempts to import same module don't result in any error though, but it is not-effective).
>
> However after making change to module, we can reload() it (if not reload(), we could possibly have reimport statement) to get the updates in module.
>
> I am a newbie in Python (learning via IDLE) and trying to understand
>
> - what is extra (special) that import does, that reload() doesn't?
> - if both do the same internally and externally, why subsequent imports of same module are ineffective?
> - if subsequent imports of same module in a session are not effective, why not simply flag those attempts as an error, rather than letting them go effect-less.
>
> Kindly help me understand the reasons behind.

Normally, you import a module because you want its features. For
instance, you can "import re" to get access to the Regular Expression
parser, or "import pandas" to load up the rather hefty third-party
numerical computation/analysis library of that name. Sometimes, this
can take a lot of work - importing pandas loads several hundred
modules in total, and can take a second or two, if it's not already in
the OS's disk cache. (Even if it is in cache, it takes a visible pause
- maybe 100-300 ms.) If two parts of your project need the same
module, it's way more efficient to make use of the already-loaded
module.

Additionally, sometimes it makes a lot of difference, and you _want_
to use the same module. When you "import sys", you absolutely must
access the same sys module that everyone else does; otherwise,
changing sys.stdout or sys.path wouldn't have any effect. And
depending on how it's implemented, sys.intern could create very subtle
bugs if you had two versions of it around.

So here's what happens (massively oversimplified) when you "import modulename":

1) Is modulename in sys.modules? If so, return that.
2) Step through sys.path, looking for the module. Can't find it? ImportError.
3) Run that program and create a module object. Put it into
sys.modules, and return it.

You can test that first step fairly easily:

>>> sys.modules["asdf"]="Haha"
>>> import asdf
>>> asdf
'Haha'

As a general rule, this is what you want (apart from sticking strings
into sys.modules, which is a VERY strange thing to do!). In fact, I
would recommend never using reload() unless you're absolutely sure of
what it does and how it's important. I've never used reload() in any
production code, ever. Ever.

The reason that repeating the import isn't flagged as an error is that
it's simply an assignment. If you write this code, Python won't warn
you:

>>> os = sys.modules["os"]
>>> os = sys.modules["os"]
>>> os = sys.modules["os"]
>>> os = sys.modules["os"]

Yet this is effectively what "import os" does. It's assignment, just
like any other assignment operation.

I believe it is theoretically possible to ask Python to give you a
warning (using an import hook), but generally, you should think about
imports simply as assignment.

ChrisA

[toc] | [prev] | [next] | [standalone]

#103787

On Mon, 29 Feb 2016 06:01 pm, Chris Angelico wrote:

> I've never used reload() in any production code, ever. Ever.


reload() isn't intended for production code. It is a convenience for
interactive use.

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?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103788

On Tue, Mar 1, 2016 at 10:18 PM, Steven D'Aprano <steve@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. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#103804

On Tue, 1 Mar 2016 10:39 pm, Chris Angelico wrote:

> On Tue, Mar 1, 2016 at 10:18 PM, Steven D'Aprano <steve@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've had an uptime of over 400 days on my laptop, without logging out, so
yes I have had processes with over a year of uptime. But that doesn't mean
I expect to modify the code of a running process and reload it. Modify
data, sure, but not code.

I'll grudgingly accept that, just maybe, if you have some sort of plugin
system, you may want to unload and reload plugins, replacing the old plugin
with a new one of the same name. Maybe you could get that to work in Python
using the import system.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103808

On Wed, Mar 2, 2016 at 4:11 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 1 Mar 2016 10:39 pm, Chris Angelico wrote:
>
>> On Tue, Mar 1, 2016 at 10:18 PM, Steven D'Aprano <steve@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've had an uptime of over 400 days on my laptop, without logging out, so
> yes I have had processes with over a year of uptime. But that doesn't mean
> I expect to modify the code of a running process and reload it. Modify
> data, sure, but not code.
>
> I'll grudgingly accept that, just maybe, if you have some sort of plugin
> system, you may want to unload and reload plugins, replacing the old plugin
> with a new one of the same name. Maybe you could get that to work in Python
> using the import system.

And then you expand the plugin system so it includes everything other
than a kernel that manages plugins, and you now have the kind of
system I'm talking about. My MUD server and client are both structured
like this:

1) Startup file, which does basic setup, initializes all other files,
then (in the server) binds to a port and starts listening. It then
drops to a back-end loop, either threaded or async I/O.
2) Globally-available utilities toolbox. Can be reloaded to add or
edit any of the functions/classes in it.
3) (Client only) GUI handling file. Creates the window, handles user
interaction. Can be reloaded, although since it doesn't destroy and
recreate the window, some changes won't take effect until full
restart.
4) All other plugins, which can do pretty much anything. The system is
quite happy to add, remove, and update these at any time.

Everything except the startup file can be edited after startup. That's
basically _every_ piece of code in the whole project. Major features
can be implemented and debugged without resetting anything, and once
I'm satisfied with the code, I commit and push, and end users can pull
that change without restarting.

If I were to implement this in Python, I would probably do it by
reimplementing module-like behaviour, rather than actually using
import. But it could be made to work, and it definitely has its
benefits. On the server, it's crucial - I can't kick my users off
every time I make changes; even on the client, having to restart and
reconnect for every change would be tedious, although that's more for
my own debugging than for other people's usage (it's not as big a deal
to update the program once a week and then have to restart).

ChrisA

[toc] | [prev] | [next] | [standalone]

#103822

On Mar 1, 2016 4:41 AM, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> On Tue, Mar 1, 2016 at 10:18 PM, Steven D'Aprano <steve@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?

[toc] | [prev] | [next] | [standalone]

#103823

On Wed, Mar 2, 2016 at 8:53 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mar 1, 2016 4:41 AM, "Chris Angelico" <rosuav@gmail.com> wrote:
>>
>> On Tue, Mar 1, 2016 at 10:18 PM, Steven D'Aprano <steve@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

[toc] | [prev] | [next] | [standalone]

#103824

On Tue, Mar 1, 2016 at 3:02 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Mar 2, 2016 at 8:53 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> 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.

I certainly understand the value of being able to work on a mudlib
without having to restart the mud. There's a big difference between
that and clocking a year of uptime just because you can, though.

The MUD that I used to play had scheduled restarts every 2-4 weeks,
not to perform updates, but just to restart the process and clear out
memory leaks. This never caused any real problem. You knew that it was
coming because it was announced, and you took a break for a couple of
minutes. If you were AFK, then your auto-login script reconnected you
within shortly after the MUD came back up.

[toc] | [prev] | [next] | [standalone]

#103827

On Wed, 2 Mar 2016 09:29 am, Ian Kelly wrote:

> There's a big difference between
> that and clocking a year of uptime just because you can, though.

What other reason is there for having a year of uptime?

It's not like it is difficult. My laptop doesn't actually go anywhere: for
historical reasons, it's a laptop but it is (mostly) used as a desktop. It
sits on my desk. If there's a power outage, the handy built-in UPS
(battery) keeps it alive for an hour or two. I come in, I nudge the mouse
to wake xscreensaver and authenticate; I do my work; then I run
xscreensaver to lock the screen and leave.

If I need access to something from home, I can SSH into the office network,
and from there into the laptop.

The OS is as stable as the surface of the moon, and simply doesn't crash or
go down ever. (If only Firefox was as good, alas, but when it does crash it
is nearly always because I've allowed Javascript to run on some popular,
multimedia-rich, information-free website.) I don't reboot because I don't
need to reboot. Why would you reboot just for the sake of rebooting?

When I unlock the screen, my system is usable *instantly*. I don't have to
open a dozen applications, wait for them to load, authenticate into half a
dozen different systems. They're already open.

About once a year, or every 18 months or so, I need to reboot to go into
Windows. If not for that, and the occasional kernel update, I'd probably
never reboot.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103832

On Tue, Mar 1, 2016 at 6:19 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Wed, 2 Mar 2016 09:29 am, Ian Kelly wrote:
>
>> There's a big difference between
>> that and clocking a year of uptime just because you can, though.
>
> What other reason is there for having a year of uptime?
>
> It's not like it is difficult. My laptop doesn't actually go anywhere: for
> historical reasons, it's a laptop but it is (mostly) used as a desktop. It
> sits on my desk. If there's a power outage, the handy built-in UPS
> (battery) keeps it alive for an hour or two. I come in, I nudge the mouse
> to wake xscreensaver and authenticate; I do my work; then I run
> xscreensaver to lock the screen and leave.
>
> If I need access to something from home, I can SSH into the office network,
> and from there into the laptop.
>
> The OS is as stable as the surface of the moon, and simply doesn't crash or
> go down ever. (If only Firefox was as good, alas, but when it does crash it
> is nearly always because I've allowed Javascript to run on some popular,
> multimedia-rich, information-free website.) I don't reboot because I don't
> need to reboot. Why would you reboot just for the sake of rebooting?

Software updates? The nice thing about *nix systems is that *most*
updates don't require a reboot. I'm still going to reboot any time
there's a kernel update though, and those are fairly frequent. I could
read the patch notes to determine whether this new kernel version is
actually important, but it takes less of my time just to go ahead and
reboot.

With my company-owned Macbook Air, the security policy will eventually
schedule a *forced* reboot when there are "critical" updates to be
installed. Thankfully the scheduler is pretty good about making sure
it's not catching the user at an inopportune moment.

[toc] | [prev] | [next] | [standalone]

#103854

On Wednesday, March 2, 2016 at 7:53:10 AM UTC+5:30, Ian wrote:
> On Tue, Mar 1, 2016 at 6:19 PM, Steven D'Aprano wrote:
> > On Wed, 2 Mar 2016 09:29 am, Ian Kelly wrote:
> >
> >> There's a big difference between
> >> that and clocking a year of uptime just because you can, though.
> >
> > What other reason is there for having a year of uptime?
> >
> > It's not like it is difficult. My laptop doesn't actually go anywhere: for
> > historical reasons, it's a laptop but it is (mostly) used as a desktop. It
> > sits on my desk. If there's a power outage, the handy built-in UPS
> > (battery) keeps it alive for an hour or two. I come in, I nudge the mouse
> > to wake xscreensaver and authenticate; I do my work; then I run
> > xscreensaver to lock the screen and leave.
> >
> > If I need access to something from home, I can SSH into the office network,
> > and from there into the laptop.
> >
> > The OS is as stable as the surface of the moon, and simply doesn't crash or
> > go down ever. (If only Firefox was as good, alas, but when it does crash it
> > is nearly always because I've allowed Javascript to run on some popular,
> > multimedia-rich, information-free website.) I don't reboot because I don't
> > need to reboot. Why would you reboot just for the sake of rebooting?
> 
> Software updates? The nice thing about *nix systems is that *most*
> updates don't require a reboot. I'm still going to reboot any time
> there's a kernel update though, and those are fairly frequent. I could
> read the patch notes to determine whether this new kernel version is
> actually important, but it takes less of my time just to go ahead and
> reboot.

Dunno what systems you folks use...
My ubuntu(s) 15.10 seem to (my estimates not hard data)
- update every couple of days
- kernel/security updates every 2-3 weeks

"Stable as the surface of the moon"??
Well thats strong
The other day I 
- aptitude purge-d the kernel I was running on
  [I was trying to show off to someone that ubuntu would not allow that!]
- machine kept running merrily but thereafter aptitude crashed
- Until I rebooted an older kernel; installed the one I had removed and rebooted to that

[toc] | [prev] | [next] | [standalone]

#103856

On Wednesday, March 2, 2016 at 3:45:28 PM UTC+5:30, Rustom Mody wrote:
> On Wednesday, March 2, 2016 at 7:53:10 AM UTC+5:30, Ian wrote:
> > On Tue, Mar 1, 2016 at 6:19 PM, Steven D'Aprano wrote:
> > > On Wed, 2 Mar 2016 09:29 am, Ian Kelly wrote:
> > >
> > >> There's a big difference between
> > >> that and clocking a year of uptime just because you can, though.
> > >
> > > What other reason is there for having a year of uptime?
> > >
> > > It's not like it is difficult. My laptop doesn't actually go anywhere: for
> > > historical reasons, it's a laptop but it is (mostly) used as a desktop. It
> > > sits on my desk. If there's a power outage, the handy built-in UPS
> > > (battery) keeps it alive for an hour or two. I come in, I nudge the mouse
> > > to wake xscreensaver and authenticate; I do my work; then I run
> > > xscreensaver to lock the screen and leave.
> > >
> > > If I need access to something from home, I can SSH into the office network,
> > > and from there into the laptop.
> > >
> > > The OS is as stable as the surface of the moon, and simply doesn't crash or
> > > go down ever. (If only Firefox was as good, alas, but when it does crash it
> > > is nearly always because I've allowed Javascript to run on some popular,
> > > multimedia-rich, information-free website.) I don't reboot because I don't
> > > need to reboot. Why would you reboot just for the sake of rebooting?
> > 
> > Software updates? The nice thing about *nix systems is that *most*
> > updates don't require a reboot. I'm still going to reboot any time
> > there's a kernel update though, and those are fairly frequent. I could
> > read the patch notes to determine whether this new kernel version is
> > actually important, but it takes less of my time just to go ahead and
> > reboot.
> 
> Dunno what systems you folks use...
> My ubuntu(s) 15.10 seem to (my estimates not hard data)
> - update every couple of days
> - kernel/security updates every 2-3 weeks
> 
> "Stable as the surface of the moon"??
> Well thats strong
> The other day I 
> - aptitude purge-d the kernel I was running on
>   [I was trying to show off to someone that ubuntu would not allow that!]
> - machine kept running merrily but thereafter aptitude crashed
> - Until I rebooted an older kernel; installed the one I had removed and rebooted to that

Right now as I write this a libssl security update.
No suggested reboot
But I should be rebooting if I were paranoid about security

[toc] | [prev] | [next] | [standalone]

#103876

On 2016-03-02, Ian Kelly <ian.g.kelly@gmail.com> wrote:

> Software updates? The nice thing about *nix systems is that *most*
> updates don't require a reboot. I'm still going to reboot any time
> there's a kernel update though, and those are fairly frequent. I could
> read the patch notes to determine whether this new kernel version is
> actually important, but it takes less of my time just to go ahead and
> reboot.

I try to remember to reboot every couple weeks or so even without a
kernel update.  There sometimes updates to things like the "rc" stuff
or udev or whatnot which occasionally cause boot-time problems.  If
you let too much time go by between reboots, and something that
happend several months ago is going to cause a problem at boot time,
that reboot is guaranteed to happen when it's the most inconvenient.
And it's a lot easier to figure out the problem when it's due to a
recent update.

> With my company-owned Macbook Air, the security policy will
> eventually schedule a *forced* reboot when there are "critical"
> updates to be installed. Thankfully the scheduler is pretty good
> about making sure it's not catching the user at an inopportune
> moment.


-- 
Grant Edwards               grant.b.edwards        Yow! Let's all show human
                                  at               CONCERN for REVERAND MOON's
                              gmail.com            legal difficulties!!

[toc] | [prev] | [next] | [standalone]

#103826

On Wed, Mar 2, 2016 at 9:29 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> I certainly understand the value of being able to work on a mudlib
> without having to restart the mud. There's a big difference between
> that and clocking a year of uptime just because you can, though.

Oh, sure. I mentioned the year because I have done that once or twice,
but it's the week, rather than the year, that's truly important. If
something came up that meant I absolutely had to reset everything on a
six-monthly basis, no big deal (although I'd rather not have a reset
every month).

> The MUD that I used to play had scheduled restarts every 2-4 weeks,
> not to perform updates, but just to restart the process and clear out
> memory leaks. This never caused any real problem. You knew that it was
> coming because it was announced, and you took a break for a couple of
> minutes. If you were AFK, then your auto-login script reconnected you
> within shortly after the MUD came back up.

Yeah, and I play one that has semi-scheduled restarts about every 6-10
weeks, for similar reasons (and also for game balance reasons; they
deliberately don't save gear across restarts, so people have to gather
new gear). I haven't had issues with memory leaks on my server, but
it's relatively low traffic. Again, though, if it turned out (under
heavier load) that periodic restarts were important, I could design
around that requirement, but there's no way I could design around a
model of "weekly downtime as the only way to change anything", the way
games like Magic: The Gathering Online do. I've once seen them have to
do an emergency out-of-band patch - and it took them an hour or
something of outage to do it. Unacceptable in my book.

ChrisA

[toc] | [prev] | [next] | [standalone]

#103688

On Sun, Feb 28, 2016 at 11:40 PM,  <alien2utoo@gmail.com> wrote:
> Hello list,
>
> We can not import a module twice in a session of Python (subsequent attempts to import same module don't result in any error though, but it is not-effective).
>
> However after making change to module, we can reload() it (if not reload(), we could possibly have reimport statement) to get the updates in module.
>
> I am a newbie in Python (learning via IDLE) and trying to understand
>
> - what is extra (special) that import does, that reload() doesn't?

When you import a module, it's cached in the sys.modules dict.
Subsequent imports of the same module find the cached module rather
than reimport it. However, reload() ignores the cache and always
reloads the module.

> - if subsequent imports of same module in a session are not effective, why not simply flag those attempts as an error, rather than letting them go effect-less.

Because there are legitimate reasons for importing the same module
multiple times. For example, I have a script that imports the sys
module. It also imports the os module, which imports the sys module.
Both the main module of my script and the os module have need of the
sys module, so they both import it. If subsequent imports of the
module raised an exception, this wouldn't be possible.

However, they shouldn't get two separate copies of the sys module,
because that would be wasteful and potentially error-prone if the
module is stateful In the case of the sys module, there is state --
the sys.modules cache that I mentioned earlier. Imagine the confusion
if two separate imports of the sys module resulted in two separate
instances with two separate caches of imported modules that were in
disagreement.

[toc] | [prev] | [next] | [standalone]

#103689

On Mon, Feb 29, 2016 at 6:02 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> - if subsequent imports of same module in a session are not effective, why not simply flag those attempts as an error, rather than letting them go effect-less.
>
> Because there are legitimate reasons for importing the same module
> multiple times. For example, I have a script that imports the sys
> module. It also imports the os module, which imports the sys module.
> Both the main module of my script and the os module have need of the
> sys module, so they both import it. If subsequent imports of the
> module raised an exception, this wouldn't be possible.

I think the OP's talking more about the situation of having an active
session (IDLE was mentioned), importing a local module (a .py file
from the current directory), then editing the file and re-importing,
which has no effect. While I am sympathetic to the problem, I don't
believe the language should be changed here; what might be useful is
something that notices that an already-loaded module is now out of
date, but really, the best solution is a change of workflow that no
longer has long-running modules loading live-updated code. I would,
instead, run a short-lived module and simply restart it after any edit
(possibly dropping to interactive mode at the end). Save, restart.
Save, restart. Python isn't optimized for the "keep running but change
code" execution model (for that, use Pike, and pay the complexity
overhead).

ChrisA

[toc] | [prev] | [next] | [standalone]

#103720

On 29/02/2016 07:11, Chris Angelico wrote:
> On Mon, Feb 29, 2016 at 6:02 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>> - if subsequent imports of same module in a session are not effective, why not simply flag those attempts as an error, rather than letting them go effect-less.
>>
>> Because there are legitimate reasons for importing the same module
>> multiple times. For example, I have a script that imports the sys
>> module. It also imports the os module, which imports the sys module.
>> Both the main module of my script and the os module have need of the
>> sys module, so they both import it. If subsequent imports of the
>> module raised an exception, this wouldn't be possible.
>
> I think the OP's talking more about the situation of having an active
> session (IDLE was mentioned), importing a local module (a .py file
> from the current directory), then editing the file and re-importing,
> which has no effect. While I am sympathetic to the problem, I don't
> believe the language should be changed here; what might be useful is
> something that notices that an already-loaded module is now out of
> date, but really, the best solution is a change of workflow that no
> longer has long-running modules loading live-updated code.

Not in Python (this was pre-Python actually) but I once used such a 
technique all the time.

The main set of modules would be running a GUI application which also 
had a command line.

Some commands included editing, compiling [a discrete step] and running 
modules of the application that were under development. Then you had a 
very fast edit-run cycle for those modules without having to restart the 
entire application, and possibly reload the graphical data that was 
under test (which could be large), or having to do any other set-ups 
required for the test.

(Another reason in those days was that not all modules would fit into 
memory at once and a module could be unloaded once it had finished (in 
Python terms, running off the end of the module) to make room for another.)

What I'm saying is, you shouldn't dismiss something just because you 
can't think of enough uses for it.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#103725

On Tue, Mar 1, 2016 at 2:33 AM, BartC <bc@freeuk.com> wrote:
>> I think the OP's talking more about the situation of having an active
>> session (IDLE was mentioned), importing a local module (a .py file
>> from the current directory), then editing the file and re-importing,
>> which has no effect. While I am sympathetic to the problem, I don't
>> believe the language should be changed here; what might be useful is
>> something that notices that an already-loaded module is now out of
>> date, but really, the best solution is a change of workflow that no
>> longer has long-running modules loading live-updated code.
>
>
> Not in Python (this was pre-Python actually) but I once used such a
> technique all the time.
>
> The main set of modules would be running a GUI application which also had a
> command line.

I use this technique all the time, in current code. But not in Python.
The main reason is to have a server that permits clients to connect
and remain connected, and to update code in ways that affect those
connected clients. So by definition, I can't restart the server (it
would drop the connections), and the critical main loop doesn't
reload, but all the rest of the code does. It's pretty much the same
style you had.

Doing the same thing in Python would probably best be done using
"exec" rather than "import". It'd work, but you'd have to
differentiate in code between "load this module which can be reloaded"
and "import this module from the standard library" (where the latter
would be the regular "import" statement).

ChrisA

[toc] | [prev] | [next] | [standalone]

#103701 — Correct IDLE usage (was Reason for not allowing import twice but allowing reload())

On Monday, February 29, 2016 at 12:10:28 PM UTC+5:30, alien2utoo wrote:
> Hello list,
> 
> We can not import a module twice in a session of Python (subsequent attempts to import same module don't result in any error though, but it is not-effective).
> 
> However after making change to module, we can reload() it (if not reload(), we could possibly have reimport statement) to get the updates in module.
> 
> I am a newbie in Python (learning via IDLE) and trying to understand
>


Hi and welcome!
 

> - what is extra (special) that import does, that reload() doesn't?
> - if both do the same internally and externally, why subsequent imports of same module are ineffective?
> - if subsequent imports of same module in a session are not effective, why not simply flag those attempts as an error, rather than letting them go effect-less.
> 
> Kindly help me understand the reasons behind.

I guess Ian and Chris have answered well enough in a general way.

However I wonder at a more pragmatic level: 

Is import needed at all when trying out in Idle?

[Maybe Idle experts can comment...]

In more detail:

1. Start idle
2. Open new with Ctrl-n

3. Put the following into foo.py
-------------------
x = 3
def foo(y) : return x+y
-------------------

4. Load it into python with F5 (or Run-> Run_Module) And have this interaction

>>> ================================ RESTART ================================
>>> 
>>> x
3
>>> foo(2)
5

Note the restart

5. Switch back to foo.py and change the '+' to '*'; F5
>>> ================================ RESTART ================================
>>> 
>>> foo(2)
6

SO THE CHANGE IS EFFECTED

6. Yes there is a difference between importing and 'F5-ing'; 
   To see that I add to bottom of foo.py

if __name__ == '__main__':
    print "if"
else:
    print "else"        

7. Now with F5:
>>> ================================ RESTART ================================
>>> 
if

 Whereas with import:

>>> import foo
else
>>> 

So it does appear that
1. import not necessary with(in) idle
2. However import and f5 (ie is run as main) are different

May some idle experts elaborate on this? Whats the idle idiom of import-ing?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web