added methods Table.with_relabeling and Table.with_column

[ericz82]

#118

[SamLau95]

Cool! Couple things:

• Let's add documentation and tests for these methods
• Let's make these methods also be able to take in a sequence as well as an individual value. (Eg. with_relabeling(['A', 'B', 'C'], ['a', 'b', 'c']) should relabel all the columns specified.)

[ericz82]

How do I add tests?

[mDibyo]

you can add tests at tests/test_tables.py

[stefanv]

This docstring is rather vague.

[stefanv]

Also, what does it add above append_column? If this is just to make a copy, we should rather implement table.copy().

[ericz82]

Should I change Table.relabel to also take in a sequence of arguments?

[stefanv]

@ericz82 I think it already does (according to the example you gave). It should simply be documented that way.

[ericz82]

@stefanv Hmm, I'm not sure what example you are referring to. I wrote a test for Table.relabel taking in a list for column_label and a list for new_label which does not seem to be passing. I believe Table.relabel should be changed accordingly.

[stefanv]

Ah! But there you go. You should just rework relabel to have the functionality you want, instead of adding a whole new method.

[ericz82]

Yeah, that's what I decided on doing. Everything should be good now.

[SamLau95]

These belong in the Transformation section because they return a new table instead of mutating the original!

[ericz82]

@SamLau95 Should I also change the locations of these methods in tables.py?

[SamLau95]

Good catch! Please do that.

[stefanv]

So, API question: is the new method added here then equivalent to:

t1= t0.copy()
t1.relabel(['a','b','c'], ['A','B','C'])

? If so, is it worth expanding the API? (I have no idea how common such an operation is.)

[SamLau95]

Let's call this dictionary old_to_new instead of d since it'll help someone who's reading this for the first time. Also, dictionaries iterate over their keys by default so you can more succinctly write for col in old_to_new:.

nit: You misspelled dictioanry!

[SamLau95]

@stefanv I think it is worth expanding the API in this case because method chaining is much easier with these two methods. For example, this is now possible:

table.select(['x', 'y'])\
    .with_column('z', 0)\
    .with_relabeling(['x', 'y', 'z'], ['a', 'b', 'c'])\
    .group(...) # etc.

In addition, I believe we're going to deprecate the mutation methods (or at least not teach them) in favor of these new ones because of the issues we face with students running cells multiple times. See #114

[stefanv]

@SamLau95 Thanks, that makes sense. I think there are a couple of sneaky places in which data mutation can still accidentally happen. If this is a decided policy (never to mutate), then we can start hunting for those.

[SamLau95]

@stefanv I'm not sure if it's a decided policy but it definitely helps a lot with reasoning about tables, especially for students that are just starting to learn programming. Originally we were fine with mutation but I think the de facto policy now is just to replace mutation with a pure function alternative as much as we can.

[SamLau95]

Thanks for the hard work on this @ericz82 !