theres an ancient ticket for this which i didnt entirely disagree with, i just chose not to deal with it. mostly becuase its not always "guaranteed" about what type you get back, like string could return str or unicode, etc.
doing the FLOAT=Float thing, if it doesnt break anything, still woulndt be a general solution since types can be subclassed freely (and are). if you want to map from SQL types to Python, we should just put a __type__ attribute or similar on TypeEngine (i.e. class String(TypeEngine): __type__ = str) On Feb 6, 2007, at 11:52 PM, Jonathan Ellis wrote: > > IIRC SA doesn't really have a map of "this is the python type I should > get for this sql type," and relies on the db driver to handle that. > > I need to at least approximate this mapping w/o going through the > driver, though. So I was just going to set up a dict for the classes > defined in types.py. But, it would make the dict a lot shorter if the > CONSTANTS at the end were defined as > FLOAT = Float > TEXT = String > ... > > instead of > class FLOAT(Float):pass > class TEXT(String):pass > ... > > Would this break anything? > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
