Are you so sure __import__() always reloads? I don't believe so, and
that is also why there is a built-in reload(). At least __import__()
does not reload in my following simple test. Jose, would you please
also try this one?
# myapp/modules/foo.py
def bar():
return 'hello world'
# myapp/controllers/test.py
def index():
return local_import('foo', reload=True)
Visit http://localhost:8000/myapp/test and you will see "hello world".
Fine. Don't restart web2py, now change bar() as return 'something
else', refresh your browser. So far I still see "hello world" but not
"something else". Besides, the myapp/modules/foo.pyc is NOT rebuilt
according to its file create timestamp, thus another evidence that the
reload did not happen. I am using latest trunk on Windows XP, Python
2.5.4
By the way, an equivalent, cleaner and faster refactoring is
legitimate, as long as it works. I will agree on a __import__() feels
better than an exec(...), so let's first get things right.
On Jul3, 7:49pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> It is true that force is ignored. That is because __import__ always
> reloads. This may seem slower but actually it may be faster than the
> previous solution using exec with force=False.
>
> The reason for the change is that the new implementation is supposed to
> be equivalent, cleaner and faster.
> Does it work for you?
>
> Massimo
>
> On 3 Lug, 06:05, Iceberg <iceb...@21cn.com> wrote:
>
>
>
> > Sorry gentlemen, I don't get it.
>
> > First of all, the new implementation, even with the latest bugfix,
> > does not use the "force" parameter at all, neither python reload(). I
> > reckon that Jose did not test the reload feature when he said "Now
> > works!". Actually now the reload feature is gone.
>
> > Second, I would recommend Massimo to test the new code before
> > committing it. Even we don't have to follow TDD (test-driven
> > development), but a TAD (test-after-development) should be a minimal
> > rule. Otherwise you actually put those enthusiastic web2py users on a
> > really "bleeding" edge, with unnecessary "blood", and therefore
> > potentially discourage them from checking out the latest trunk often.
>
> > The last, well, and the least, I would like to suggest "If It Works,
> > Don't Fix It". I remember local_import(...) was not an easy job. More
> > than 7 months ago, it experienced some back and forth adjustment,
> > until Massimo commented out the "old implementation" and code
> > stabilized since then. So, why the sophisticated local_import(...) is
> > being reimplemented 2 days ago, introducing all this hustle?
>
> > On Jul3, 7:45am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > I think I fixed it. Please try again. Also check whether reload works
> > > or not.
>
> > > On 2 Lug, 18:26, Jose <jjac...@gmail.com> wrote:
>
> > > > In the modules directory of my application I have mymodule.py
>
> > > > When run from the controller:
> > > > mymodule = local_import ('mymodule', reload = True)
>
> > > > this produces no error, but when I access the functions or classes of
> > > > the module,
>
> > > > myobject = mymodule.MyClass(...)
>
> > > > it fails:
>
> > > > AttributeError: 'module' object has no attribute 'MyClass'
>
> > > > You understand?
>
> > > > This worked well until yesterday, after upgrading from the trunk,
> > > > started the error.
>
> > > > Jose
