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 1 of 2  [1] 2  Next page →

#22102 — Documentation, assignment in expression.

Hi,

I think this section of the docs needs some kind of rewrite:

<http://docs.python.org/faq/design.html#why-can-t-i-use-an-assignment-in-an-expression>

While it is great to discuss the reasons for not allowing an assignment
in an expression, I feel that the given example is some kind of
outdated. 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:)" makes me think that this section was written
while that syntax was still new. No one I know would ever write
something like this:

> while True:
>     line = f.readline()
>     if not line:
>         break
>     ... # do something with line

I think at least we need a new example. Any ideas?

Greetings
Alexander

[toc] | [next] | [standalone]

#22107

On Fri, 23 Mar 2012 23:59:44 +0100, Alexander Blinne <news@blinne.net>
declaimed the following in gmane.comp.python.general:

> Hi,
> 
> I think this section of the docs needs some kind of rewrite:
> 
> <http://docs.python.org/faq/design.html#why-can-t-i-use-an-assignment-in-an-expression>
> 
> While it is great to discuss the reasons for not allowing an assignment
> in an expression, I feel that the given example is some kind of
> outdated. 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:)" makes me think that this section was written
> while that syntax was still new. No one I know would ever write
> something like this:
> 
> > while True:
> >     line = f.readline()
> >     if not line:
> >         break
> >     ... # do something with line
> 
> I think at least we need a new example. Any ideas?
>
	But remember -- this is a section on why no "assignment in
expression"...

	That means 

for line in f:
	#do stuff

is the counter to the equivalent C-style

while (line = f.readline() ):	#mixing C style with Python calls
	# do stuff

	The section is not meant to be an advocate for or against your true
Python design using an infinite loop, and separate input line.

	The emphasis on "current version" might do with updating -- by
explicitly stating when the iteration came in...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#22135

I am not sure I understand your argument. The doc section states that

" [...] in Python you’re forced to write this:

while True:
    line = f.readline()
    if not line:
        break
    ... # do something with line".

That simply isn't true as one can simply write:

for line in f:
	#do stuff

which is the exact counter of the C idiom that C or perl people try to
use and complained about when they were really forced to write the above
lengthy while True loop. So there is no reason to want to do "assignment
in expression", so no real reason to use this example to explain why
they aren't there in python. I totally agree with the
error-handling-reason not allowing them.

I agree with Roy Smith saying that documentation shouldn't refer to the
"current version".

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

#22136

On 03/25/12 07:18, Alexander Blinne wrote:
> I am not sure I understand your argument. The doc section states that
>
> " [...] in Python you’re forced to write this:
>
> while True:
>      line = f.readline()
>      if not line:
>          break
>      ... # do something with line".
>
> That simply isn't true as one can simply write:
>
> for line in f:
> 	#do stuff

I think the complaint was backed by a bad example.  Perhaps a DB 
example works better.  With assignment allowed in an evaluation, 
you'd be able to write

   while data = conn.fetchmany():
     for row in data:
       process(row)

whereas you have to write

   while True:
     data = conn.fetchmany()
     if not data: break
     for row in data:
       process(row)

Granted, this can be turned into an iterator with a yield, making 
the issue somewhat moot:

   def db_iter(conn, *args, **kwargs):
     while True:
       data = conn.fetchmany(rows, *args, **kwargs)
       if not data: break
       for row in data:
         yield row

   for row in db_iter(conn):
     proecss(row)

-tkc

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

#22155

On Sun, 25 Mar 2012 08:03:14 -0500, Tim Chase wrote:

> I think the complaint was backed by a bad example.  Perhaps a DB example
> works better.  With assignment allowed in an evaluation, you'd be able
> to write
> 
>    while data = conn.fetchmany():
>      for row in data:
>        process(row)

Yes, but why would you want to? Apart from making your code hard to read. 
Better written as:

while data = conn.fetchmany():  # THIS IS NOT A TYPO
    for row in data:
        process(row)


When you need to write a comment explaining that something isn't a typo, 
that's a good clue that you shouldn't do it *wink*

But seriously, assignment as an expression is a pretty major code-smell. 
Even when it's innocent, it should still fire off warning alarms, because 
how do you know if it's innocent or not until you've studied the code?

(Comments, like the above, are prone to get out of date with the code, 
and can't be entirely trusted.)

Python avoids this code smell by prohibiting assignment as an expression. 
Functional languages avoid it by prohibiting assignment. Other languages 
may choose to do differently. If all languages did exactly what C does, 
they'd all be C.

(I seem to recall a language that used a single = for both assignment and 
equality testing, guessing which one you meant from context. BASIC 
perhaps? Whatever it was, I'm pretty sure they regretted it.)


> whereas you have to write
> 
>    while True:
>      data = conn.fetchmany()
>      if not data: break
>      for row in data:
>        process(row)

Or even:

data = 'SENTINEL'  # Any true value will do.
while data:
    data = conn.fetchmany()
    for row in data:
        process(row)


There's no need to break out of the while loop early, because `for row in 
<empty>` is a null-op.




-- 
Steven

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

#22199

On 3/26/2012 1:36 AM, Steven D'Aprano wrote:
>
> (I seem to recall a language that used a single = for both assignment and
> equality testing, guessing which one you meant from context. BASIC
> perhaps?

Right. In some Basics, such as MS GW-Basic (I still have their book), a 
= b = c meant a = (b = c), or in Python, a = b==c.

-- 
Terry Jan Reedy

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

#22189

Am 25.03.2012 15:03 schrieb Tim Chase:
> Perhaps a DB example
> works better. With assignment allowed in an evaluation, you'd be able to
> write
>
> while data = conn.fetchmany():
>     for row in data:
>         process(row)
>
> whereas you have to write
>
> while True:
>     data = conn.fetchmany()
>     if not data: break
>     for row in data:
>         process(row)

Or simpler

for data in iter(conn.fetchmany, []):
     for row in data:
         process(row)

provided that a block of rows is returned as a list - which might be 
different among DB engines.


Thomas

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

#22205

On 03/26/12 08:59, Thomas Rachel wrote:
> Am 25.03.2012 15:03 schrieb Tim Chase:
>> while True:
>>      data = conn.fetchmany()
>>      if not data: break
>>      for row in data:
>>          process(row)
>
> Or simpler
>
> for data in iter(conn.fetchmany, []):
>       for row in data:
>           process(row)

Nice!  That's the first time I've seen the 2-parameter version of 
iter() improve things :-)  (I've seen it once or twice before in 
the 2-param form, and wondered why it wasn't written in a clearer 
way).  Also, I was surprised to learn that the sentinel was 
available as far back as 2.2 (I knew about the 1-param version as 
far back as 2.3 when I became more serious about Python).

-tkc

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

#22137

On Mon, Mar 26, 2012 at 12:03 AM, Tim Chase
<python.list@tim.thechases.com> wrote:
> Granted, this can be turned into an iterator with a yield, making the issue
> somewhat moot:

No, just moving the issue to the iterator. Your iterator has exactly
the same structure in it.

Personally, I quite like assignment-in-conditional notation. Yes, it's
a pretty common cause of problems; but what happened to the
"consenting adults" policy? Python permits operator overloading and
even the reassignment of builtins, both of which can cause similar
confusion.

But, that's the choice Python's made. And being able to use the same
symbol for assignment and comparison does have its advantages.

ChrisA

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

#22138

On 03/25/12 08:11, Chris Angelico wrote:
> On Mon, Mar 26, 2012 at 12:03 AM, Tim Chase
> <python.list@tim.thechases.com>  wrote:
>> Granted, this can be turned into an iterator with a yield, making the issue
>> somewhat moot:
>
> No, just moving the issue to the iterator. Your iterator has exactly
> the same structure in it.

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.

> Personally, I quite like assignment-in-conditional notation. Yes, it's
> a pretty common cause of problems; but what happened to the
> "consenting adults" policy? Python permits operator overloading and
> even the reassignment of builtins, both of which can cause similar
> confusion.

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.

> But, that's the choice Python's made. And being able to use the same
> symbol for assignment and comparison does have its advantages.

The old curmudgeon in me likes the Pascal method of using "=" for 
equality-testing, and ":=" for assignment which feels a little 
closer to mathematical use of "=".

-tkc

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

#22141

On 3/25/2012 15:48, Tim Chase wrote:
> The old curmudgeon in me likes the Pascal method of using "=" for
> equality-testing, and ":=" for assignment which feels a little closer to
> mathematical use of "=".

Unfortunately, ":=" means "is defined as" in mathematics. The "right" 
operator would have been "<-".

Kiuhnm

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

#22144

On 03/25/12 10:16, Kiuhnm wrote:
> On 3/25/2012 15:48, Tim Chase wrote:
>> The old curmudgeon in me likes the Pascal method of using "=" for
>> equality-testing, and ":=" for assignment which feels a little closer to
>> mathematical use of "=".
>
> Unfortunately, ":=" means "is defined as" in mathematics. The "right"
> operator would have been "<-".

Yeah, while I like the "<-" better too, I'm not *quite* old 
enough to have influenced Wirth in his design decisions ;-)

-tkc

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

#22157

On Sun, 25 Mar 2012 17:16:16 +0200, Kiuhnm wrote:

> On 3/25/2012 15:48, Tim Chase wrote:
>> The old curmudgeon in me likes the Pascal method of using "=" for
>> equality-testing, and ":=" for assignment which feels a little closer
>> to mathematical use of "=".
> 
> Unfortunately, ":=" means "is defined as" in mathematics. The "right"
> operator would have been "<-".

That's hardly universal. In approx 20 years of working with mathematics 
textbooks, I've never seen := used until today.

I see that Wikipedia lists no fewer than seven different symbols for "is 
defined as":

http://en.wikipedia.org/wiki/Table_of_mathematical_symbols

including the one I'm familiar with, ≝, or "def" over "=".  

Besides, just because mathematicians use a symbol, doesn't mean 
programming languages can't use it for something else.



-- 
Steven

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

#22164

On Sun, Mar 25, 2012 at 11:16 AM, Kiuhnm
<kiuhnm03.4t.yahoo.it@mail.python.org> wrote:
> On 3/25/2012 15:48, Tim Chase wrote:
>>
>> The old curmudgeon in me likes the Pascal method of using "=" for
>> equality-testing, and ":=" for assignment which feels a little closer to
>> mathematical use of "=".
>
>
> Unfortunately, ":=" means "is defined as" in mathematics. The "right"
> operator would have been "<-".


"Is defined as" is actually pretty reasonable. "Define this to be
that" is a common way to speak about assignment. Its only difference
is the present tense. For example, in Python, "def" stands for
"define", but we can overwrite previous definitions::

    def f(x): return x
    def f(x): return 2
    f(3) == 2

In fact, in pretty every programming language that I know of with a
"define" assignment verb, this is so. For example, in Scheme, x is 2
at the end::

    (define x 1)
    (define x 2)
    x

-- Devin

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

#22171

On 3/26/2012 10:52, Devin Jeanpierre wrote:
> On Sun, Mar 25, 2012 at 11:16 AM, Kiuhnm
> <kiuhnm03.4t.yahoo.it@mail.python.org>  wrote:
>> On 3/25/2012 15:48, Tim Chase wrote:
>>>
>>> The old curmudgeon in me likes the Pascal method of using "=" for
>>> equality-testing, and ":=" for assignment which feels a little closer to
>>> mathematical use of "=".
>>
>>
>> Unfortunately, ":=" means "is defined as" in mathematics. The "right"
>> operator would have been "<-".
>
>
> "Is defined as" is actually pretty reasonable. "Define this to be
> that" is a common way to speak about assignment. Its only difference
> is the present tense. For example, in Python, "def" stands for
> "define", but we can overwrite previous definitions::
>
>      def f(x): return x
>      def f(x): return 2
>      f(3) == 2
>
> In fact, in pretty every programming language that I know of with a
> "define" assignment verb, this is so. For example, in Scheme, x is 2
> at the end::
>
>      (define x 1)
>      (define x 2)
>      x

When you write
   (define x 1)
   (define x 2)
   x
or, in F# and OCaml,
   let x = 1
   let x = 2
   x
you're saying
   x = 1
   {
      x = 2
      x
   }
You don't modify 'x': you hide it by defining another "value" (not 
variable) with the same name.
Indeed,
   let x = 1
   let x = 2
   x
is shorthand for
   let x = 1 in
   let x = 2 in
   x

Kiuhnm

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

#22172

Kiuhnm writes:
> On 3/26/2012 10:52, Devin Jeanpierre wrote:
> > On Sun, Mar 25, 2012 at 11:16 AM, Kiuhnm
> > <kiuhnm03.4t.yahoo.it@mail.python.org>  wrote:
> >> On 3/25/2012 15:48, Tim Chase wrote:
> >>>
> >>> The old curmudgeon in me likes the Pascal method of using "=" for
> >>> equality-testing, and ":=" for assignment which feels a little closer to
> >>> mathematical use of "=".
> >>
> >>
> >> Unfortunately, ":=" means "is defined as" in mathematics. The "right"
> >> operator would have been "<-".
> >
> >
> > "Is defined as" is actually pretty reasonable. "Define this to be
> > that" is a common way to speak about assignment. Its only difference
> > is the present tense. For example, in Python, "def" stands for
> > "define", but we can overwrite previous definitions::
> >
> >      def f(x): return x
> >      def f(x): return 2
> >      f(3) == 2
> >
> > In fact, in pretty every programming language that I know of with a
> > "define" assignment verb, this is so. For example, in Scheme, x is 2
> > at the end::
> >
> >      (define x 1)
> >      (define x 2)
> >      x
> 
> When you write
>    (define x 1)
>    (define x 2)
>    x
> or, in F# and OCaml,
>    let x = 1
>    let x = 2
>    x
> you're saying
>    x = 1
>    {
>       x = 2
>       x
>    }
> You don't modify 'x': you hide it by defining another "value" (not
> variable) with the same name.
> Indeed,
>    let x = 1
>    let x = 2
>    x
> is shorthand for
>    let x = 1 in
>    let x = 2 in
>    x

No, Devin is right about Scheme. On "top level" re-definition is
interpreted as assignment. The following mean the same:

(define x 1) (define x 2) x
(define x 1) (set! x 2) x
       
Local definitions in the beginning of a "body" do not allow duplicate
names at all. The following mean the same:

(let () (define x 1) (define y 2) x)
(letrec* ((x 1) (y 2)) x) ;letrec in older versions (not sure of R6RS)

But (let () (define x 1) (define x 2) x) is still an error. Some
implementations may give it a meaning. Not sure.

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

#22176

On 3/26/2012 13:13, Jussi Piitulainen wrote:
> Kiuhnm writes:
>> On 3/26/2012 10:52, Devin Jeanpierre wrote:
>>> On Sun, Mar 25, 2012 at 11:16 AM, Kiuhnm
>>> <kiuhnm03.4t.yahoo.it@mail.python.org>   wrote:
>>>> On 3/25/2012 15:48, Tim Chase wrote:
>>>>>
>>>>> The old curmudgeon in me likes the Pascal method of using "=" for
>>>>> equality-testing, and ":=" for assignment which feels a little closer to
>>>>> mathematical use of "=".
>>>>
>>>>
>>>> Unfortunately, ":=" means "is defined as" in mathematics. The "right"
>>>> operator would have been "<-".
>>>
>>>
>>> "Is defined as" is actually pretty reasonable. "Define this to be
>>> that" is a common way to speak about assignment. Its only difference
>>> is the present tense. For example, in Python, "def" stands for
>>> "define", but we can overwrite previous definitions::
>>>
>>>       def f(x): return x
>>>       def f(x): return 2
>>>       f(3) == 2
>>>
>>> In fact, in pretty every programming language that I know of with a
>>> "define" assignment verb, this is so. For example, in Scheme, x is 2
>>> at the end::
>>>
>>>       (define x 1)
>>>       (define x 2)
>>>       x
>>
>> When you write
>>     (define x 1)
>>     (define x 2)
>>     x
>> or, in F# and OCaml,
>>     let x = 1
>>     let x = 2
>>     x
>> you're saying
>>     x = 1
>>     {
>>        x = 2
>>        x
>>     }
>> You don't modify 'x': you hide it by defining another "value" (not
>> variable) with the same name.
>> Indeed,
>>     let x = 1
>>     let x = 2
>>     x
>> is shorthand for
>>     let x = 1 in
>>     let x = 2 in
>>     x
>
> No, Devin is right about Scheme. On "top level" re-definition is
> interpreted as assignment. The following mean the same:
>
> (define x 1) (define x 2) x
> (define x 1) (set! x 2) x
>
> Local definitions in the beginning of a "body" do not allow duplicate
> names at all. The following mean the same:
>
> (let () (define x 1) (define y 2) x)
> (letrec* ((x 1) (y 2)) x) ;letrec in older versions (not sure of R6RS)
>
> But (let () (define x 1) (define x 2) x) is still an error. Some
> implementations may give it a meaning. Not sure.

Thanks for the correction. I haven't written a line of code in Scheme 
for 15 years and it shows :(

Kiuhnm

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

#22143

On Mar 25, 6:48 pm, Tim Chase <python.l...@tim.thechases.com> wrote:
>
> The old curmudgeon in me likes the Pascal method of using "=" for
> equality-testing, and ":=" for assignment which feels a little
> closer to mathematical use of "=".
>
> -tkc

Carroll Morgan author of programming from specifications
http://www.cs.ox.ac.uk/publications/books/PfS/ called colon in ':=' as
'make'. So := is 'make equal'  This generalizes nicely to other
specification operators (though not computable) eg :> is 'make greater
than'

So x :> x
can be refined to x := x+1
or to x := x*x if the precondition x > 1 is available

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

#22149

Tim Chase wrote:

> On 03/25/12 08:11, Chris Angelico wrote:
>> On Mon, Mar 26, 2012 at 12:03 AM, Tim Chase
>> <python.list@tim.thechases.com>  wrote:
>>> Granted, this can be turned into an iterator with a yield, making the
>>> issue somewhat moot:
>>
>> No, just moving the issue to the iterator. Your iterator has exactly
>> the same structure in it.
> 
> 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.

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()


	Mel.
> 
>> Personally, I quite like assignment-in-conditional notation. Yes, it's
>> a pretty common cause of problems; but what happened to the
>> "consenting adults" policy? Python permits operator overloading and
>> even the reassignment of builtins, both of which can cause similar
>> confusion.
> 
> 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.
> 
>> But, that's the choice Python's made. And being able to use the same
>> symbol for assignment and comparison does have its advantages.
> 
> The old curmudgeon in me likes the Pascal method of using "=" for
> equality-testing, and ":=" for assignment which feels a little
> closer to mathematical use of "=".
> 
> -tkc

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

#22153

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))

	Though some DB adapters provide a "dictionary cursor" that already
does what this modules does; or provides a way to specify a subclassed
cursor that implements the dictionary cursor internally.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web