Re: psycopg2 and large queries
On Dec 19, 2:34 am, Laszlo Nagy wrote:
>
> I was looking for psycopg2 documentation, but I found nothing. However,
> I found some posts telling that named cursors do support fetching a
> single row at a time. Here is how to create a named cursor:
>
> cur = conn.cursor('mycursor')
>
> This is very strange, because DB API 2.0 does not have this feature. Why
> this feature was created, and how to use it? Not documented.
>
The feature was created to use server-side cursors. The DB API
doesn't specify how to create them. I've got no idea why it isn't
documented.
> However, this is also not usable, because named cursors do not have a
> ".description" property! You can try this:
>
> cur = conn.cursor('mycursor')
> cur.execute('select name from product limit 100')
> print repr(cur.description) # -> None
>
They do have a description attribute, but it is only populated after
you fetch a row. eg try
cur = conn.cursor(name='mycursor')
cur.execute('select name from blah')
cur.fetchone()
print cur.description
> This is unacceptable!
Really? I accepted it just fine.
>
> p.s.: I tried to subscribe to the psycopg mailing list, but the
> confirmation email did not arrive in 6 hours...
psycopg website and development in general seems to be comatose.
Emails to the list are being silently dropped. Also, don't believe the
front page, development stopped happening on that svn branch a while
ago and moved to a bzr branch, which has failed to respond for the
last few weeks. Maybe the relevant people are on holidays. If this
persists for a while someone will fork it, since quite a few people
are interested in its continued development.
--
http://mail.python.org/mailman/listinfo/python-list
Usual practice: running/testing modules in a package
Hi all, I am new to using packages to group my modules. I can't figure out how to run a module that uses relative imports without writing a wrapper that imports that module. Everything I try it complains that I am attempting a relative import in a non-package. eg ~/python/testpackage$ ls config.py importer.py __init__.py ~/python/testpackage$ cat importer.py from . import config config.hello() ~/python/testpackage$ cat config.py def hello(): print 'hello' __init__.py is empty ~/python/testpackage$ python -V Python 2.5.2 ~/python/testpackage$ echo $PYTHONPATH .:/home/ale/python/libs:/home/ale/lib/python/: ~/python/testpackage$ python importer.py Traceback (most recent call last): File "importer.py", line 1, in from . import config ValueError: Attempted relative import in non-package Ok, fair enough. There's something about running with -m for running modules: ~/python/testpackage$ python -m importer Traceback (most recent call last): File "/usr/lib/python2.5/runpy.py", line 95, in run_module filename, loader, alter_sys) File "/usr/lib/python2.5/runpy.py", line 52, in _run_module_code mod_name, mod_fname, mod_loader) File "/usr/lib/python2.5/runpy.py", line 32, in _run_code exec code in run_globals File "/home/ale/python/testpackage/importer.py", line 1, in from . import config ValueError: Attempted relative import in non-package Ok, maybe it can't see the __init__.py because it is in the current directory. Go up one. ~/python$ python testpackage/importer.py Traceback (most recent call last): File "testpackage/importer.py", line 1, in from . import config ValueError: Attempted relative import in non-package No. What about: ~/python$ python -m testpackage.importer Traceback (most recent call last): File "/usr/lib/python2.5/runpy.py", line 95, in run_module filename, loader, alter_sys) File "/usr/lib/python2.5/runpy.py", line 52, in _run_module_code mod_name, mod_fname, mod_loader) File "/usr/lib/python2.5/runpy.py", line 32, in _run_code exec code in run_globals File "/home/ale/python/testpackage/importer.py", line 1, in from . import config ValueError: Attempted relative import in non-package That one is very puzzling. It knows that testpackage is a package because I am invoking it with testpackage.importer, but still thinks it isn't a package. A wrapper on the level up works: ~/python$ cat importercaller.py from testpackage import config config.hello() ~/python$ python importercaller.py hello So, how do I run these modules without writing a wrapper script for each one? My main use actually would be to get pylint to analyse them, but it seems to use the python import system, so it fails whenever python fails. If anyone can tell me how to get pychecker to even be able to use a wrapper, it would also be very beneficial. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to use subprocess.Popen execute "find" in windows
On May 6, 7:19 pm, [EMAIL PROTECTED] wrote:
> In cmd, I can use find like this.
>
> C:\>netstat -an | find "445"
> TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
> UDP 0.0.0.0:445 *:*
>
> C:\>
>
> And os.system is OK.>>> import os
> >>> os.system('netstat -an | find "445"')
>
> TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
> UDP 0.0.0.0:445 *:*
> 0
>
>
>
> But I don't know how to use subprocess.Popen to do this.
>
> from subprocess import Popen, PIPE
>
> p1 = Popen(['netstat', '-an'], stdout = PIPE)
> p2 = Popen(['find', '"445"'], stdin = p1.stdout, stdout = PIPE)
> print p2.stdout.read()
>
Get rid of the extra quotes. ie:
p2 = Popen(['find', '445'], stdin = p1.stdout, stdout = PIPE)
The quotes on the command line and on the os.system call are consumed
by the shell. The program doesn't see them.
--
http://mail.python.org/mailman/listinfo/python-list
Re: generator expression works in shell, NameError in script
On Jun 18, 11:56 pm, nn wrote: > On Jun 18, 8:38 am, guthrie wrote: > > > > > On Jun 17, 6:38 pm, Steven Samuel Cole > > wrote: > > > > Still don't really understand why my initial code didn't work, though... > > > Your code certainly looks reasonable, and looks to me like it "should" > > work. The comment of partial namespace is interesting, but > > unconvincing (to me) - but I am not a Python expert! It would > > certainly seem that within that code block it is in the local > > namespace, not removed from that scope to be in another. > > > Seems that it should either be a bug, or else is a design error in the > > language! > > > Just as in the above noted "WTF" - non-intuitive language constructs > > that surprise users are poor design. > > This is certainly an odd one. This code works fine under 2.6 but fails > in Python 3.1. > > >>> class x: > > ... lst=[2] > ... gen=[lst.index(e) for e in lst] > ... > Traceback (most recent call last): > File "", line 1, in > File "", line 3, in x > File "", line 3, in > NameError: global name 'lst' is not defined > Arghh. I see thousands of future wtf!? posts to c.l.p. triggered by this new feature. Might as well save some time and add it to the FAQ already. -- http://mail.python.org/mailman/listinfo/python-list
