News for hackers. Stuff that matters.
Re:Python Tips and Traps by dalke on Monday January 19, 2015 @12:43PM (#8912935)
The namedtuple example is wrong. The constructor requires all of the parameters, and an attribute cannot be set:

    >>> from collections import namedtuple
    >>> LightObject = namedtuple('LightObject', ['shortname', 'otherprop'])
    >>> m = LightObject()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: __new__() takes exactly 3 arguments (1 given)
    >>> m = LightObject("first", "second")
    >>> m.shortname
    'first'
    >>> m.shortname = 'athing'
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: can't set attribute
Also, bare try/excepts as in:

    try:
      # get API data
      data = db.find(id='foo') # may raise exception
    except:
      # log the failure and bail out
      log.warn("Could not retrieve FOO")
      return
are really bad. The failure might be caused by a ^C or MemoryError, or even a SystemExit, should db.find() desire to do that.

Instead, qualify it by catching Exception:

    try:
      # get API data
      data = db.find(id='foo') # may raise exception
    except Exception:
      # log the failure and bail out
      log.warn("Could not retrieve FOO")
      return

It's also poor form to "return True" in the exit method of the context manager. If there is no exception then that's not needed at all, and if there is an exception ... well, that code will swallow AttributeError and NameError and ZeroDivisionError, and leave people confused as to the source of the error.
Re:Python Tips and Traps by ryan_sb on Monday January 19, 2015 @01:08PM (#8913064)
Thanks for correcting me, I'll get those updated ASAP.
Re:Python Tips and Traps by pdonis on Monday January 19, 2015 @01:22PM (#8913149)
A good rule of thumb: if you show actual code, run it before you post it!
Re:Python Tips and Traps by timdierks on Tuesday January 20, 2015 @12:38PM (#8918120)
I frequently want ad-hoc slots to create a structure of related values without the verbosity of a dict with static keys. What's the pythonic method?

E.g. when I want to carry a foo, a bar, and a baz around, but namedtuple isn't right (e.g. I need mutation). I'd prefer

    config = Someclass()
    config.foo = 1
    config.bar = "quux"
    config.baz = 3.3
and then using config.bar, etc.

over:

    config = { 'foo': 1, 'bar': "quux", 'baz': 3.3 }
and then using config['bar']
Re:Python Tips and Traps by mkesper on Tuesday January 20, 2015 @03:01AM (#8915909)
Shouldn't you qualify the exception class as properly as you can? If you can't I'd expect to check for certain error classes you can handle and else reraise the Exception.
Re:Python Tips and Traps by dalke on Tuesday January 20, 2015 @08:19AM (#8916771)
Yes, I would do that in nearly every case.

However, I don't know the larger context. If this were at the top-level of a web services handler where a "return None" indicates a 400 - Internal Server Error, then logging the database failure and stopping is likely acceptable.

Even then, I wouldn't call it good code. However, the goal of this essay seemed to be to give the minimal example, and a more complete example would have required introducing a fake database module with its own exception type. I believe that would have obscured the intent.

I would have preferred real, working code. In this case, with sqlite3. That's fundamentally a pedagogical choice though.