Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Documentation, assignment in expression. (http://www.velocityreviews.com/forums/t944676-documentation-assignment-in-expression.html)

Alexander Blinne 03-23-2012 10:59 PM

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

Dennis Lee Bieber 03-24-2012 01:09 AM

Re: Documentation, assignment in expression.
 
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/


Roy Smith 03-24-2012 01:37 AM

Re: Documentation, assignment in expression.
 
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..."

Alexander Blinne 03-25-2012 12:18 PM

Re: Documentation, assignment in expression.
 
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".

Tim Chase 03-25-2012 01:03 PM

Re: Documentation, assignment in expression.
 
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









Chris Angelico 03-25-2012 01:11 PM

Re: Documentation, assignment in expression.
 
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

Tim Chase 03-25-2012 01:48 PM

Re: Documentation, assignment in expression.
 
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




Chris Angelico 03-25-2012 02:11 PM

Re: Documentation, assignment in expression.
 
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

rusi 03-25-2012 04:17 PM

Re: Documentation, assignment in expression.
 
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

Tim Chase 03-25-2012 06:22 PM

Re: Documentation, assignment in expression.
 
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





All times are GMT. The time now is 09:00 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.