import issue

[Paolo Valleri]

Hi,

we can import the same web2py class in two ways:

from gluon import DAL

from dal.base import DAL as d1

both work, but 

d=d1()

isinstance(d, DAL)

False

This could lead to very odds results/issues. 

DAL is only an example, I'd this problem with other classes as well. 

 Paolo

[Leonel Câmara]

I think you're right. This should be an error.

from gluon import DAL

and

from gluon.dal,base import DAL

Should be the only 2 ways to do it, and we should only ensure backwards compatibility for the first form.

[Paolo Valleri]

While fixing this issue I've figured out something odds.

Current custom_import allows you to import any app-module by writing:

from module import ...

This works as soon as the module name is different from any module we have in gluon/*. 

If your app module has the same module, the import will fail (without much information). 

Although it seems a rare case it could still happen.

 Paolo

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paolo Valleri]

I created a PR https://github.com/web2py/web2py/pull/587 with a potential solution

 Paolo

[Leonel Câmara]

This solves the problem but I'm not sure I like it. Ideally you could not import from 'dal' directly at all in web2py, you should have to import from gluon.dal. Maybe we should just add modules inside gluon to INVALID_MODULES or something.

[Niphlod]

+1. we should encourage to use web2py libraries ALWAYS starting from the gluon module...

[Paolo Valleri]

In the current situation it is really easy to find something that doesn't work as expected.

I'm for fixing it and the PR is a tentative for the 3 mentioned problems.

@Niphlod, I agree, we should encourage to use web2py libraries ALWAYS starting from the gluon module, I think a first step in this direction is to do the same in web2py.

in gluon/* we have several times used both ways to import modules (even in tests/*). I started to review it in order to explicitly write from gluon/* import ... but this is an other things.

Being "explicitly" is slightly faster. Run python web2py.py -S welcome

>>> a="""
... from dal import DAL
... """
>>> b="""
... from gluon.dal import DAL
... """
>>> import timeit
>>> timeit.timeit(a, number=100000)
0.5820941925048828
>>> timeit.timeit(b, number=100000)
0.48334693908691406

@leonel mind that we import from dal directly in several places, blocking it would brake apps and web2py too. Anyway, I tried your solution but it doesn't work since gluon is in the sys.path https://github.com/web2py/web2py/blob/master/gluon/admin.py#L445

Finally, "from dal import DAL" will force to re-import all modules at run-time. 

To test it, add "print name" in https://github.com/web2py/web2py/blob/master/gluon/custom_import.py#L61

and do "from dal import DAL" in a web2py console. The first time all modules will be reloaded, the second time no.

Paolo

[Leonel Câmara]

I only see 5 places where we import from dal directly.

gluon/sql.py

gluon/__init__.py

gluon/tests/test_dal.py

gluon/tests/test_dal_nosql.py

These could all be changed to be either relative imports or to import from gluon.dal instead.

This one is fine since it's in the dal module

gluon/dal/base.py

Do people really import from the dal directly in apps? Why is the gluon directory in sys.path? In the book you always see "from gluon.foo import bar". For instance in the book you see:

from gluon.contrib.sms_utils import SMSCODES, sms_email

Not

from contrib.sms_utils import SMSCODES, sms_email 

Seriously importing from modules inside gluon directly should not be supported and if people do it we need to break compatibility with it because it makes it unsustainable as we can't change the modules inside gluon and keep backwards compatibility in a sane way.

[Paolo Valleri]

Mind that dal is only an example, this issue belongs to any module in gluon/*

 Paolo

--