0

The question comes out when building a small set of class to a plotting package. Although the question holds independent of my particular case, I describe what I have in hands to put some context:

The scenario is a "datasource" class containing numpy vectors; the "datasource" class adds metadata around the (data) vectors. The data source object is the one to go inside my "plot" class/object; the "plot" object ask information (metadata and data) to "datasource", but if I want to modify a data point or a metadata value "plot" has nothing to do with it, "datasource" deals with all that is yours and then just communicate "plot" that he needs to refresh.

So, stating the question is clearer words: when I pass an object to a function or to another object (to hold it as its member), am I passing a pointer or a copy?

[]

Brandt
  • 5,058
  • 3
  • 28
  • 46
  • No, usually it passes a "reference". Generally, the object model is quite similar to Java one: there're "primitive types" (numbers), which are passed by value, and the rest are objects, which are passed by reference, with immutable strings. – user3159253 May 06 '16 at 15:20
  • 2
    Closer duplicate: http://stackoverflow.com/q/534375/2301450 – vaultah May 06 '16 at 15:20
  • 1
    @user3159253: What? In Python, _everything_ is an object, including integers. – PM 2Ring May 06 '16 at 15:38
  • You may find this article helpful: [Facts and myths about Python names and values](http://nedbatchelder.com/text/names.html), which was written by SO veteran Ned Batchelder. – PM 2Ring May 06 '16 at 15:38
  • To actually answer your question: everything in Python is a reference (which is implemented with pointers). Hardly anything you do will make a copy; for example `a=b` doesn't make a copy of `b`. One notable exception is slicing: `a=b[:]` *will* make a copy. – Mark Ransom May 06 '16 at 16:15
  • @PM2Ring one one hand, each and every entity in python can be introspected with `dir()` and so on, so, yes, they are objects in that sense. On another, those "primitive types" are immutable, so any "modifying" operation like `+=` actually reassigns a corresponding object. That is why in `x=1; y=x; x+=1` only `x` changes and `x` receives a new object `id` during the operation. Just like in Java, for its autoboxing types, btw. So for practical purposes it's better to treat them specifically, not like other objects for which "real refs" are used, and one could change an object passed to a func. – user3159253 May 06 '16 at 22:00
  • @user3159253: But what you're saying re `+=` is due to immutability, not because integers are primitive. Thus `+=` on a list will mutate the list, but `+=` on a tuple _must_ create a new tuple object because tuples are immutable. Saying that integers are primitive types to me implies that they are stored & passed as machine integers (rather than being implemented as fully-fledged objects), and _that_ was what I was objecting to in my earlier comment. – PM 2Ring May 07 '16 at 11:31

0 Answers0