that approach fails to take into account arguments consumed from
**kwargs by superclasses. the particular method I have makes some
assumptions about the construction of the class being inspected, i.e.
that it looks like this:
class Foo(object):
def __init__(self, arg1, arg2):
...
cla
On Nov 12, 2006, at 11:56 AM, Michael Bayer wrote:
>
> since create_engine deals with class constructors, i went with this
> approach:
>
> def get_cls_kwargs(cls):
> """return the full set of legal kwargs for the given cls"""
> kw = []
> for c in cls.__mro__:
> cons = c.__ini
On 11/12/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
> since create_engine deals with class constructors, i went with this
> approach:
>
> def get_cls_kwargs(cls):
> """return the full set of legal kwargs for the given cls"""
> kw = []
> for c in cls.__mro__:
> cons = c.__init
since create_engine deals with class constructors, i went with this
approach:
def get_cls_kwargs(cls):
"""return the full set of legal kwargs for the given cls"""
kw = []
for c in cls.__mro__:
cons = c.__init__
if hasattr(cons, 'func_code'):
for vn in cons.
ugh, well i fixed that one. random doc bugs you can file tickets
for, or ill just give you commit access if you want to knock some out
yourself.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" gr
On 11/7/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
> yeah, or use introspection to consume the args, i thought of that too.
> i guess we can do that. of course i dont like having to go there but i
> guess not a big deal.
>
> as far as kwargs collisions, yeah, thats a potential issue too. but
>
On 11/7/06, Shannon -jj Behrens <[EMAIL PROTECTED]> wrote:
> The following results in correct data going into and coming out of the
> database, but the data in the database itself looks double encoded:
>
> import MySQLdb
>
>
> connection = MySQLdb.connect(host="fmapp03", user="foxmarks",
>
yeah, or use introspection to consume the args, i thought of that too.
i guess we can do that. of course i dont like having to go there but i
guess not a big deal.
as far as kwargs collisions, yeah, thats a potential issue too. but
the number of dialects/pools is not *that* varied, theyre gener
The following results in correct data going into and coming out of the
database, but the data in the database itself looks double encoded:
import MySQLdb
connection = MySQLdb.connect(host="fmapp03", user="foxmarks",
passwd='ChunkyBacon', db="users")
cursor = connect
On 11/4/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> Shannon -
>
> im trying to figure a way to make create_engine() behave the way you
> want. but let me show you a highly simplified version of how
> create_engine() works. how would you change it ?
>
> def create_engine(url, **kwargs):
>
On 11/4/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
> Shannon -jj Behrens wrote:
> > I'm using convert_unicode=True. Everything is fine as long as I'm the
> > one reading and writing the data. However, if I look at what's
> > actually being stored in the database, it's like the data has been
>
Shannon -
im trying to figure a way to make create_engine() behave the way you
want. but let me show you a highly simplified version of how
create_engine() works. how would you change it ?
def create_engine(url, **kwargs):
pool = pool.Pool(**kwargs)
dialect = module.Dialect(url, **kwar
Shannon -jj Behrens wrote:
> Changing from convert_unicode=True to use_unicode=True doesn't do what
> you'd expect. SQLAlchemy is passing keyword arguments all over the
> place, and use_unicode actually gets ignored. I
> personally think that you should be strict *somewhere* when you're
> passi
Shannon -jj Behrens wrote:
> I'm using convert_unicode=True. Everything is fine as long as I'm the
> one reading and writing the data. However, if I look at what's
> actually being stored in the database, it's like the data has been
> encoded twiced. If I switch to use_unicode=True, which I be
Logic is just fine... I guess you forgot to consider first param "not
dialect.convert_unicode".
On the sidenote, the doc string
(http://www.sqlalchemy.org/docs/docstrings.myt#docstrings_sqlalchemy.engine)
says that:
convert_unicode=False : True if unicode conversion should be applied
to all str
On 11/3/06, Shannon -jj Behrens <[EMAIL PROTECTED]> wrote:
> I'm using convert_unicode=True. Everything is fine as long as I'm the
> one reading and writing the data. However, if I look at what's
> actually being stored in the database, it's like the data has been
> encoded twiced. If I switch
16 matches
Mail list logo
