[web2py] Re: New Storage() Object Breaks Backwards Compatibility
The new Storage in trunk is experimental. It may go away. Yet I think
the problems you refer to have been solved. Can you please try trunk
again and confirm?
Massimo
On Jun 2, 9:57 am, Ross Peoples ross.peop...@gmail.com wrote:
I just updated my trunk only to find several scripts not working properly
and acting strangely. I thought it was a change made to MSSQL, but I have
narrowed down the problem to revision 1980 titled, 'many semplifications'. A
change made to storage.py's __getattr__() function is causing the problem.
The old function used to read:
def __getattr__(self, key):
if key in self:
return self[key]
else:
return None
That means that if you create a new Storage object like so:
data = Storage()
data.foo = 'bar'
And you tried to access a field that didn't exist:
return data.some_field
This would return None. However, the new __getattr__ now reads:
def __getattr__(self,key):
if not key in self:
self[key] = Storage()
return self[key]
So the same exact code would return Storage {} instead of None.
This is causing a lot of problems for me, as I rely on the Storage object
throughout my application.
[web2py] Re: New Storage() Object Breaks Backwards Compatibility
It still returns an empty Storage instance instead of None.
[web2py] Re: New Storage() Object Breaks Backwards Compatibility
I just tried this in a web2py shell:
from gluon.storage import Storage
data = Storage()
data.foo = 'bar'
data.foo
'bar'
data.test
Storage {}
[web2py] Re: New Storage() Object Breaks Backwards Compatibility
The point is that it allows you to do
data.a.b.c=1
without having to do
data.a=Storage()
data.a.b=Storage()
data.a.b.c=1
In your test:
data.test
Storage {}
but:
data.test == None
True
if not data.test: print 'null'
null
On Jun 2, 11:54 am, Ross Peoples ross.peop...@gmail.com wrote:
I just tried this in a web2py shell:
from gluon.storage import Storage
data = Storage()
data.foo = 'bar'
data.foo
'bar'
data.test
Storage {}
Re: [web2py] Re: New Storage() Object Breaks Backwards Compatibility
On Jun 2, 2011, at 10:29 AM, Massimo Di Pierro wrote:
The point is that it allows you to do
data.a.b.c=1
without having to do
data.a=Storage()
data.a.b=Storage()
data.a.b.c=1
In your test:
data.test
Storage {}
but:
data.test == None
True
if not data.test: print 'null'
null
I'd vote for None, and explicit initialization.
On Jun 2, 11:54 am, Ross Peoples ross.peop...@gmail.com wrote:
I just tried this in a web2py shell:
from gluon.storage import Storage
data = Storage()
data.foo = 'bar'
data.foo
'bar'
data.test
Storage {}
Re: [web2py] Re: New Storage() Object Breaks Backwards Compatibility
Hi Massimo, I use Storage in many places, and I always compare with is None, which I believe would now break my code. I also vote for explicit initialization, and make sure that is None works ok. Thanks, Carlos
Re: [web2py] Re: New Storage() Object Breaks Backwards Compatibility
Keep None on the Storage object, then create a new class and call it MultiStorage which implements the new functionality. -- Thadeus On Thu, Jun 2, 2011 at 12:37 PM, Carlos carlosgali...@gmail.com wrote: Hi Massimo, I use Storage in many places, and I always compare with is None, which I believe would now break my code. I also vote for explicit initialization, and make sure that is None works ok. Thanks, Carlos
[web2py] Re: New Storage() Object Breaks Backwards Compatibility
Will do that. How about having current.settings=MultiStorage() and having PluginManager(name) return the current.settings.name? On Jun 2, 1:35 pm, Thadeus Burgess thade...@thadeusb.com wrote: Keep None on the Storage object, then create a new class and call it MultiStorage which implements the new functionality. -- Thadeus On Thu, Jun 2, 2011 at 12:37 PM, Carlos carlosgali...@gmail.com wrote: Hi Massimo, I use Storage in many places, and I always compare with is None, which I believe would now break my code. I also vote for explicit initialization, and make sure that is None works ok. Thanks, Carlos
[web2py] Re: New Storage() Object Breaks Backwards Compatibility
Having the two Storage and MultiStorage objects would be nice, as Storage would require explicit initialization (just like request.vars does). Then if you want to use recursive Storage objects (data.a.b.c = 1), that's where MultiStorage comes in. Nice suggestion, because I do like this new functionality, but I also like the way Storage has been working. Now we can have the best of both worlds and choose the right tool for the job.
