Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #47554 > unrolled thread

Newbie: question regarding references and class relationships

Back to article view | Back to comp.lang.python

Contents

  Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 14:18 +0100
    Re: Newbie: question regarding references and class relationships Roy Smith <roy@panix.com> - 2013-06-10 09:35 -0400
      Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 14:57 +0100
        Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 15:00 +0100
        Re: Newbie: question regarding references and class relationships Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-10 13:56 -0600
          Re: Newbie: question regarding references and class relationships Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-11 17:02 -0700
    Re: Newbie: question regarding references and class relationships Peter Otten <__peter__@web.de> - 2013-06-10 15:49 +0200
      Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 14:59 +0100
        Re: Newbie: question regarding references and class relationships Peter Otten <__peter__@web.de> - 2013-06-10 16:28 +0200
          Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 15:38 +0100
            Re: Newbie: question regarding references and class relationships Peter Otten <__peter__@web.de> - 2013-06-10 17:05 +0200
              Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 16:20 +0100
                Re: Newbie: question regarding references and class relationships Peter Otten <__peter__@web.de> - 2013-06-10 17:55 +0200
                  Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 17:09 +0100
                    Re: Newbie: question regarding references and class relationships Peter Otten <__peter__@web.de> - 2013-06-10 19:07 +0200
                      Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 18:42 +0100
                        Re: Newbie: question regarding references and class relationships Dave Angel <davea@davea.name> - 2013-06-10 15:36 -0400
                          Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 21:31 +0100
                    Re: Newbie: question regarding references and class relationships Terry Jan Reedy <tjreedy@udel.edu> - 2013-06-10 15:51 -0400
                      Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 21:13 +0100
                        Re: Newbie: question regarding references and class relationships Terry Jan Reedy <tjreedy@udel.edu> - 2013-06-10 18:07 -0400
                          Re: Newbie: question regarding references and class relationships Grant Edwards <invalid@invalid.invalid> - 2013-06-10 22:39 +0000
                            Re: Newbie: question regarding references and class relationships Chris Angelico <rosuav@gmail.com> - 2013-06-11 08:54 +1000
                            Re: Newbie: question regarding references and class relationships Tim Chase <python.list@tim.thechases.com> - 2013-06-10 18:24 -0500
                            Re: Newbie: question regarding references and class relationships Dave Angel <davea@davea.name> - 2013-06-10 19:26 -0400
                            Re: Newbie: question regarding references and class relationships Jason Swails <jason.swails@gmail.com> - 2013-06-10 23:49 -0400
    Re: Newbie: question regarding references and class relationships Terry Jan Reedy <tjreedy@udel.edu> - 2013-06-10 15:54 -0400
      Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-10 21:09 +0100
    Re: Newbie: question regarding references and class relationships Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-11 16:50 -0700
      Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-13 13:06 +0100
        Re: Newbie: question regarding references and class relationships Chris Angelico <rosuav@gmail.com> - 2013-06-14 00:07 +1000
          Re: Newbie: question regarding references and class relationships Rui Maciel <rui.maciel@gmail.com> - 2013-06-13 19:23 +0100

Page 2 of 2 — ← Prev page 1 [2]

#47606

On 6/10/2013 4:13 PM, Rui Maciel wrote:
> Terry Jan Reedy wrote:
>
>> Three answers:
>> Look how much trouble it has already caused ;-)
>> Since you are a self-declared newbie, believe us!
>> Since, be definition, useless code can do no good, it can only cause
>> trouble. Think about it.
>
> I don't doubt that there might good reasons for that, but it is always
> preferable to get the rationale behind a decision to be able to understand
> how things work and how to do things properly.

I agree actually. But sometimes is it hard to articulate 'good reasons' 
for a principle based on the integration of over a decade of experience. 
I was really trying to point to the difference between

'I will not accept the experience-based advice until enough good reasons 
are presented.' and

'I will provisionally accept the advice but I would still like to know why.'

Another principle similar to 'Don't add extraneous code' is 'Don't 
rebind builtins*'. I have a separate post for that.

Terry

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

#47610

On 2013-06-10, Terry Jan Reedy <tjreedy@udel.edu> wrote:

> Another principle similar to 'Don't add extraneous code' is 'Don't 
> rebind builtins'.

OK, we've all done it by accident (especially when starting out), but
are there people that rebind builtins intentionally?

-- 
Grant Edwards               grant.b.edwards        Yow! FROZEN ENTREES may
                                  at               be flung by members of
                              gmail.com            opposing SWANSON SECTS ...

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

#47613

On Tue, Jun 11, 2013 at 8:39 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-06-10, Terry Jan Reedy <tjreedy@udel.edu> wrote:
>
>> Another principle similar to 'Don't add extraneous code' is 'Don't
>> rebind builtins'.
>
> OK, we've all done it by accident (especially when starting out), but
> are there people that rebind builtins intentionally?

There are times when you don't care what you shadow, like using id for
a database ID.

ChrisA

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

#47618

On 2013-06-11 08:54, Chris Angelico wrote:
> >> Another principle similar to 'Don't add extraneous code' is
> >> 'Don't rebind builtins'.
> >
> > OK, we've all done it by accident (especially when starting out),
> > but are there people that rebind builtins intentionally?
> 
> There are times when you don't care what you shadow, like using id
> for a database ID.

While that's certainly the most common, there are a lot of items in
__builtins__ that are there for convenience that I wouldn't think
twice about rebinding, especially in a local scope (I might take more
care at a module scope, but still wouldn't care much).  E.g.

  apply
  bin
  buffer
  coerce
  filter
  format
  input

Some are deprecated, some are easily replaced by (what I consider
more readible) list comprehensions, and some have alternate meanings
that might be the right word-choice inside a function and wouldn't be
missed (I'd expect to see a bin-sort function use variables called
"bin" and not needing to convert from integer-to-string)

And some strings that are harmless outside the interactive interpreter

  copyright
  credits
  exit
  license
  quit

-tkc

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

#47619

On 06/10/2013 06:54 PM, Chris Angelico wrote:
> On Tue, Jun 11, 2013 at 8:39 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2013-06-10, Terry Jan Reedy <tjreedy@udel.edu> wrote:
>>
>>> Another principle similar to 'Don't add extraneous code' is 'Don't
>>> rebind builtins'.
>>
>> OK, we've all done it by accident (especially when starting out), but
>> are there people that rebind builtins intentionally?
>
> There are times when you don't care what you shadow, like using id for
> a database ID.
>
> ChrisA
>

And times where you're deliberately replacing a built-in

try:
    input = raw_input
except ....



-- 
DaveA

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

#47636

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 10, 2013 at 7:26 PM, Dave Angel <davea@davea.name> wrote:

> On 06/10/2013 06:54 PM, Chris Angelico wrote:
>
>> On Tue, Jun 11, 2013 at 8:39 AM, Grant Edwards <invalid@invalid.invalid>
>> wrote:
>>
>>> On 2013-06-10, Terry Jan Reedy <tjreedy@udel.edu> wrote:
>>>
>>>  Another principle similar to 'Don't add extraneous code' is 'Don't
>>>> rebind builtins'.
>>>>
>>>
>>> OK, we've all done it by accident (especially when starting out), but
>>> are there people that rebind builtins intentionally?
>>>
>>
>> There are times when you don't care what you shadow, like using id for
>> a database ID.
>>
>> ChrisA
>>
>>
> And times where you're deliberately replacing a built-in
>
> try:
>    input = raw_input
> except ....


Yes but this is a hack to coerce Python2/3 compatibility.  You're no doubt
correct that it's intentional rebinding with a definite aim, but if the
PyArchitects had their way, this would be unnecessary (and discouraged) as
well.

The first time I remember rebinding a builtin was completely accidental
(and at the very beginning of me learning and using Python).

# beginner's crappy code
range = [0, 20]

# bunches of code

for i in range(len(data)):
   if data[i] > range[0] and data[i] < range[1]:
      do_something

TypeError: 'list' object is not callable... # what the heck does this mean??


That one drove me nuts. Took me hours to find.  I still avoid rebinding
builtins just from the memory of the experience :)

--Jason

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

#47596

On 6/10/2013 9:18 AM, Rui Maciel wrote:

> class Model:
>          points = []
>          lines = []

Unless you actually need keep the points and lines ordered by entry 
order, or expect to keep sorting them by whatever, sets may be better 
than lists. Testing that a point or line is in the model will be faster, 
as will deleting one by its identify.

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

#47599

Terry Jan Reedy wrote:

> On 6/10/2013 9:18 AM, Rui Maciel wrote:
> 
>> class Model:
>>          points = []
>>          lines = []
> 
> Unless you actually need keep the points and lines ordered by entry
> order, or expect to keep sorting them by whatever, sets may be better
> than lists. Testing that a point or line is in the model will be faster,
> as will deleting one by its identify.

Thanks for the tip, Terry.  Sounds great.  I'll update my code.


Once again, thanks for the help,
Rui Maciel

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

#47712

On Monday, June 10, 2013 8:18:52 AM UTC-5, Rui Maciel wrote:
> [...]
>
> <code> 
> class Point:
>         position = []
>         def __init__(self, x, y, z = 0):
>                 self.position = [x, y, z]

Firstly. Why would you define a Point object that holds it's x,y,z values in a list attribute? Why not store them as self.x, self.y and self.z? But if you are going to store them as a list, then why not extend a python list? I hate to see a "listy" object that only holds a list. It begs the question: Why not make it a *real* list? (Although i believe the former approach is more desirable for this problem)

Secondly, why would store the position of the Point as a class attribute? Do you realize that EVERY instance of the Point object will share the same x,y, and z values if you do it that way? (considering you query the correct variable *evil grin*)

Actually, you have a legitimate excuse: you were fooled because in your "object definition" you declared a "class level variable" named "position". THEN in your "__init__" method you declared an "instance level variable" named "position". 

Then, when you assigned the x,y,z values to "self.position" you thought you where assigning them to the "class level variable" named "position", HaHa, but then again you had NO idea that "class level variables" and "instance level variables" even existed! (or, at least, how to properly declare them)

Q: Yes Rick but how do i solve this issue?

By changing the names we can inspect the Point object and understand how class level and instance level variables work in Python. Observe:

## START SESSION ##
py> class Foo(object):
...     classVar = []
...     def __init__(self, arg):
...         self.instanceVar = arg
... 
py> Foo.classVar
[]
py> Foo.classVar = "apple"
py> Foo.classVar
apple
py> foo1 = Foo("pear")
py> foo1.classVar
apple
py> foo1.instanceVar
pear
py> foo2 = Foo("peach")
py> foo2.classVar
apple
py> foo2.instanceVar
peach
## END SESSION ##

As you can see the "class level variable" is known to all instances of the object, and a change in one is equal to a change in all. Whereas the "instance level variables" are unique to each instance.

> class Line:
>         points = ()
>         def __init__(self, p_i, p_f):
>                 self.points = (p_i, p_f)

Same problem here with the class level/instance level thing.

> It would be nice if, whenever a Point object was updated,
> the Line objects which are associated with it could
> reflect those updates directly in Line.p_i and Line.p_f.
> What's the Python way of achieving the same effect? Thanks
> in advance, Rui Maciel
> 

If you construct your code properly this can be achieved. If each point is an object, and lines are merely holding references to two point objects that define the start and end position of an imaginary "line", then updates on the points will be reflected in the Line object. 

Observe:

## START SESSION ##
py> class Point3d(object):
...     def __init__(self, x, y, z):
...         self.x = x
...         self.y = y
...         self.z = z
...     def __str__(self):
...         _ = 'Point3d({}, {}, {})'
...         return _.format(self.x, self.y, self.z)
...         
py> p1 = Point3d(1,2,3)
py> str(p1)
Point3d(1, 2, 3)
py> p2 = Point3d(3,4,5)
py> str(p2)
Point3d(3, 4, 5)
py> class Line3d(object):
...     def __init__(self, p1, p2):
...         self.p1 = p1
...         self.p2 = p2
...     def __str__(self):
...         _ = 'Line3d({}, {})'
...         return _.format(self.p1, self.p2)
...         
py> line1 = Line3d(p1, p2)
py> str(line1)
Line3d(Point3d(1, 2, 3), Point3d(3, 4, 5))
py> p1.x = 100
py> str(p1)
Point3d(100, 2, 3)
py> str(line1)
Line3d(Point3d(100, 2, 3), Point3d(3, 4, 5))
## END SESSION ##

Easy peasy.

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

#47944

Rick Johnson wrote:

> On Monday, June 10, 2013 8:18:52 AM UTC-5, Rui Maciel wrote:
>> [...]
>>
>> <code>
>> class Point:
>>         position = []
>>         def __init__(self, x, y, z = 0):
>>                 self.position = [x, y, z]
> 
> Firstly. Why would you define a Point object that holds it's x,y,z values
> in a list attribute? Why not store them as self.x, self.y and self.z? 
<snip/>

The position in space is represented as a vector, which is then used in a 
series of operations.  

Currently I'm using numpy arrays to represent vectors.


> Secondly, why would store the position of the Point as a class attribute?
<snip/>

I've answered this 3 days ago.  I'm still learning Python, and python.org's 
tutorial on classes didn't explicitly covered the differences between class 
and instance attributes.


> If you construct your code properly this can be achieved. If each point is
> an object, and lines are merely holding references to two point objects
> that define the start and end position of an imaginary "line", then
> updates on the points will be reflected in the Line object.

This was already covered three days ago in another post in this thread.  
I'll quote the post below

<quote>
I've tested the following:

<code>
model = Model()
model.points.append(Point(1,2))
model.points.append(Point(1,4))

line = Line( model.points[0], model.points[1])

# Case A: this works
model.points[0].position = [2,3,4]
line.points

# Case B: this doesn't work
test.model.points[0] = test.Point(5,4,7)
line.points
</code>


Is there a Python way of getting the same effect with Case B?
</quote>

Rui Maciel

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

#47966

On Thu, Jun 13, 2013 at 10:06 PM, Rui Maciel <rui.maciel@gmail.com> wrote:
> Rick Johnson wrote:
>> Firstly. Why would you define a Point object that holds it's x,y,z values
>> in a list attribute? Why not store them as self.x, self.y and self.z?
> <snip/>
>
> The position in space is represented as a vector, which is then used in a
> series of operations.
>
> Currently I'm using numpy arrays to represent vectors.
>
>
>> Secondly, why would store the position of the Point as a class attribute?
> <snip/>
>
> I've answered this 3 days ago.  I'm still learning Python, and python.org's
> tutorial on classes didn't explicitly covered the differences between class
> and instance attributes.

Just FYI, Rick Johnson (aka Ranting Rick) is a known troll. Don't let
him goad you :)

Follow other people's advice, and take Rick's posts with a grain of
salt. Sometimes he has a good point to make (more often when he's
talking about tkinter, which is his area of expertise), but frequently
he spouts rubbish.

ChrisA

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

#48003

Chris Angelico wrote:

> Just FYI, Rick Johnson (aka Ranting Rick) is a known troll. Don't let
> him goad you :)
> 
> Follow other people's advice, and take Rick's posts with a grain of
> salt. Sometimes he has a good point to make (more often when he's
> talking about tkinter, which is his area of expertise), but frequently
> he spouts rubbish.

I had no idea.  


Thanks for the headsup.
Rui Maciel

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web