[web2py] Re: gluon.storage.Storage interface discrepancy?

2011-11-02 Thread Magnitus
Definitely, so much is storage (vars, sessions, DAL results, etc) that you pretty much have to use it. And for that reason, I think it warrants its own small subsection in the manual. For uses where I don't have to rely on None identifying initialized keys with the None value specifically, I tend

Re: [web2py] Re: gluon.storage.Storage interface discrepancy?

2011-11-02 Thread Jonathan Lundell
On Nov 2, 2011, at 10:15 PM, Magnitus wrote: > I agree. > > s.a is not sufficient if you want to avoid code repetition. > > You'll naturally want use something like s['a'] at some point if you > want to write good code and you will also want to rely on the > convenient "returns None instead of t

[web2py] Re: gluon.storage.Storage interface discrepancy?

2011-11-02 Thread Magnitus
I agree. s.a is not sufficient if you want to avoid code repetition. You'll naturally want use something like s['a'] at some point if you want to write good code and you will also want to rely on the convenient "returns None instead of throwing an exception" facility. There are workarounds for t

Re: [web2py] Re: gluon.storage.Storage interface discrepancy?

2011-10-27 Thread Jonathan Lundell
On Oct 27, 2011, at 5:03 PM, Jonathan Lundell wrote: > On Oct 27, 2011, at 10:57 AM, Massimo Di Pierro wrote: > >> Any suggestion for improvement? > > I'm not sure when I'll have time to get around to it, but my idea is to > implement both Storage.__getattr__ and .__getitem__ in terms of > sup

Re: [web2py] Re: gluon.storage.Storage interface discrepancy?

2011-10-27 Thread Jonathan Lundell
On Oct 27, 2011, at 10:57 AM, Massimo Di Pierro wrote: > Any suggestion for improvement? I'm not sure when I'll have time to get around to it, but my idea is to implement both Storage.__getattr__ and .__getitem__ in terms of super(get(whatever, None)). (That's not quite the syntax, but you get

Re: [web2py] Re: gluon.storage.Storage interface discrepancy?

2011-10-27 Thread Jonathan Lundell
Sure. On the road now, but shortly. On Oct 27, 2011, at 10:57 AM, Massimo Di Pierro wrote: > Any suggestion for improvement? > > On Oct 25, 3:32 pm, Jonathan Lundell wrote: >> On Oct 25, 2011, at 1:18 PM, Anthony wrote: >> >>> On Tuesday, October 25, 2011 4:08:20 PM UTC-4, pepper_bg wrote:

[web2py] Re: gluon.storage.Storage interface discrepancy?

2011-10-27 Thread Massimo Di Pierro
Any suggestion for improvement? On Oct 25, 3:32 pm, Jonathan Lundell wrote: > On Oct 25, 2011, at 1:18 PM, Anthony wrote: > > > On Tuesday, October 25, 2011 4:08:20 PM UTC-4, pepper_bg wrote: > > > You can do > > > s.get(6,None) > > > Still have to anticipate what my keys are and write different

Re: [web2py] Re: gluon.storage.Storage interface discrepancy?

2011-10-25 Thread Jonathan Lundell
On Oct 25, 2011, at 1:18 PM, Anthony wrote: > On Tuesday, October 25, 2011 4:08:20 PM UTC-4, pepper_bg wrote: > > You can do > > s.get(6,None) > > Still have to anticipate what my keys are and write different code > accordingly. Which is fine in most cases I guess. Or may be I am > trying to

[web2py] Re: gluon.storage.Storage interface discrepancy?

2011-10-25 Thread Anthony
On Tuesday, October 25, 2011 4:08:20 PM UTC-4, pepper_bg wrote: > > > You can do > > s.get(6,None) > > Still have to anticipate what my keys are and write different code > accordingly. Which is fine in most cases I guess. Or may be I am > trying to be too generic here. Thanks for your input...

[web2py] Re: gluon.storage.Storage interface discrepancy?

2011-10-25 Thread pepper_bg
> You can do > s.get(6,None) Still have to anticipate what my keys are and write different code accordingly. Which is fine in most cases I guess. Or may be I am trying to be too generic here. Thanks for your input...

[web2py] Re: gluon.storage.Storage interface discrepancy?

2011-10-25 Thread Massimo Di Pierro
You can do s.get(6,None) On Oct 25, 1:07 pm, pepper_bg wrote: > So gluon.storage.Storage is an amended dict subclass with dot notation > indexing added. With the additional twist that when a key is missing > s['missing_key'] will still raise the standard dict KeyError, while > s.missing_key will