Tuple assignment and generators?

[robert]

enriching return values / symetric call&return in P3K ? - Re: Tupleassignment and generators?

Tim Chase wrote:[color=blue]
> Just as a pedantic exercise to try and understand Python a bit better, I
> decided to try to make a generator or class that would allow me to
> unpack an arbitrary number of calculatible values. In this case, just
> zeros (though I just to prove whatever ends up working, having a
> counting generator would be nice). The target syntax would be something
> like
>[color=green][color=darkred]
> >>> a,b,c = zeros()
> >>> q,r,s,t,u,v = zeros()[/color][/color]
>
> where "zeros()" returns an appropriately sized tuple/list of zeros.
>
> I've tried a bit of googling, but all my attempts have just ended up
> pointing to pages that blithly describe tuple assignment, not the
> details of what methods are called on an object in the process.
>
> My first thought was to get it to use a generator:
>
> def zeros():
> while 1: yield 0
>
> However, I get back a "ValueError : too many values to unpack" result.
>
> As a second attempt, I tried a couple of attempts at classes (I started
> with the following example class, only derived from "object" rather than
> "list", but it didn't have any better luck):
>[color=green][color=darkred]
> >>> class zeros(list):[/color][/color]
> ... def __getitem__(sel f,i):
> ... return 0
> ...[color=green][color=darkred]
> >>> z = zeros()
> >>> a,b,c = z[/color][/color]
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> ValueError: need more than 0 values to unpack
>
>
> It looks like I need to have a pre-defined length, but I'm having
> trouble figuring out what sorts of things need to be overridden. It
> seems like I sorta need a
>
> def __len__(self):
> return INFINITY
>
> so it doesn't choke on it. However, how to dupe the interpreter into
> really believing that the object has the desired elements is escaping
> me. Alternatively if there was a "doYouHaveThisM anyElements"
> pseudo-function that was called, I could lie and always return true.
>
> Any hints on what I'm missing?[/color]

Think the use case, you present, is (pythonically) ill as such. if you
want to fill literal variable's do it like: a=b=c=...=0. Otherwise
you'd handle variable lists zeros(7)

Yet there is a real freqent need for adding transparent extra/decorating
return values in cases, where you don't want to break the simple return
scheme (in maybe big existing code). For such use cases check out this
"RICHVALUE" approach with _named_ extra values - no puzzles about
non-matching tuple assignments:

http://aspn.activestate.com/ASPN/Coo.../Recipe/496676 :

....
def f():
return RICHVALUE(7, extra='hello')

ret=f()
print ret, ret+1, ret.extra
....


As I have this need very very often I'd like to see an even more natural
builtin method for enriching return values (both positional and by name)
in Python3000 - maybe by making calling and returning almost symetric!
Yet, this ideas maybe strange ? ...

def f_P3K(*args,**k wargs):
xreturn((7,8), 3, extra=5, *args, **kwargs) # first is main

v = f_P3K() # (7,8)
v,x = f_P3K() # (7,8),3
v,x,*pret,**kwr et= f_P3K()
extra=kwret.get ('extra',-1)


-robert

[vdrab]

Re: Tuple assignment and generators?

> No. Why should you ever care about whether two integers representing[color=blue]
> values are the same object? Your tests should be with `==`, not `is`.[/color]

Given this though, what other such beauties are lurking in the
interpreter, under the name of 'implementation accidents'? One of the
things that drew me to python is the claimed consistency and
orthogonality of both language and implementation, not sacrificing
clarity for performance, minimizing ad-hoc design hacks and weird
gotcha's, etc...
In fact, I think my code contains things like "if len(arg) is 0:" and
so on, 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.
s.

[vdrab]

Re: Tuple assignment and generators?

> beasts. It can get even worse: I can define an object (in C++ as well as in[color=blue]
> python) that is not even equal to itself. Not that I felt the need for that
> so far....[/color]

hehe... now you've picked my curiosity... how?

ps.
def __eq__(self, other): return False
does not count !

[Diez B. Roggisch]

Re: Tuple assignment and generators?

vdrab wrote:
[color=blue][color=green]
>> beasts. It can get even worse: I can define an object (in C++ as well as
>> in python) that is not even equal to itself. Not that I felt the need for
>> that so far....[/color]
>
> hehe... now you've picked my curiosity... how?
>
> ps.
> def __eq__(self, other): return False
> does not count ![/color]

Sure it does! The rich comparison methods can very well be used to define
whatever semantics you want. Now I agree that

def __eq__(self, other):
if self is other:
return False
... # do something more sane


doesn't make much sense usually. Or maybe even never. Still, it illustrates
the point: object identity is not to be confused with two objects being
part of an equality relation.

Diez

[Fredrik Lundh]

Re: Tuple assignment and generators?

"vdrab" wrote:
[color=blue]
> Given this though, what other such beauties are lurking in the
> interpreter, under the name of 'implementation accidents'? One of the
> things that drew me to python is the claimed consistency and
> orthogonality of both language and implementation, not sacrificing
> clarity for performance, minimizing ad-hoc design hacks and weird
> gotcha's, etc...[/color]

so anything you don't understand, and cannot be bothered to look up in
the documentation, just has to be an inconsistent ad-hoc weird-gotcha
design ?

I think we can all safely *plonk* you know.

</F>

[Diez B. Roggisch]

Re: Tuple assignment and generators?

vdrab wrote:
[color=blue][color=green]
>> No. Why should you ever care about whether two integers representing
>> values are the same object? Your tests should be with `==`, not `is`.[/color]
>
> Given this though, what other such beauties are lurking in the
> interpreter, under the name of 'implementation accidents'? One of the
> things that drew me to python is the claimed consistency and
> orthogonality of both language and implementation, not sacrificing
> clarity for performance, minimizing ad-hoc design hacks and weird
> gotcha's, etc...
> In fact, I think my code contains things like "if len(arg) is 0:" and
> so on, 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]

Python doesn't claim that 0 is 0 == True. You are abusing the "is" operator.
The only (or at least 99%) occasions I use "is" are

if foo is None:
...

as None is guaranteed to be a singleton object.

The thing you observe as accident is that sometimes "0 is 0" is true just
because of an optimization of number objects allocation. Such things happen
in the "real" world - other examples are string-interning in e.g. the JVM
(and I bet they have a similar scheme to boxed number object allocation as
python has).

Diez

[vdrab]

Re: Tuple assignment and generators?

> so anything you don't understand, and cannot be bothered to look up in[color=blue]
> the documentation, just has to be an inconsistent ad-hoc weird-gotcha
> design ?[/color]

Does the documentation mention that "x is y" returns True when they are
both 0 but not when they are 100001 ? If so, I stand corrected. *plonk*
away ...
s.

[Alexandre Fayolle]

Re: Tuple assignment and generators?

Le 05-05-2006, Diez <deets@nospam.w eb.de> nous disait:
[color=blue]
> The thing you observe as accident is that sometimes "0 is 0" is true just
> because of an optimization of number objects allocation. Such things happen
> in the "real" world - other examples are string-interning in e.g. the JVM
> (and I bet they have a similar scheme to boxed number object allocation as
> python has).[/color]

String interning is available in Python too, by using the intern()
builtin function.

--
Alexandre Fayolle LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations
Développement logiciel sur mesure: http://www.logilab.fr/services
Python et calcul scientifique: http://www.logilab.fr/science

[Daniel Nogradi]

Re: Tuple assignment and generators?

> > Given this though, what other such beauties are lurking in the[color=blue][color=green]
> > interpreter, under the name of 'implementation accidents'? One of the
> > things that drew me to python is the claimed consistency and
> > orthogonality of both language and implementation, not sacrificing
> > clarity for performance, minimizing ad-hoc design hacks and weird
> > gotcha's, etc...[/color]
>
> so anything you don't understand, and cannot be bothered to look up in
> the documentation, just has to be an inconsistent ad-hoc weird-gotcha
> design ?
>
> I think we can all safely *plonk* you know.[/color]

I was just at a point when I thought I learned something but got
confused again after trying the following and unfortunately didn't
find an answer in the docs.
[color=blue][color=green][color=darkred]
>>> a = 10
>>> b = 10
>>> id(a)[/color][/color][/color]
134536516[color=blue][color=green][color=darkred]
>>> id(b)[/color][/color][/color]
134536516

So the two memory addesses are the same, but
[color=blue][color=green][color=darkred]
>>> a = 10000
>>> b = 10000
>>> id(a)[/color][/color][/color]
134604216[color=blue][color=green][color=darkred]
>>> id(b)[/color][/color][/color]
134604252

and they are not the same (I restarted the interpreter between the two
cases). So how is this now? Sorry if it's too trivial, but I simply
don't get it.

[Fredrik Lundh]

Re: Tuple assignment and generators?

"vdrab" wrote:
[color=blue]
> Does the documentation mention that "x is y" returns True when they are
> both 0 but not when they are 100001 ?[/color]

language reference, comparisions (is operator):

The operators is and is not test for object identity: x is y is true if and
only if x and y are the same object

language reference, objects:

"Even the importance of object identity is affected in some sense: for
immutable types, operations that compute new values may actually
return a reference to any existing object with the same type and value,
while for mutable objects this is not allowed. 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, but after "c = []; d = []", c and d are
guaranteed to refer to two different, unique, newly created empty lists.

(note the use of "may or may not" and "depending on the implementation" )

</F>

[Diez B. Roggisch]

Re: Tuple assignment and generators?

>[color=blue]
> I was just at a point when I thought I learned something but got
> confused again after trying the following and unfortunately didn't
> find an answer in the docs.
>[color=green][color=darkred]
>>>> a = 10
>>>> b = 10
>>>> id(a)[/color][/color]
> 134536516[color=green][color=darkred]
>>>> id(b)[/color][/color]
> 134536516
>
> So the two memory addesses are the same, but
>[color=green][color=darkred]
>>>> a = 10000
>>>> b = 10000
>>>> id(a)[/color][/color]
> 134604216[color=green][color=darkred]
>>>> id(b)[/color][/color]
> 134604252
>
> and they are not the same (I restarted the interpreter between the two
> cases). So how is this now? Sorry if it's too trivial, but I simply
> don't get it.[/color]

It's an optimization scheme that will cache number objects up to a certain
value for optimized reuse. However this is impractical for larger numbers -
you only hold a table of lets say 1000 or so objects. Then the look up of
one of those objects is extremely fast, whereas the construction of
arbitrary numbers is somewhat more expensive.

And as "is" is the operator for testing if objects are identical and _not_
the operator for testing of equality (which is ==), the above can happen.
And is totally irrelevant from a practical POV (coding-wise that is - it
_is_ a relevant optimization).

Diez

[Daniel Nogradi]

Re: Tuple assignment and generators?

> > I was just at a point when I thought I learned something but got[color=blue][color=green]
> > confused again after trying the following and unfortunately didn't
> > find an answer in the docs.
> >[color=darkred]
> >>>> a = 10
> >>>> b = 10
> >>>> id(a)[/color]
> > 134536516[color=darkred]
> >>>> id(b)[/color]
> > 134536516
> >
> > So the two memory addesses are the same, but
> >[color=darkred]
> >>>> a = 10000
> >>>> b = 10000
> >>>> id(a)[/color]
> > 134604216[color=darkred]
> >>>> id(b)[/color]
> > 134604252
> >
> > and they are not the same (I restarted the interpreter between the two
> > cases). So how is this now? Sorry if it's too trivial, but I simply
> > don't get it.[/color]
>
> It's an optimization scheme that will cache number objects up to a certain
> value for optimized reuse. However this is impractical for larger numbers-
> you only hold a table of lets say 1000 or so objects. Then the look up of
> one of those objects is extremely fast, whereas the construction of
> arbitrary numbers is somewhat more expensive.
>
> And as "is" is the operator for testing if objects are identical and _not_
> the operator for testing of equality (which is ==), the above can happen.
> And is totally irrelevant from a practical POV (coding-wise that is - it
> _is_ a relevant optimization).[/color]

Thanks a lot! So after all I really learned something :)

[vdrab]

Re: Tuple assignment and generators?

>
language reference, objects:

"Even the importance of object identity is affected in some sense:
for
immutable types, operations that compute new values may actually
return a reference to any existing object with the same type and
value,
while for mutable objects this is not allowed. 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, but after "c = []; d = []", c and
d are
guaranteed to refer to two different, unique, newly created empty
lists.

(note the use of "may or may not" and "depending on the
implementation" )

</F>

That, I knew. What I did not know, nor get from this explanation, is
that this behaviour "may" differ
not only within the same implementation, but with instances of the same
class or type (in this case, 'int'). Is this really a case of me being
too dumb or too lazy, or could it just be that this behaviour is not
all that consistent ?
v.
v.

[Diez B. Roggisch]

Re: Tuple assignment and generators?

vdrab wrote:
[color=blue]
> That, I knew. What I did not know, nor get from this explanation, is
> that this behaviour "may" differ
> not only within the same implementation, but with instances of the same
> class or type (in this case, 'int').[/color]

"""
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,
"""

Diez

[Duncan Booth]

Re: Tuple assignment and generators?

Daniel Nogradi wrote:
[color=blue][color=green][color=darkred]
>>>> a = 10
>>>> b = 10
>>>> id(a)[/color][/color]
> 134536516[color=green][color=darkred]
>>>> id(b)[/color][/color]
> 134536516
>
> So the two memory addesses are the same, but
>[color=green][color=darkred]
>>>> a = 10000
>>>> b = 10000
>>>> id(a)[/color][/color]
> 134604216[color=green][color=darkred]
>>>> id(b)[/color][/color]
> 134604252
>
> and they are not the same (I restarted the interpreter between the two
> cases). So how is this now? Sorry if it's too trivial, but I simply
> don't get it.
>[/color]
If two immutable values are the same, then the interpreter has the right to
simply reuse the same value. Apart from the guarantee that it will do this
with None everything else is left open.

The current C-Python implementation will reuse small integers but not large
integers, it also reuses some strings. It reuses the empty tuple but not
(so far as I know) any other tuples. This could change at any time and
other Python implementations may do totally different things here.

Just because you saw it reusing a small value such as 10 doesn't mean that
there cannot be other small integers with the value 10 which aren't the
same as that one. Back before Python had a separate bool type, it used to
use two different integers for 0 (and two for 1), so you could (by an
accident of implementation) tell whether a value had been created by a
comparison operator. So far as I know, there is nothing stopping the author
of an extension written in C continuing to create their own versions of
small numbers today.