[Python-Dev] chained assignment weirdity

2012-11-06 Thread Chris Withers 

Hi All,

I bumped into this using Michael Foord's Mock library.
It feels like a bug to me, but thought I'd ask here before logging one 
in the tracker in case people know that we won't be able to fix it:


On 05/11/2012 13:43, Michael Foord wrote:



class Foo(object):

...  def __setattr__(s, k, v):
...   print k
...

f = Foo()

f.g = f.x = 3

g
x


Hmm, that's definitely counter-intuitive. Worth raising on python-dev?


Well, I guess "it's always been that way", so changing it would be backwards 
incompatible. Feel free to raise it though. :-)


Here's the actual problem I had:


mock = Mock()
inst = mock.Popen.return_value = mock.Popen_instance = Mock(spec=Popen)



Here the *return_value* is set first. So when mock.Popen_instance is assigned 
it already has a parent! (Setting a mock as the return value of another mock 
also establishes the child / parent relationship.)

This is why calls to the instance are then not recorded in "method_calls".


cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Devin Jeanpierre 
On Tue, Nov 6, 2012 at 1:18 AM, Chris Withers  wrote:
> Hi All,
>
> I bumped into this using Michael Foord's Mock library.
> It feels like a bug to me, but thought I'd ask here before logging one in
> the tracker in case people know that we won't be able to fix it:
>
> On 05/11/2012 13:43, Michael Foord wrote:
>>
>>
>>> class Foo(object):

 ...  def __setattr__(s, k, v):
 ...   print k
 ...
>>>
>>> f = Foo()
>>>
>>> f.g = f.x = 3

 g
 x
>>>

It's terrible and counter-intuitive, but it is documented. See:
http://docs.python.org/2/reference/simple_stmts.html#assignment-statements

Notice that it proclaims that target lists are assigned to from left
to right. That's the behavior you've noticed.

On the other hand, one might easily misread this piece of
documentation, which implies right to left assignment:
http://docs.python.org/2/reference/expressions.html#evaluation-order

But the last note doesn't look normative to me.

(I'm not a dev, just trying to be helpful.)

-- Devin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Terry Reedy 

On 11/6/2012 1:18 AM, Chris Withers wrote:

Hi All,

I bumped into this using Michael Foord's Mock library.
It feels like a bug to me, but thought I'd ask here before logging one
in the tracker in case people know that we won't be able to fix it:

On 05/11/2012 13:43, Michael Foord wrote:



class Foo(object):

...  def __setattr__(s, k, v):
...   print k
...

f = Foo()

f.g = f.x = 3

g
x


Hmm, that's definitely counter-intuitive. Worth raising on python-dev?


Well, I guess "it's always been that way", so changing it would be
backwards incompatible. Feel free to raise it though. :-)


You are expecting a chained assignment a = b = c to be parsed as
a = (b = c), as in C and as it should be if assignment is an expression. 
But in Python it is not. The right association would be meaningless 
since (b = c) has no value to be assigned to a.


Python actually parses the chained assignment as (a =) (b =) c.
The relevant grammar production is "assignment_stmt ::=
(target_list "=")+ (expression_list | yield_expression)".
The explanation after the grammar begins with this sentence.

"An assignment statement evaluates the expression list (remember that 
this can be a single expression or a comma-separated list, the latter 
yielding a tuple) and assigns the single resulting object to each of the 
target lists, from left to right."


In other words, in my example, c is assigned to a then b. Please do not 
report documented behavior on the tracker as a bug (and don't encourage 
people to). If you think the above is not clear enough, you *can* 
suggest improvement. Perhaps add an example and explanation such as


a = b, (c,d), *e, f = 1, (2, 3), 4, 5, 6

"The tuple on the right is first assigned to a and then unpacked to b, 
c, d, e, and f, giving them the values 1, 2, 3, [4, 5], and 6."


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Nick Coghlan 
As noted, it's really only counterintuitive if your intuition is primed to
expect C style right to left chained assignments.

Python, on the other hand, is able to preserve primarily left to right
evaluation in this case with only the far right hand expression needing to
be evaluated out of order.

One example that can really make the intended behaviour clear:

*a = *b = iter(range(3))

a ends up as (0,1,2), b ends up as (), because the first assignment
consumes the entire iterable.

My actual advice, though? If the order of assignment really matters, use
multiple assignment statements rather than relying on readers knowing the
assignment order.

Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ctypes is not an acceptable implementation strategy for modules in the standard library?

2012-11-06 Thread Trent Nelson 
On Mon, Nov 05, 2012 at 03:36:00AM -0800, Victor Stinner wrote:
> I'm not sure that ctypes is always available (available on all platforms).

Indeed.  Every non-x86 Snakebite platform has pretty serious issues
with ctypes.  I spent a morning looking into one platform, Solaris
10 on SPARC, and, after building the latest libffi from scratch, it
failed more tests than that box chews amps.

Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Rob Cliffe 


On 06/11/2012 12:01, Nick Coghlan wrote:


As noted, it's really only counterintuitive if your intuition is 
primed to expect C style right to left chained assignments.


Python, on the other hand, is able to preserve primarily left to right 
evaluation in this case with only the far right hand expression 
needing to be evaluated out of order.




It strikes me that a really intuitive language (at least for Westerners 
who read left-to-right) would write assignments as

expression --> target
and then the order of assignment in
expression -> target1 -> target2
could be the natural left-to-right one.
[Sorry, this is more appropriate to Python-ideas, but I couldn't resist 
adding my 2c.]

Rob Cliffe

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.com


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.3): Add examples for opener argument of open (#13424).

2012-11-06 Thread Éric Araujo 
Hi,

Le 05/11/2012 13:04, Georg Brandl a écrit :
> Please heed your Sphinx warnings: the :ref:`dir_fd` needs a link caption, 
> since
> it can't autogenerate one (the dir_fd anchor does not point to a heading).

Okay.  I hadn’t noticed it because I was using my system sphinx-build
instead of a local one and there were many warnings related (I think) to
pyspecific extensions not found.  Will fix (and also simplify the
examples per the reviews I got).

Cheers
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread MRAB 

On 2012-11-06 15:02, Rob Cliffe wrote:


On 06/11/2012 12:01, Nick Coghlan wrote:


As noted, it's really only counterintuitive if your intuition is
primed to expect C style right to left chained assignments.

Python, on the other hand, is able to preserve primarily left to right
evaluation in this case with only the far right hand expression
needing to be evaluated out of order.


It strikes me that a really intuitive language (at least for Westerners
who read left-to-right) would write assignments as
 expression --> target
and then the order of assignment in
 expression -> target1 -> target2
could be the natural left-to-right one.


That would make augmented assignment more difficult. For example, how
would you write the equivalent of "x -= y"?


[Sorry, this is more appropriate to Python-ideas, but I couldn't resist
adding my 2c.]
Rob Cliffe



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Guido van Rossum 
+1 to what Nick said. And I thought about this carefully when
designing the language. It's not a bug. The note about assignment RHS
being evaluated before LHS is normative -- you just have to interpret
RHS as "after the *last* '=' symbol". Assignment itself is *not* an
expression.

On Tue, Nov 6, 2012 at 4:01 AM, Nick Coghlan  wrote:
> As noted, it's really only counterintuitive if your intuition is primed to
> expect C style right to left chained assignments.
>
> Python, on the other hand, is able to preserve primarily left to right
> evaluation in this case with only the far right hand expression needing to
> be evaluated out of order.
>
> One example that can really make the intended behaviour clear:
>
> *a = *b = iter(range(3))
>
> a ends up as (0,1,2), b ends up as (), because the first assignment consumes
> the entire iterable.
>
> My actual advice, though? If the order of assignment really matters, use
> multiple assignment statements rather than relying on readers knowing the
> assignment order.
>
> Cheers,
> Nick.
>
> --
> Sent from my phone, thus the relative brevity :)
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Serhiy Storchaka 

On 06.11.12 14:01, Nick Coghlan wrote:

Python, on the other hand, is able to preserve primarily left to right
evaluation in this case with only the far right hand expression needing
to be evaluated out of order.


I'm surprised, but it is really so.

  >>> {}[print('foo')] = print('bar')
  bar
  foo

I was expecting "foo" before "bar".

Another counterintuitive (and possible wrong) example:

  >>> {print('foo'): print('bar')}
  bar
  foo
  {None: None}


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread R. David Murray 

On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka  
wrote:
> Another counterintuitive (and possible wrong) example:
> 
>>>> {print('foo'): print('bar')}
>bar
>foo
>{None: None}

http://bugs.python.org/issue11205

--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Ned Batchelder 

On 11/6/2012 11:26 AM, R. David Murray wrote:

On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka  
wrote:

Another counterintuitive (and possible wrong) example:

>>> {print('foo'): print('bar')}
bar
foo
{None: None}

http://bugs.python.org/issue11205


This seems to me better left undefined, since there's hardly ever a need 
to know the precise evaluation sequence between keys and values, and 
retaining some amount of "unspecified" to allow for implementation 
flexibility is a good thing.


--Ned.



--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Devin Jeanpierre 
On Nov 6, 2012 1:05 PM, "Ned Batchelder"  wrote:
>
> On 11/6/2012 11:26 AM, R. David Murray wrote:
>>
>> On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka 
wrote:
>>>
>>> Another counterintuitive (and possible wrong) example:
>>>
>>> >>> {print('foo'): print('bar')}
>>> bar
>>> foo
>>> {None: None}
>>
>> http://bugs.python.org/issue11205
>
>
> This seems to me better left undefined, since there's hardly ever a need
to know the precise evaluation sequence between keys and values, and
retaining some amount of "unspecified" to allow for implementation
flexibility is a good thing.

"Left undefined"? The behavior was defined, but CPython didn't follow the
defined behaviour.

--Devin (phone)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Ned Batchelder 


On 11/6/2012 1:19 PM, Devin Jeanpierre wrote:



On Nov 6, 2012 1:05 PM, "Ned Batchelder" > wrote:

>
> On 11/6/2012 11:26 AM, R. David Murray wrote:
>>
>> On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka 
mailto:[email protected]>> wrote:

>>>
>>> Another counterintuitive (and possible wrong) example:
>>>
>>> >>> {print('foo'): print('bar')}
>>> bar
>>> foo
>>> {None: None}
>>
>> http://bugs.python.org/issue11205
>
>
> This seems to me better left undefined, since there's hardly ever a 
need to know the precise evaluation sequence between keys and values, 
and retaining some amount of "unspecified" to allow for implementation 
flexibility is a good thing.


"Left undefined"? The behavior was defined, but CPython didn't follow 
the defined behaviour.




I would change the reference manual to leave it undefined.  Clearly not 
many people have been bothered by the fact that CPython implemented it 
"wrong".  If someone really needs to control whether the keys or values 
are evaluated first, they shouldn't use a dict literal.


--Ned.


--Devin (phone)



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Greg Ewing 

MRAB wrote:

That would make augmented assignment more difficult. For example, how
would you write the equivalent of "x -= y"?


SUBTRACT x FROM y.

CLOSE POST WITH SMILEY.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Guido van Rossum 
On Tue, Nov 6, 2012 at 9:58 AM, Ned Batchelder  wrote:
> On 11/6/2012 11:26 AM, R. David Murray wrote:
>>
>> On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka 
>> wrote:
>>>
>>> Another counterintuitive (and possible wrong) example:
>>>
>>> >>> {print('foo'): print('bar')}
>>> bar
>>> foo
>>> {None: None}
>>
>> http://bugs.python.org/issue11205
>
>
> This seems to me better left undefined, since there's hardly ever a need to
> know the precise evaluation sequence between keys and values, and retaining
> some amount of "unspecified" to allow for implementation flexibility is a
> good thing.

Maybe. Do note that Python tries to be *different* than your average
C++ standard and actually prescribes evaluation orders in most cases.
The idea being that the kind of optimizations that C++ compilers get
to do by moving evaluation order around aren't worth it in Python
anyway, and it's better for the user if there are no arbitrary
differences in this area between Python implementations. Note that I
didn't say "no surprises" -- the post that started this thread shows
that surprises are still possible.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 回复： Python-Dev Digest, Vol 112, Issue 8

2012-11-06 Thread 邓九祥 
I hava some question about Object which "inital" need ,but return "object" in 
mongo shell. So 
 BSONElement initial = p["initial"];
if ( initial.type() != Object ) {
errmsg = "initial has to be an object";
return false;
}
 "initial.type() != Object " will be found ,so "group" command will not run 
forever. What can'i do
Mybe this is my fase, please give me some advise.___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] chained assignment weirdity

2012-11-06 Thread Serhiy Storchaka 

On 06.11.12 21:00, Ned Batchelder wrote:

If someone really needs to control whether the keys or values
are evaluated first, they shouldn't use a dict literal.


Not only a dict literal.

>>> {print('foo'): print('bar') for x in [1]}
bar
foo
{None: None}


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com