[psycopg] #98: 'raise' is better than 'raise err' when reraising errors.

#98: 'raise' is better than 'raise err' when reraising errors.
-------------------------------------------+--------------------------------
 Reporter:  docwhat+bugs.psycopg <at> gerf.org  |       Owner:  fog   
     Type:  defect                         |      Status:  new   
 Priority:  normal                         |   Milestone:        
Component:  psycopg1                       |     Version:  1.1.21
 Severity:  normal                         |    Keywords:        
-------------------------------------------+--------------------------------
 psycopg-1.1.21
 source:/psycopg1/trunk/ZPsycopgDA/db.py (line 246) does a {{{raise err}}}
 to re-raise an error instead of just doing {{{raise}}}.

 This cuts short the tracebacks and call stack, making it hard to find the
 error that caused this exception.

 {{{
 #!python
 try:
 ...
 except StandardError, err: # Using just raise below would let you just use
 'except:'
     self._abort()
     raise  # using just raise keeps the call stack intact.
 }}}

 Ciao!

-- 
Ticket URL: <http://initd.org/tracker/psycopg/ticket/98>
psycopg <http://initd.org/>

[psycopg] #99: Patch for cursor.execute and cursor.executemany to return cursor object

#99: Patch for cursor.execute and cursor.executemany to return cursor object
-------------------------------------------------+--------------------------
 Reporter:  Miki Tebeka <miki.tebeka <at> gmail.com>  |       Owner:  fog        
     Type:  defect                               |      Status:  new        
 Priority:  normal                               |   Milestone:  PSYCOPG 2.0
Component:  psycopg2                             |     Version:  2.0beta    
 Severity:  patch                                |    Keywords:             
-------------------------------------------------+--------------------------
 This patch makes `cursor.execute` and `cursor.executemany` return the
 cursor object.
 This way you can write:
 {{{
 #!python
 for login, in cursor.execute("select login from users"):
     print login
 }}}

 The patch:
 {{{
 Index: cursor_type.c
 ===================================================================
 --- cursor_type.c       (revision 745)
 +++ cursor_type.c       (working copy)
  <at>  <at>  -395,6 +395,7  <at>  <at> 
  {
      long int async = 0;
      PyObject *vars = NULL, *operation = NULL;
 +    PyObject *pyself = NULL;

      static char *kwlist[] = {"query", "vars", "async", NULL};

Re: [psycopg] #99: Patch for cursor.execute and cursor.executemany to return cursor object

#99: Patch for cursor.execute and cursor.executemany to return cursor object
-------------------------------------------------+--------------------------
 Reporter:  Miki Tebeka <miki.tebeka <at> gmail.com>  |        Owner:  fog        
     Type:  defect                               |       Status:  closed     
 Priority:  normal                               |    Milestone:  PSYCOPG 2.0
Component:  psycopg2                             |      Version:  2.0beta    
 Severity:  patch                                |   Resolution:  wontfix    
 Keywords:                                       |  
-------------------------------------------------+--------------------------
Changes (by fog):

  * resolution:  => wontfix
  * status:  new => closed

Comment:

 Sorry but I don't see anything good in being able to do to .execute()
 directly in the loop. I better like to keep the result of .execute()
 undefined and have it return something really useful in the future.

-- 
Ticket URL: <http://initd.org/tracker/psycopg/ticket/99>
psycopg <http://initd.org/>
psycopg

_______________________________________________
Psycopg mailing list
Psycopg@...
http://lists.initd.org/mailman/listinfo/psycopg

Re: #99: Patch for cursor.execute and cursor.executemany to return cursor object

Miki Tebeka wrote:

>#99: Patch for cursor.execute and cursor.executemany to return cursor object
>-------------------------------------------------+--------------------------
> Reporter:  Miki Tebeka <miki.tebeka@...>  |       Owner:  fog        
>     Type:  defect                               |      Status:  new        
> Priority:  normal                               |   Milestone:  PSYCOPG 2.0
>Component:  psycopg2                             |     Version:  2.0beta    
> Severity:  patch                                |    Keywords:             
>-------------------------------------------------+--------------------------
> This patch makes `cursor.execute` and `cursor.executemany` return the
> cursor object.
> This way you can write:
> {{{
> #!python
> for login, in cursor.execute("select login from users"):
>     print login
> }}}
>  
>

I assume that you really meant to write this:
    for login, in cursor.execute("select login from users").fetchone():
        print login

which does save a few keystrokes over the current:
    cursor.execute("select login from users")
    for login, in cursor.fetchone():
        print login

Re: #99: Patch for cursor.execute and cursor.executemany to return cursor object

> I assume that you really meant to write this:
>     for login, in cursor.execute("select login from users").fetchone():
>         print login

	His example would work : a cursor is an iterable which yields rows :

for id, login in cursor.execute("select id, login from users"):
           print id, login

would print the ids and logins of all users.

for id, login in cursor.execute("select id, login from users").fetchone():
           print id, login

would fail, because fetchone() would return one [id_value, login_value].

Now I'd like this :

for id, login in cursor("select id, login from users"):
           print id, login

I find the DBAPI way a bit kludgey...

When I only need 1 cursor for quick scripts, I use some helper function
which does this.

def Query( sql, *args ):
	cursor.execute( sql, args )
	return cursor.fetchall()

Bug report with dictcursor

Problem :
Using the cursor as an iterable seems to yield DictRow's which behave like  
non-Dict rows (ie. no string keys). Bug ?

Example :

cursor = db.cursor( cursor_factory = psycopg2.extras.DictCursor )

# This code works :

cursor.execute( "SELECT id FROM users LIMIT 2" )
for row in cursor.fetchall():
	print "row :", row, type(row)
	for key in 0,'id':
		try:
			print key, row[key]
		except:
			traceback.print_exc()
	print

# Results :

row : [1] <class 'psycopg2.extras.DictRow'>
0 1
id 1

row : [2] <class 'psycopg2.extras.DictRow'>
0 2
id 2

Re: Bug report with dictcursor

Il giorno mar, 07/03/2006 alle 19.35 +0100, PFC ha scritto:
> Problem :
> Using the cursor as an iterable seems to yield DictRow's which behave like  
> non-Dict rows (ie. no string keys). Bug ?

Seems a bug to me. I'll investigate and fix.

--

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog@...
INIT.D Developer                                           fog@...
     One key. One input. One enter. All right. -- An american consultant
           (then the system crashed and took down the *entire* network)

_______________________________________________
Psycopg mailing list
Psycopg@...
http://lists.initd.org/mailman/listinfo/psycopg

Re: #99: Patch for cursor.execute and cursor.executemany to return cursor object

В Втр, 07/03/2006 в 19:34 +0100, PFC пишет:

> Oh, and by the way : thanks for psycopg. The speed of this thing is
> insane. FYI the postgres driver for PHP is about 10 times slower, without
> doing any object adaptation.

How did you determine that?

Markus Bertheau

Re: Bug report with dictcursor

Il giorno mar, 07/03/2006 alle 19.35 +0100, PFC ha scritto:
> Problem :
> Using the cursor as an iterable seems to yield DictRow's which behave like  
> non-Dict rows (ie. no string keys). Bug ?

DictCursor was missing the .next() override. This is fixed in SVN
changeset [746] (i.e., on the trunk.)

federico

--

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog@...
INIT.D Developer                                           fog@...
          The reverse side also has a reverse side.  -- Japanese proverb

_______________________________________________
Psycopg mailing list
Psycopg@...
http://lists.initd.org/mailman/listinfo/psycopg

[psycopg] #100: null pointer

#100: null pointer
-----------------------------------------+----------------------------------
 Reporter:  brian AT equal / ed DOT net  |       Owner:  fog        
     Type:  defect                       |      Status:  new        
 Priority:  high                         |   Milestone:  PSYCOPG 2.0
Component:  psycopg2                     |     Version:  2.0beta    
 Severity:  critical                     |    Keywords:             
-----------------------------------------+----------------------------------
 >>> psycopg2.connect(db='idportal', user='brian')
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
 TypeError: 'db' is an invalid keyword argument for this function
 >>> psycopg2.connect(database='idportal', user='brian')
 <connection object at 0xb7ab2120; dsn: 'dbname=idportal user=brian',
 closed: 0>
 >>> c = psycopg2.connect(database='idportal', user='brian')
 >>> c.execute("COPY idportal_user TO STDOUT CSV")
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
 AttributeError: 'psycopg2._psycopg.connection' object has no attribute
 'execute'
 >>> c.cursor().execute("COPY idportal_user TO STDOUT CSV")
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
 SystemError: null argument to internal routine
 >>>

-- 
Ticket URL: <http://www.initd.org/tracker/psycopg/ticket/100>
psycopg <http://initd.org/>