On 21.02.2006., at 17:18, Jonathan Ellis wrote:
I think you should re-examine your sense of proportion if you
condemn a (very useful!) language feature as "a major problem"
because you sometimes dislike what people name their modules. :)
I didn't want to offend. It's not a problem of module naming at all,
and I'm not the only one criticysing this aspect of python.
and also because sometimes one needs to import using "import
package.module " and then use module.function
and other times "from package.module import Class" ... Class.method,
which imho is less consistent.
I don't understand this objection at all. How is it inconsistent
that classes, like anything else, can be individually imported from
a module?
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.
so, I repeat, the problem is not internally in the framework where
you know what you are doing but the external api stability.
Source compatiblity from release to release is important because it
impacts the freedom of refactoring. Forcing the developers to
postpone important refactoring just to preserve source compatibility
between minor releases make development less fun and when developing
free software fun is important :-)
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.
I'm not for the mantra "procedural is bad", I'm only concerned with
the fact that (as happens frequently) refactoring to OOP should be
more unintrusive to the external api, and in python the illusion is
kept quit well but there are many little gotchas like this one
Many people says that python is not a good language because of
stuff like that but for me is far more important the abundancy of
python libraries and frameworks that this subtle issues.
---
marko
-------------------------------------------------------
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
