Define default pop_rel

[dimitri-yatsenko]

In 90% of cases, the pop_rel is the unrestricted join of the primary dependencies of the table. Should we set that as the default value and let users override that?

[eywalker]

I guess it's fine for the pop_rel to default to that. I'll implement it.

On Fri, May 8, 2015 at 9:11 PM, Dimitri Yatsenko notifications@github.com
wrote:

In 90% of cases, the pop_rel is the join of the primary dependencies of
the table. Should we set that as the default value and let users override
that?

—
Reply to this email directly or view it on GitHub
#59.

[dimitri-yatsenko]

since we are all over PEP8 now, is pop_rel the right name? What about populate_relation?

[fabiansinz]

I think we should name it populate_relation, but have a function pop_rel that wraps it for the time being.

[eywalker]

I think populate_relation makes sense and looks cleaner. I'm not too eager on having pop_rel unless we intend to support both names for the foreseeable future - once a name is introduced, it's hard for us to get rid of it without breaking someone else's code.

[fabiansinz]

I generally agree, but it is just one line and makes it easier for people that switch from matlab to python. At some point we can throw a deprecation warning.

[eywalker]

Hmm.. I just don't like the idea of implementing a feature that is already
know to get deprecated... given already existing name differences between
matlab and python dj in classes and other methods, can we not just ask
python users to learn to use populate_relation right off the bat?
On May 9, 2015 12:33 PM, "Fabian Sinz" notifications@github.com wrote:

I generally agree, but it is just one line and makes it easier for people
that switch from matlab to python. At some point we can throw a deprecation
warning.

—
Reply to this email directly or view it on GitHub
#59 (comment)
.

[fabiansinz]

I think it depends on how close we want to keep both implementations. If they don't need to be too close, then I completely agree with you, because I definitely like the name populate_relation better.

Maybe you are right, we already created the batch_insert for example. Also makeTuples will probably become make_tuples to properly worship PEP8. So if do that anyway we can just call it populate_relation right away. I just wanted to make sure that this is a conscious design decision.

[FlorianFranzen]

Due to the changes induced by #37 AutoPopulate is not purely about populating tables anymore. I therefore think it would be even legit to rename AutoPopulate, populate(...) and makeTuples(...) completely, as long as we come up with more descriptive names.

One could keep a AutoPopulate class around (that maybe even inherits from Base) that acts as a pure alias class, to avoid confusion and code breaks.

[eywalker]

It is timely that AutoPopulate got mentioned here because it is a subject to change as described in the issue #60 . Let's think through the implementation of auto-populating mechanism carefully before deciding on how to call things.

In general though, because I still consider the Python DataJoint pre-launch and I don't feel a huge obligation (yet) to make Python DataJoint a mirror of Matlab DataJoint (as @fabiansinz and @FloFra noted, Python implementation is already starting to deviate from Matlab a bit), I would rather not place any just for now features into Python DataJoint. This includes any alias methods and properties that's there just to make it look or feel like Matlab. I think it would make sense for us to decide exactly how similar we want these two versions of DataJoint to be.

[fabiansinz]

I think we should implement it how we think it should be done. The compatibility to Matlab should be there on a database level, but apart from that I don't feel the obligation to make it a Matlab clone. This means I agree with @eywalker. I just want to make sure that we agree on that. @eywalker: Shall we discuss this issue on Monday and distribute implementation tasks?

[eywalker]

Sounds good to me ;)

[dimitri-yatsenko]

make_tuples is perhaps not the best name. Sometimes it only makes one tuple for example. How about just make or compute?

[dimitri-yatsenko]

It make_tuples should probably be protected. It's not meant to be called from outside the object.

[fabiansinz]

I think make_tuples is a good name if it produces data tuples (even if it is just one). I agree, that it should be protected when it shouldn't be called from users.