Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #22102 > unrolled thread

Documentation, assignment in expression.

Back to article view | Back to comp.lang.python

Contents

  Documentation, assignment in expression. Alexander Blinne <news@blinne.net> - 2012-03-23 23:59 +0100
    Re: Documentation, assignment in expression. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-03-23 21:09 -0400
      Re: Documentation, assignment in expression. Alexander Blinne <news@blinne.net> - 2012-03-25 14:18 +0200
        Re: Documentation, assignment in expression. Tim Chase <python.list@tim.thechases.com> - 2012-03-25 08:03 -0500
          Re: Documentation, assignment in expression. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-26 05:36 +0000
            Re: Documentation, assignment in expression. Terry Reedy <tjreedy@udel.edu> - 2012-03-26 12:00 -0400
          Re: Documentation, assignment in expression. Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-03-26 15:59 +0200
            Re: Documentation, assignment in expression. Tim Chase <python.list@tim.thechases.com> - 2012-03-26 12:42 -0500
        Re: Documentation, assignment in expression. Chris Angelico <rosuav@gmail.com> - 2012-03-26 00:11 +1100
        Re: Documentation, assignment in expression. Tim Chase <python.list@tim.thechases.com> - 2012-03-25 08:48 -0500
          Re: Documentation, assignment in expression. Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-25 17:16 +0200
            Re: Documentation, assignment in expression. Tim Chase <python.list@tim.thechases.com> - 2012-03-25 13:22 -0500
            Re: Documentation, assignment in expression. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-26 05:47 +0000
            Re: Documentation, assignment in expression. Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-03-26 04:52 -0400
              Re: Documentation, assignment in expression. Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-26 12:56 +0200
                Re: Documentation, assignment in expression. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2012-03-26 14:13 +0300
                  Re: Documentation, assignment in expression. Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-26 13:58 +0200
          Re: Documentation, assignment in expression. rusi <rustompmody@gmail.com> - 2012-03-25 09:17 -0700
          Re: Documentation, assignment in expression. mwilson@the-wire.com - 2012-03-25 19:09 -0400
            Re: Documentation, assignment in expression. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-03-25 22:29 -0400
              Re: Documentation, assignment in expression. mwilson@the-wire.com - 2012-03-26 07:27 -0400
        Re: Documentation, assignment in expression. Chris Angelico <rosuav@gmail.com> - 2012-03-26 01:11 +1100
          Re: Documentation, assignment in expression. Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-25 17:17 +0200
        Re: Documentation, assignment in expression. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-03-25 18:59 -0400
          Re: Documentation, assignment in expression. Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-03-26 15:54 +0200
            Re: Documentation, assignment in expression. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-03-26 12:16 -0400
        Re: Documentation, assignment in expression. Tim Chase <python.list@tim.thechases.com> - 2012-03-26 05:14 -0500
    Re: Documentation, assignment in expression. Roy Smith <roy@panix.com> - 2012-03-23 21:37 -0400

Page 2 of 2 — ← Prev page 1 [2]

#22173

Dennis Lee Bieber wrote:

> On Sun, 25 Mar 2012 19:09:12 -0400, mwilson@the-wire.com declaimed the
> following in gmane.comp.python.general:
> 
> 
>> Most of my database programs wind up having the boilerplate (not tested):
>> 
>> def rowsof (cursor):
>>     names = [x[0] for x in cursor.description]
>>     r = cursor.fetchone()
>>     while r:
>>         yield dict (zip (names, r))
>>         r = cursor.fetchone()
>>
> 
> In my (limited) experience, the main loop above could be replaced
> with:
> 
> for r in cursor:
> yield dict(zip(names, r))

I think your experience is more recent than mine.  I'll change my 
boilerplate next time around.

	Mel.

[toc] | [prev] | [next] | [standalone]

#22139

On Mon, Mar 26, 2012 at 12:48 AM, Tim Chase
<python.list@tim.thechases.com> wrote:
> Yeah, it has the same structure internally, but I'm somewhat surprised that
> the DB connection object doesn't have an __iter__() that does something like
> this automatically under the covers.

Sure. That's definitely the truly Pythonic technique. If I build a C++
object that acts like an array, it's going to overload the []
dereference operator - and if I build a Python object that returns a
series of things, it's going to be an iterable.

> In my past years of C programming, I've accidentally omitted the second "="
> in a comparison test numerous times, requiring me to track down the missing
> character.  When I finally catch it, it's obvious what the problem is, but
> I've come to love having Python yell at me contextually.

This is where compiler warnings come in handy. GCC will, in what I
told someone was "Perls of Wisdom mode" (with the -Wall option - yes,
it is that bad a pun), recommend clarification of the worst offenders
of this sort. And in the common case where you're comparing against a
constant, quite a few compilers will alert you to the fact that your
condition is always true/always false (eg "if (x=3) ;"). Many problems
can be solved in multiple ways; sometimes there's a clear "best way",
other times it really doesn't matter matter matter matter matter.

ChrisA

[toc] | [prev] | [next] | [standalone]

#22142

On 3/25/2012 16:11, Chris Angelico wrote:
> On Mon, Mar 26, 2012 at 12:48 AM, Tim Chase
> <python.list@tim.thechases.com>  wrote:
>> Yeah, it has the same structure internally, but I'm somewhat surprised that
>> the DB connection object doesn't have an __iter__() that does something like
>> this automatically under the covers.
>
> Sure. That's definitely the truly Pythonic technique. If I build a C++
> object that acts like an array, it's going to overload the []
> dereference operator - and if I build a Python object that returns a
> series of things, it's going to be an iterable.

STL's containers are *heavily* based on iterators. There are forward 
iterators, bidirectional iterators and even random access iterators.
You can also write (in C++11)
   int my_array[5] = {1, 2, 3, 4, 5};
   for (int &x : my_array)
     x *= 2;
It works with every container or object which returns iterators through 
begin() and end().
Note the ampersand which means "get the reference of".

Kiuhnm

[toc] | [prev] | [next] | [standalone]

#22148

On Sun, 25 Mar 2012 08:48:31 -0500, Tim Chase
<python.list@tim.thechases.com> declaimed the following in
gmane.comp.python.general:


> Yeah, it has the same structure internally, but I'm somewhat 
> surprised that the DB connection object doesn't have an 
> __iter__() that does something like this automatically under the 
> covers.
>
	I believe being able to use the connection object directly for
queries is considered a short-cut feature... If you use the longer form

con = db.connect()
cur = con.cursor()

	the cursor object, in all that I've worked with, does function for
iteration

	for rec in cur:
		#do stuff
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#22190

Am 26.03.2012 00:59 schrieb Dennis Lee Bieber:

> If you use the longer form
>
> con = db.connect()
> cur = con.cursor()
>
> the cursor object, in all that I've worked with, does function for
> iteration

I use this form regularly with MySQLdb and am now surprised to see that 
this is optional according to http://www.python.org/dev/peps/pep-0249/.

So a database cursor is not required to be iterable, alas.


Thomas

[toc] | [prev] | [next] | [standalone]

#22201

On Mon, 26 Mar 2012 15:54:52 +0200, Thomas Rachel
<nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de>
declaimed the following in gmane.comp.python.general:

> Am 26.03.2012 00:59 schrieb Dennis Lee Bieber:
> 
> > If you use the longer form
> >
> > con = db.connect()
> > cur = con.cursor()
> >
> > the cursor object, in all that I've worked with, does function for
> > iteration
> 
> I use this form regularly with MySQLdb and am now surprised to see that 
> this is optional according to http://www.python.org/dev/peps/pep-0249/.
> 
> So a database cursor is not required to be iterable, alas.
>

	Sounds like it may be time to do a survey...

	MySQLdb		iterable cursor
					Cursor, DictCursor, SSCursor, SSDictCursor (the
first two suck the entire result set to the client and then feed it to
the application, the latter two keep the results on the server and fetch
them as needed; the Dict versions obviously return dictionaries, the
others return tuples)

	SQLite3 		iterable cursor
					Dictionary-like cursor using a row-factory (in
Python 2.5 documentation: 13.13.6.2 Accessing columns by name instead of
by index )

	Psycopg		iterable cursor
					dictionary-like cursor
http://initd.org/psycopg/docs/extras.html#connection-and-cursor-subclasses

	Pygresql 		iterable cursor
					dictresult() ?

	py-postgresql	unknown -- the only documentation I found appears to
be for the NON-DB-API interface
					Row object supports index or key access

	pypgsql		NOT iterable (based on readme and source)
					Result object supports index or key access

	Can anyone add to this? mxODBC, pyodbc, M$ SQL server?

	One thing I note in the above is that ALL of those adapters have
built-in means of accessing return data as a dictionary, so the OP's
generator function to create dictionary values is likely superfluous,
and may even be a bottleneck in processing.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#22170

On 03/25/12 17:59, Dennis Lee Bieber wrote:
> On Sun, 25 Mar 2012 08:48:31 -0500, Tim Chase
>> Yeah, it has the same structure internally, but I'm somewhat
>> surprised that the DB connection object doesn't have an
>> __iter__() that does something like this automatically under the
>> covers.
>>
> 	I believe being able to use the connection object directly for
> queries is considered a short-cut feature... If you use the longer form
>
> con = db.connect()
> cur = con.cursor()
>
> 	the cursor object, in all that I've worked with, does function for
> iteration
>
> 	for rec in cur:
> 		#do stuff

Interesting.  Either this is something special for a particular 
DB back-end, or has been added since I went hunting (back with 
mxODBC and Python2.4).  I wouldn't be surprised if the latter was 
the case, as my code is nigh identical to yours.

  conn = db.DriverConnect(connection_string)
  cursor = conn.cursor()
  cursor.execute(sql, params)
  for row in cursor: # in the above 2.4 + mxODBC, this fails
    process(row)

I'd be interested to know the underlying implementation's 
efficiency, hopefully using .fetchmany() under the hood.  My 
understanding is that the .fetchmany() loop is the best way to do 
it, as the .fetchone() gets chatty with the DB (but is more 
efficient if you only need one row from a multi-result query), 
and the .fetchall() can blow out memory on large datasets.

-tkc

[toc] | [prev] | [next] | [standalone]

#22108

In article <4f6d0060$0$6634$9b4e6d93@newsspool2.arcor-online.net>,
 Alexander Blinne <news@blinne.net> wrote:

> The last sentence "For example, in the current version of Python file 
> objects support the iterator protocol, so you can now write simply 
> (for line in file:)" ...

In general, words like "current", "previous", and "next" don't belong in 
documentation.  The timepoint to which they refer changes as soon as 
they're published.  Much better to say, "as of version x.y..."

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web