On Dec 9, 2008, at 4:09 PM, Angri wrote:
> > I can not agree that extending is "safe" as I've encountered another > problem with custom class name: > http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/sql/util.py#L145 > And I guess it is not the last :( It probably is the last. That's something which has been added recently. It previously worked in a dynamic fashion but was changed to what you see there for pickling purposes. However it can be expanded to support classes which aren't present, so that you wouldn't notice it. This technique is also something I picked up from a very well known and respected Python developer. > I see, you propose not to extend class Column and write "a function > that creates instances" but it seems to me that this approach is not > good because it is not "pythonic", it is not "object-oriented"ly, it > is hard to write, support and extend. It's how most of SQLA clause elements are invoked, in fact. Python's philosophy is defnitely not in the vein of "use objects and inheritance for everything", you're thinking of Java, which does not provide standalone functions in the language. Using functions to return objects provides a convenient layer of variability between the composed structure of what the function returns and the public signature of that function. Subclassing is definitely not the only way to extend something and the problem you're experiencing is a variant of the so-called "fragile base" problem. What strikes me as most "unpythonic" here is that you think you need a rewrite of the library in a Java-like GOF style when a simple, one line function will solve your problem. > > Btw, I still think that relying on class name is a bad way to do > things. Here is where the technique is derived from, from the "visitor.py" module in Python's own compiler module: http://svn.python.org/view/python/branches/release26-maint/Lib/compiler/visitor.py?rev=66717&view=auto > What do you think Michael, how difficult it can be to rewrite > those pieces of code to use more OOP-like technics, particularly > explicitly define class properties (inheritable class properties!) > instead of doing things like eval("Annotated%s" % > element.__class__.__name__)? When I first started Python, I used a traditional GOF-visitor pattern, with explicit visit_XXX and dispatcher methods. It's extremely verbose and tedious to refactor. It didn't take too long for me to realize I was porting Java methodologies that are entirely inappropriate for a dynamic language like Python. Subclassing Column in any case requires knowledge of the visitation logic - you either need to implement visit_XXX() in the GOF style, or __visit_name__ = 'whatever' in the Pythonic style. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
