On Wednesday, May 17, 2017 at 1:58:04 AM UTC-7, lyn2py wrote: > > Please bear with me while I explain my use case: > > I have a list of "standard" websites, like all the major search engines. > Traditionally, I can make do with a python list, like so: > > list_of_sites =['google.com','yahoo.com',...] > > > However, the code base has evolved and it's much better to have other data > too, like: > > one_site = dict( > url='google.com', > name='Google', > short='G', > ..and many more.. > ) > > I have that for each site. As you can see, having a table will serve this > data much better. >
Aside from the persistence and sharing issues addressed by Anthony and Sundar, I'd like to point out that Python doesn't have a native data type of "table". And in web2py, the data type used to hold the results of a database query is essentially a list of dictionaries. Using an SQLite in-memory table (which I have never done, so don't mistake me for an authority) would help with retrieving data *if the data involved a great many entries*. If you have a dozen or two entries, then I would expect that accessing a local variable which was a list of dicts would be faster than calling out to a database engine. I would expect the speed crossover to be well above a hundred entries, maybe even above a thousand entries, but I'm not looking at any actual timing data right now. /dps -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
