Tuple assignment and generators?

[vdrab]

Re: Tuple assignment and generators?

> """[color=blue]
> E.g., after "a = 1;
> b = 1",
> a and b may or may not refer to the same object with the value one,
> depending on the implementation,
> """[/color]

But when in a specific implementation this property _does_ hold for
ints having value 1, I expect the
same behaviour for ints with other values than 1.
I guess I'm kind of weird that way.

[Paul Boddie]

Re: Tuple assignment and generators?

Tim Chase wrote:[color=blue]
>
> I was hoping that there was just some __foo__ property I was
> missing that would have been called in the process of tuple
> unpacking that would allow for a more elegant solution such
> as a generator (or generator method on some object) rather
> than stooping to disassembling opcodes. :)[/color]

I suppose you wanted something like this...

a, b, c, d, e = xyz # first, let's consider a plain object

....to use the iterator "protocol" to populate the tuple elements, like
this:

_iter = xyz.__iter__()
a = _iter.next()
b = _iter.next()
c = _iter.next()
d = _iter.next()
e = _iter.next()

For such plain objects, it is possible to use such a mechanism. Here's
a "countdown" iterator:

class A:
def __init__(self, size):
self.size = size
def __iter__(self):
return B(self.size)

class B:
def __init__(self, size):
self.n = size
def next(self):
if self.n > 0:
self.n -= 1
return self.n
else:
raise StopIteration

xyz = A(5)
a, b, c, d, e = xyz

In fact, similar machinery can be used to acquire new values from a
generator:

def g(size):
while size > 0:
size = size - 1
yield size

a, b, c, d, e = g(5)

Note that if the iterator (specifically, the generator in the second
case) doesn't provide enough values, or provides too many, the tuple
unpacking operation will fail with the corresponding exception message.
Thus, generators which provide infinite or very long sequences will not
work unless you discard trailing values; you can support this either by
adding support for slicing to whatever is providing your sequences or,
if you're using generators anyway, by employing an additional
"limiting" generator:

def limit(it, size):
while size > 0:
yield it.next()
size -= 1

xyz = A(5)
a, b, c, d = limit(iter(xyz) , 4)

The above generator may be all you need to solve your problem, and it
may be the case that such a generator exists somewhere in the standard
library.

Paul

[Boris Borcic]

Re: Tuple assignment and generators?

vdrab wrote:[color=blue][color=green]
>> """
>> E.g., after "a = 1;
>> b = 1",
>> a and b may or may not refer to the same object with the value one,
>> depending on the implementation,
>> """[/color]
>
> But when in a specific implementation this property _does_ hold for
> ints having value 1, I expect the
> same behaviour for ints with other values than 1.
> I guess I'm kind of weird that way.
>[/color]

Are you telling us that you *had* read that doc,
and tripped because it says "depending on the implementation" ,
when it should say "at the choice of the implementation" ?

That's indeed a bit weird, imo.

[vdrab]

Re: Tuple assignment and generators?

> Are you telling us that you *had* read that doc,[color=blue]
> and tripped because it says "depending on the implementation" ,
> when it should say "at the choice of the implementation" ?[/color]

no.
let's see, where to start ... ?
let's say there's a certain property P, for the sake of this loooong
discussion, something
more or less like a class or type's property of "having immutable
values, such that any instance with value X has a single, unique
representation in memory and any two instantiations of objects with
that value X are in fact references to the same object".

Then, for example, python strings have property P whereas python lists
do not:
[color=blue][color=green][color=darkred]
>>> x = "test"
>>> y = "test"
>>> x is y[/color][/color][/color]
True[color=blue][color=green][color=darkred]
>>> x = []
>>> y = []
>>> x is y[/color][/color][/color]
False[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Now, as it turns out, whether or not python integers have property P
_depends_on_the ir_value_.
For small values, they do. For large values they don't. Yes, I
understand about the interpreter optimization. I didn't know this, and
I find it neither evident nor consistent. I don't think the above post
explains this, regardless of how you read "implementation ".

In fact, the whole string of replies after my initial question reminded
me of something I read not too long ago, but didn't quite understand at
the time.
source :
http://www.oreillynet.com/ruby/blog/...iantihype.html

'''
Pedantry: it's just how things work in the Python world. The status
quo is always correct by definition. If you don't like something, you
are incorrect. If you want to suggest a change, put in a PEP,
Python's equivalent of Java's equally glacial JSR process. The
Python FAQ goes to great lengths to rationalize a bunch of broken
language features. They're obviously broken if they're frequently
asked questions, but rather than 'fessing up and saying "we're
planning on fixing this", they rationalize that the rest of the world
just isn't thinking about the problem correctly. Every once in a
while some broken feature is actually fixed (e.g. lexical scoping), and
they say they changed it because people were "confused". Note that
Python is never to blame.
'''

taking this rant with the proverbial grain of salt, I did think it was
funny.

Anyway, thanks for all the attempts to show me.
I will get it in the end.
v.

[Diez B. Roggisch]

Re: Tuple assignment and generators?

vdrab wrote:
[color=blue][color=green]
>> """
>> E.g., after "a = 1;
>> b = 1",
>> a and b may or may not refer to the same object with the value one,
>> depending on the implementation,
>> """[/color]
>
> But when in a specific implementation this property _does_ hold for
> ints having value 1, I expect the
> same behaviour for ints with other values than 1.[/color]

That is an assumption you made. The above sentence is true for that
assumption, but also - and that is the key point here - for the current
implementation.

And to put it frankly: if you'd had spend only half the time it took you to
participate in this argument to think about how one could possibly
implement the behavior you'd thought of, you'd realize that its totally
unfeasible. Try stuffing 2^64 python long objects in your memory to make
that guarantee hold... And then 2^65
[color=blue]
> I guess I'm kind of weird that way.[/color]

Maybe.

Diez

[Sion Arrowsmith]

Re: Tuple assignment and generators?

vdrab <stijndesaeger@ gmail.com> wrote:[color=blue]
>let's say there's a certain property P, for the sake of this loooong
>discussion, something
>more or less like a class or type's property of "having immutable
>values, such that any instance with value X has a single, unique
>representati on in memory and any two instantiations of objects with
>that value X are in fact references to the same object".
>
>Then, for example, python strings have property P whereas python lists
>do not:[/color]

Er, no:
[color=blue][color=green][color=darkred]
>>> x = "test!"
>>> y = "test!"
>>> x == y[/color][/color][/color]
True[color=blue][color=green][color=darkred]
>>> x is y[/color][/color][/color]
False

Strings only get a unique instance if they are valid identifiers.
Again, it's an optimisation issue. As with ints, it
[color=blue]
>_depends_on_th eir_value_.[/color]
[color=blue]
>I find it neither evident nor consistent. I don't think the above post
>explains this, regardless of how you read "implementation ".[/color]

"Implementa tion dependent" => "Any behaviour you observe which is not
explicitly documented is not to be relied upon". Also, "Implementa tion
dependent" => "How this is implemented should be transparent and
irrelevant to the normal user". No, it's not particularly consistent.
Because it doesn't matter.

--
\S -- siona@chiark.gr eenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[vdrab]

Re: Tuple assignment and generators?

oh wow... it gets better...
[color=blue][color=green][color=darkred]
>>> x = "test!"
>>> y = "test!"
>>> x is y[/color][/color][/color]
False[color=blue][color=green][color=darkred]
>>> x = "test"
>>> y = "test"
>>> x is y[/color][/color][/color]
True[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

.... I had no clue.
I guess the take-away lesson is to steer clear from any reliance on
object identity checks, if at all possible. Are there any other such
"optimizati ons" one should like to know about?
v.

[Dave Hansen]

Re: Tuple assignment and generators?

On 5 May 2006 05:23:24 -0700 in comp.lang.pytho n, "vdrab"
<stijndesaeger@ gmail.com> wrote:
[color=blue][color=green]
>> Are you telling us that you *had* read that doc,
>> and tripped because it says "depending on the implementation" ,
>> when it should say "at the choice of the implementation" ?[/color]
>
>no.
>let's see, where to start ... ?
>let's say there's a certain property P, for the sake of this loooong
>discussion, something
>more or less like a class or type's property of "having immutable
>values, such that any instance with value X has a single, unique
>representati on in memory and any two instantiations of objects with
>that value X are in fact references to the same object".[/color]

IOW, property P is "(x == y) => (x is y)" (read "=>" as "implies").

Note that only immutable objects can have property P.
[color=blue]
>
>Then, for example, python strings have property P whereas python lists
>do not:
>[color=green][color=darkred]
>>>> x = "test"
>>>> y = "test"
>>>> x is y[/color][/color]
>True[color=green][color=darkred]
>>>> x = []
>>>> y = []
>>>> x is y[/color][/color]
>False[color=green][color=darkred]
>>>>[/color][/color][/color]

Note this last relationship is _guaranteed_. Lists are not immutable,
and therefore can not have property P.
[color=blue]
>
>Now, as it turns out, whether or not python integers have property P
>_depends_on_th eir_value_.[/color]

From the zen, I believe this falls out from "practicali ty beats
purity."
[color=blue]
>For small values, they do. For large values they don't. Yes, I[/color]

Even that's not necessarily true. The implementation is free to
always create a new immutable object, even for small values.
[color=blue]
>understand about the interpreter optimization. I didn't know this, and
>I find it neither evident nor consistent. I don't think the above post
>explains this, regardless of how you read "implementation ".[/color]

Think about implementation for a moment. Consider the statement

x = some_arbitrary_ integer()

Do you really want the interpreter to go through all the existing
integer objects in the program to see if that particular value exists,
just to guarantee some some later statement

x is y

returns True if x == y?

OK, maybe we can change the "is" operator on immutable objects such
that x is y returns True if x == y. But then you can encounter a
situation where "x is y" but "id(x) != id(y)" Now what?

Perhaps the solution would be to disable the "is" operator and "id"
function for immutable objects. But then _they_ lose generality.
There doesn't seem to be a way to win.

So it all comes down to "who cares?" Immutable objects are immutable.
You can't change them. Object identity is a non-issue.

This is not the case for mutable objects. Consider

a = [1,2,3]
b = [1,2,3]
c = a

a==b
a==c
b==c
a is not b
b is not c
c is a

c.append(4)
[color=blue]
>
>In fact, the whole string of replies after my initial question reminded
>me of something I read not too long ago, but didn't quite understand at
>the time.
>source :
>http://www.oreillynet.com/ruby/blog/...iantihype.html
>[/color]
[...whinge elided...][color=blue]
>
>taking this rant with the proverbial grain of salt, I did think it was
>funny.[/color]

Your original post in its entirety (ignoring the example) was "what
the...? does anybody else get mighty uncomfortable about this? "

The first response (paraphrased) was "No. Why should I? With
immutable objects, I care about ==, not is."

Your response seemed to want to cast doubt on the integrity of the
entire language: "Given this though, what other such beauties are
lurking in the interpreter, under the name of 'implementation
accidents'?"
[color=blue]
>
>Anyway, thanks for all the attempts to show me.
>I will get it in the end.[/color]

I will ignore the double entendre, and simply hope I was of help, and
wish you luck. Regards,
-=Dave

--
Change is inevitable, progress is not.

[Fredrik Lundh]

Re: Tuple assignment and generators?

"vdrab" wrote:
[color=blue]
> I guess the take-away lesson is to steer clear from any reliance on
> object identity checks, if at all possible. Are there any other such
> "optimizati ons" one should like to know about?[/color]

so in your little world, an optimization that speeds things up and saves
memory isn't really an optimization ?

good luck with your future career in programming.

*plonk*

[Diez B. Roggisch]

Re: Tuple assignment and generators?

> ... I had no clue.

We figured that....
[color=blue]
> I guess the take-away lesson is to steer clear from any reliance on
> object identity checks, if at all possible.[/color]

You've been told that quite a few times before that "is" is not intended for
what you used it.

Some people actually listen to what others tell. Others seem to be driven by
the deep desire to make even the tiniest bit of getting-a-grasp a public
affair.

Diez

[vdrab]

Re: Tuple assignment and generators?

> You've been told that quite a few times before that "is" is not intended for[color=blue]
> what you used it.[/color]

I got that. I was cleaning up some code that used "is" incorrectly
immediately after.
[color=blue]
> Some people actually listen to what others tell. Others seem to be driven by
> the deep desire to make even the tiniest bit of getting-a-grasp a public
> affair.[/color]

Not really. I always found python to be true to that -- admittedly
elusive -- principle of least surprise up to now ("special cases aren't
special enough to break the rules", maybe? I don't know. but then you
figured that, right?), and was thrown off quite a bit by the behaviour
described in one of the earlier posts, that is all. I wanted to ask
people's explanations about it and learnt a few things on the way
(thanks Dave). What did you get from all of this?

[Carl Banks]

Re: Tuple assignment and generators?


vdrab wrote:[color=blue]
> I guess the take-away lesson is to steer clear from any reliance on
> object identity checks, if at all possible.[/color]

BINGO!

[color=blue]
> Are there any other such
> "optimizati ons" one should like to know about?[/color]

You don't have to know about them, as long as you use the operators
correctly.

== tests equality. is tests identity. Use is ONLY when you are
testing whether two things are the same object. Otherwise, use ==.
When deciding which operator to use, ask yourself this: would the
result still be true if they were different objects with the same
value? If yes, then use ==. 0 == 0 should be true even if the two
zeros are different objects.

Corrollary:

You should test for singleton objects with is. None, NotImplemented,
and Ellipsis are singleton objects; this is part of the language and
not an implementation detail. You can rely on it.


Carl Banks

[John J. Lee]

Re: Tuple assignment and generators?

"vdrab" <stijndesaeger@ gmail.com> writes:
[...][color=blue]
> In fact, I think my code contains things like "if len(arg) is 0:" and
> so on,[/color]

So you made a mistake. It's OK, you can forgive yourself, nobody will
notice <wink>

[color=blue]
> and I feel I should be able to do so given the way python treats
> (claims to treat?) constant objects, even if I don't care whether the
> values actually represent the same object.[/color]

(By "constant" I assume you mean immutable.)

I'm afraid it sounds like your assumptions about "the way python
treats (claims to treat?) constant objects" were "made up out of your
own head" as Tim Peters once put it :-) Python does not make such
guarantees about the identity of separately-constructed immutable
objects, and that's good, careful design, in my book (you might be
able to see why if you think about what "is" *means* and what it would
take to ensure it *always* remains true for e.g. x is 10E9, where x ==
10E9 but is assigned elsewhere, and at another time during program
execution).

OTOH, it's good practice in Python to use "is" to compare values with
the immutable singleton None ("if x is None"). No harm comes of that,
simply because there is only one None object.


John

[Mel Wilson]

Re: Tuple assignment and generators?

vdrab wrote:[color=blue]
> I guess the take-away lesson is to steer clear from any reliance on
> object identity checks, if at all possible. Are there any other such
> "optimizati ons" one should like to know about?[/color]

Object identity checks are just the thing/numero uno/ichiban
for checking object identity. A code snipped like

def broadcast (self, message):
"Broadcast a message to all the other game players."
for p in all_players:
if p is not self:
p.send (message)

does just what I want and expect it to.

Mel.