Psycopg psycopg

Comments and changes to this ticket

• 

  Daniele Varrazzo January 29th, 2012 @ 07:40 PM

  Why it would be handy? Can you make an example? Thanks.

• 

  Daniele Varrazzo January 30th, 2012 @ 01:42 PM

  • State changed from “new” to “hold”

  If we put stuff in args, it ends up being printed everywhere, changing the current behaviour of the exception:

  In [1]: class MyException(Exception): pass
     ...: 
  
  In [3]: try: raise MyException('foo', 10, 20)
     ...: except MyException, e: pass
     ...: 
  
  In [4]: e
  Out[4]: MyException('foo', 10, 20)
  
  In [5]: print e
  ('foo', 10, 20)
  

  We also have three independent attributes for exceptions: pgerror, pgcode and cursor, and the second is mostly independent from the first two, which makes positional arguments an awkward implementation.

  It's also more explicit to access exc.pgerror than exc.args[1].

  What would be the advantages in using args? Would they outweigh these drawbacks?

• You flagged this item as spam.
  

  Piotr Czachur January 30th, 2012 @ 06:06 PM

  Daniele,

  Pros:
  * When you log exception, you see also pgcode, which may be important (error messages can change, while pgcode should remain unchanged (user's stored functions))

  Cons
  * What's wrong that pgcode is being printed everywhere? * I agre that accessing e.args[1] is not so friendly, but you can always provide getter function.

  Please decide yourself... it's really not important issue.

• 

  Daniele Varrazzo January 30th, 2012 @ 06:15 PM

  The pgcode may be important, but I suspect now it would mostly break other people code (only at visualization level, but knowing from the past I'd say it would be enough to piss people).

  My decision would be not to change the exception. However, please feel entirely free to raise the question to the mailing list and see what would be ok for other users. If there is a good use case to have the pgcode in the args, or in the str(), which I suspect is what you are really after, I would have no problem in changing the code.

• You flagged this item as spam.
  

  Piotr Czachur February 1st, 2012 @ 01:08 PM

  After some thoughts, I agree that enhancment it would provide would be supressed by backward incompatibilitiy issues, so leaving it as it is, is the best choice for now.
  If I find some more solid motivation for this change I will put on the mailing list.
  Thank you very much for great attitude.

• 

  Daniele Varrazzo September 26th, 2012 @ 02:24 PM

  • State changed from “hold” to “invalid”

  Closing as agreed not to change the thing.