[CentralOH] Syntactic Sugar (or sacharine)?

[Mark Erbaugh]

One thing I didn't mention is that the dict I am using is for the info parameter to SQLAlchemy's Column constructor. The info parameter is designed to store application specific information. In my case, I'm intending to use info to store information needed to validate user input strings (from a web page) destined for the database column. The SQLAlchemy docs state that the info paramter must be a dict.

Mark

On Aug 12, 2011, at 2:00 PM, Eric Wilson wrote:

> I'm not sure what you want to do with this dict, but you may want to consider whether collections.namedtuple would be useful.
> 
> >>> from collections import namedtuple
> >>> Customer = namedtuple('Custormer','name age dob')
> >>> john = Customer('John Doe',42,'1901-01-01')
> >>> john.name
> 'John Doe'
> >>> john.username
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> AttributeError: 'Custormer' object has no attribute 'username'
> 
> The main benefits of the namedtuple is that you can't add new attributes to it, and if you forget what an attribute is named, rather than return None, it gives the error seen above.
> 
> Of course, in many situations where you would use a dict, this wouldn't be useful, as it is intentionally not nearly as flexible.
> 
> For more, see the video from PyOhio: http://python.mirocommunity.org/video/4373/pyohio-2011-data-transfer-obje
> 
> Eric Wilson
> 
> On Fri, Aug 12, 2011 at 1:12 PM, Issac Kelly <issac.kelly at gmail.com> wrote:
> You could do something like this:
> 
> >>> class Settings(object):
> ...     internal_dict = {
> ...         'min': 4,
> ...         'max': 8,
> ...     }
> ...     def __getattr__(self, attr):
> ...         return self.internal_dict[attr]
> ...     def __setattr__(self, attr, value):
> ...         self.internal_dict[attr] = value
> ... 
> >>> s = Settings()
> >>> s.min
> 4
> >>> s.max
> 8
> >>> s.min = 5
> >>> s.min
> 5
> http://stackoverflow.com/questions/42558/python-and-the-singleton-pattern
> 
> And then you could make it a singleton if you need (or not)
> 
> On Fri, Aug 12, 2011 at 12:55 PM, Brandon Craig Rhodes <brandon.craig.rhodes at gmail.com> wrote:
> Mark Erbaugh <mark at microenh.com> writes:
> 
> > I accidentally initialized the dict with {min:0} rather than
> > {'min':0}, but the former worked as the built-in function min is
> > hashable ... I'm thinking it's marginally faster as there's no string
> > processing involved.
> 
> An interesting hypothesis!  You should run a test with the "timeit"
> module to see whether it is truly faster.
> 
> My guess is that it is *not* actually faster, because all of the strings
> that appear as literals in your Python code are "interned" strings - no
> matter how many times the literal string 'min' appears in your program,
> CPython creates only a single string object that gets used over and
> over.  And interned strings are, like functions, compared by identity -
> the check for d['min'] will, just like d[min], be reduced immediately to
> an extremely fast pointer comparison operation.
> 
> But run timeit anyway, because I could be wrong! :)
> 
> --
> Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> http://mail.python.org/mailman/listinfo/centraloh
> 
> 
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> http://mail.python.org/mailman/listinfo/centraloh
> 
> 
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> http://mail.python.org/mailman/listinfo/centraloh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/mailman/private/centraloh/attachments/20110812/70e018fe/attachment-0001.html>