Altair objects, copy-on-modify semantics or mutable? about altair

[AliciaSchep]

I don't think it is true that reticulate necessarily offers Python objects as RC objects. Using pryr, when I look at

plot <- 
    alt$Chart(
        r_to_py(mtcars)
    )$mark_point(
    )$encode(
        x = "mpg:Q",
        y = "hp:Q",
        color = "cyl:N"
    )
pryr::otype(plot) 

it returns that the plot object is an S3 class. I think it is an S3 class that happens to store functions as its elements, meaning they can be accessed by '$', making them look like RC objects in a way.

That is why

plot[["interactive""]()

does the same thing as

plot$interactive()

(and neither without any assignment modifies the plot object)

It appears that Altair might also have copy-on-modify behavior:

import pandas as pd
data = pd.DataFrame({'a': list('CCCDDDEEE'),
                     'b': [2, 7, 4, 1, 2, 6, 8, 4, 7]})

import altair as alt

x = alt.Chart(data).mark_point()
x.encode(x = 'a')

The last command does not actually modify x, but rather returns a new object.
(However, some of the components of the object will only be shallowly copied rather than deep copied if say doing y=x)

[ijlyttle]

I am discovering the same thing - I forgot to update this issue, but I hope I have updated the articles. If there is anywhere else I am making this mistake, please let me know.

I need to learn a lot more about how Python objects work, so I feel a bit like a two-year-old trying to reason about and explain things that I don't quite understand or have the words for, so I am particularly grateful for these conversations (and your patience).

I think this was the part that I mis-read:

If a Python object of a custom class is returned then an R reference to that object is returned. You can call methods and access properties of the object just as if it was an instance of an R reference class.

As you describe, it returns an S3 object that acts a bit like a reference-class object.

I agree that the Altair (Python) methods use copy-on-modify semantics. I got bit, though, thinking that assignment returned a copy.

spec_only <- 
  alt$Chart(
  )$encode(
    x = "mpg:Q",
    y = "hp:Q",
    color = "cyl:N"
  )$mark_point()

plot <- spec_only

plot$data <- r_to_py(mtcars)

examine(spec_only)
# what!?!

This, however, works how I intend:

spec_only <- 
  alt$Chart(
  )$encode(
    x = "mpg:Q",
    y = "hp:Q",
    color = "cyl:N"
  )$mark_point()

plot <- spec_only$copy()

plot$data <- r_to_py(mtcars)

examine(spec_only)

At some point, it might be nice to have a field guide to Altair objects, as they appear in R (if only for my own benefit).

[AliciaSchep]

Yes I see now that the docs say "S3"! Sorry, had missed that. I think the reticulate documentation is not very clear about all this. One suggestion might be to edit "It exposes Python objects as R S3 objects that behave like Reference Class objects." a bit, as I think it is a little misleading... the objects behaves only in some ways like Reference Class. With reference class, I think if you called obj$function() it mutates the object which is not the case here. Although I suppose it is the case that with Python objects where methods mutate the object (a common pattern, I think, although not the one Altair appears to use) then the reticulate object likely would behave more similarly to a Reference class. Bringing up S3 & reference classes might be better left to a vignette that is a more detailed field guide to Altair objects as you propose, rather than the introductory vignette?

[ijlyttle]

I agree - the field guide deserves its own vignette - I was (and to some extent still am) trying to write down everything I think I know about this - often wherever the cursor happens to be at the time.

• vignette: field guide to Altair objects

[ijlyttle]

This is being addressed in #31

[ijlyttle]

included in #37