[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.
[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 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 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
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 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 > >
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
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 > > > 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 wrote: >> I just tried this in a web2py shell: >> > from gluon.storage import Storage > data = Storage() > data.foo = 'bar' > data.foo >> 'bar' > data.test >> >>
[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 but: >>>data.test == None True >>>if not data.test: print 'null' null On Jun 2, 11:54 am, Ross Peoples wrote: > I just tried this in a web2py shell: > > >>> from gluon.storage import Storage > >>> data = Storage() > >>> data.foo = 'bar' > >>> data.foo > 'bar' > >>>data.test > >
[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
[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
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 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 instead of None. > > This is causing a lot of problems for me, as I rely on the Storage object > throughout my application.
