Marko Mikulicic wrote:
that's not the problem. the problem is that sometimes you import module
names and use them as first class objects (with the module.object
notation),
and other times you directly import classes and use the same notation
(class.method), but then the import syntax is different.
Let's consider this scenario:
you have a module example/oddball.py with:
blabla = 0
def dosomething():
global blabla
blabla = blabla + 1
return blabla
def somethingOther():
...
now imagine that the users of this module use it this way:
import example.oddball
print example.oddball.dosomething()
It would be nicer to use import it with:
from example import oddball
but you have no control on how users use your code.
Now imagine some time in the future you want to wrap oddballs methods
inside a class using classmethods (for whatever reasion one would like
to do that, for example you want to have different singleton objects one
for each thead without having to deal the thread locality issues for
every function, or simply in order to avoid usage of global module
variables (error prone because of scoping issues)) suddenly you cannot
import it with "import example.oddball" because now "oddball" isn't a
module (even if the class methods and module functions are actually used
the same way!) and this breaks user code importing the module that way.
I feel that it's really a documentation problem. And if you really want
import example.oddball
to still work for compatibility reasons, it's easy to modify sys.modules to
provide an alias.
so, I repeat, the problem is not internally in the framework where you
know what you are doing but the external api stability.
With python, except when there are name clashes, it's always possible to
keep API stability, if the API is not badly thought out in the first place.
sys.modules compatibility aliases are being used a lot in Zope 3 for
instance, and even in Zope 2. All suitably surrounded by warning that
explain that it's deprecated and when it will go away in the future.
For product as young as SQLAlchemy it's probably not necessary to provide
them, import breakages are obvious and fixed in a matter of minutes.
Python object oriented features were slowly added during many years and
it's easy to see completely different styles between standard python
modules and language features (for example compare the perfix "len"
function to the infix "has_key" method for dictionaries) and this thing
about modules "freedom" is reminiscent of procedural programming style.
On the contrary modules are a great feature of python, they're a file-based
namespace, very useful. And modules are first-class object by the way.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
