Live data from Hacker News

Show HN: Pydb – a lightweight database with Python syntax queries, using ZeroMQ

github.com

31–34 of 34 posts

Re: Show HN: Pydb – a lightweight database with Python syntax queries, using ZeroMQ

#32
post #24

Will this code not cause issues? I know that you aren't modifying args or kwargs, in the _run method, but it just seems like a potential point of failure or a python anti-pattern def _run(self, func=None, args=(), kwargs={})

Yes, indeed! Thanks for pointing that out. I actually saw that when I was cleaning this up a bit for release and couldn't make up my mind. I mean I'm not modifying args or kwargs now but if I did later, I could shoot myself in the foot in a not so obvious way. But on the other hand, I don't know a succinct way to express these default values. I'd probably go with `args=None, kwargs=None` and then `args = args if args…

In the cases where I need to do this, I use a singleton:

  DEFAULT=object() # used for no other purpose

  def fun(arg=DEFAULT):
      arg_val = {} if arg is DEFAULT else arg

Re: Show HN: Pydb – a lightweight database with Python syntax queries, using ZeroMQ

#33
vanilla zeromq is a pretty bad choice for any database. zmq explicitly makes no guarantees about reliable delivery, so losing random inserts or queries here or there would be considered acceptable.

subscribers also lose the first few messages the publisher sends, unless you make sure you start the subscriber first. The publisher will make no indication of which messages are lost and which ones have actually been sent to someone:

http://zguide.zeromq.org/page:all#Getting-the-Message-Out

I would suggest building something on top of request-reply instead: it's actually possible to get build reliable delivery on that.

http://zguide.zeromq.org/page:all#reliable-request-reply

Re: Show HN: Pydb – a lightweight database with Python syntax queries, using ZeroMQ

#34
post #24

Will this code not cause issues? I know that you aren't modifying args or kwargs, in the _run method, but it just seems like a potential point of failure or a python anti-pattern def _run(self, func=None, args=(), kwargs={})

Yes, indeed! Thanks for pointing that out. I actually saw that when I was cleaning this up a bit for release and couldn't make up my mind. I mean I'm not modifying args or kwargs now but if I did later, I could shoot myself in the foot in a not so obvious way. But on the other hand, I don't know a succinct way to express these default values. I'd probably go with `args=None, kwargs=None` and then `args = args if args…

This is the pythonic way

  def func(*args, defaulted='default', **kwargs):
      # args is a list, kwargs is a dict
      arg0 = args[0] if args else None
      another_kwarg = kwargs.get('another_kwarg', 'default')
      print(arg0, defaulted, another_kwarg)


  >>> func('one', 'two', defaulted='myval')
  one myval default
  >>> func(another_kwarg='myval')    
  None default myval
  >>> args = ('one', 'two')
  >>> kwargs = {'defaulted': 'myval', 'another_kwarg': 'other'}
  >>> func(*args, **kwargs)    
  one myval other
Post reply on HN