Thanks, it is easy to see how the default parameter gets changed with that
example since the binding passes back outside the function through the
return value, gets assigned to another variable and then the container
contents modified through that assignment.
Additional information:
I added a print to the front end of DAL.__init__ and was surprised to find
driver_args was set to {'check_same_thread': False} but I did not set it in
my db = DAL() class constructor call.
So here is the issue. I start up the development environment on Linux with a
You must be using trunk. I think this is a bug in trunk but not
stable. Thanks for reporting it.
Massimo
On Mar 3, 2:02 pm, ron_m ron.mco...@gmail.com wrote:
Additional information:
I added a print to the front end of DAL.__init__ and was surprised to find
driver_args was set to
I just downloaded the nightly build, unpacked it, copied over my application
and get the same problem.
I don't have a problem with 1.92.1. I don't normally use trunk but test it
once in a while to see what is coming. :-)
Ron
please try change line in dal
args =
(self,uri,pool_size,folder,db_codec,credential_decoder,driver_args)
to
args =
(self,uri,pool_size,folder,db_codec,credential_decoder,driver_args or
{})
On Mar 3, 4:07 pm, ron_m ron.mco...@gmail.com wrote:
I just downloaded the nightly build, unpacked it,
Wow that fixed it. You are a Python Ninja :-)
I would sure like to know what the mechanism was that caused driver_args to
bleed from SQLLite to the other adapters even though it is defaulted it to
an empty dict on the class initializer. I also printed driver_args as the
first line of code in
class DAL:
def __init__(self,...,driver_args={})
so because this is defined in a module, every time driver_args is not
passed it is set to {}, the same {}. If one app changes, the default
changes for all apps. It is kind of counter intuitive but it works
that way.
It is very dangerous to set
Ah Ok, I was trying to reproduce with a simple program containing a couple
of classes with a main all in one file but it did not exhibit the problem
behaviour. So having the classes in a module is part of the recipe and lists
and dicts are passed around as object references to the container
def f(a={}): return a
...
x=f()
x[1]=1
print x
{1: 1}
y=f()
print y
{1: 1}
On Mar 3, 5:49 pm, ron_m ron.mco...@gmail.com wrote:
Ah Ok, I was trying to reproduce with a simple program containing a couple
of classes with a main all in one file but it did not exhibit the problem
behaviour.
9 matches
Mail list logo
