profile naming and interface

[roll]

Overview

There are two questions:

• profile is also in use for datapackage profiles
• profile interface could be updated

Naming

TBD

Interface

@pwalsh has wrote:

---

I'm not a fan of passing in data (errors and table in this case), modifying it, and then not returning that modified data. https://github.com/frictionlessdata/goodtables-py/blob/next-initial/goodtables/profiles/datapackage.py#L15

Based on the way profiles are used here, I don't see why the profile function needs errors and table passed in as arguments - they are always empty. Why not get rid of the empty list assignments and have

errors, tables = profile_handler(source, **options)  # sidenote: handler because more meaningful than func?

---

The reason why now profiles gets predefined errors and tables - API consistency with checks (but that's true we could removed errors and tables from profile signature):

profile(errors, tables, ...)
check(errors, columns, ...)

Also cc @amercader

[pwalsh]

why does check need to have the same API as profile?

[roll]

@pwalsh
It doesn't.

Here I just use principle like don't surprise your user. After writing first custom check user could expect that passing errors to a function is a standard pattern for this API. May be not perfect but consistent across the framework.

Not having a strong preference here esp after your words (that it's confusing). Just interested in how others look on this problem.

[roll]

About profile naming. There is a collision with datapackage profile but may be because it means the same in a good way (of collision). Like there is a dataset which could be:

• table
• ckan instance
• datapackage
• fiscal datapackage
• etc

And distinction between is a dataset profile. So datapackage profiles are subset of overall dataset profiles.

But if collision is still seems bad may use something safe like handler?

[pwalsh]

@roll let's hear from others. @amercader @vitorbaptista @akariv please jump in when you can.

For me:

I prefer handler or anything that is not profile.

For the other issue above, I don't like the arbitrary enforcement of the same API for profile and check. But I honestly don't care if it stays like that because you do prefer it :).

[amercader]

Sorry it's hard to follow this discussion if you don't know the context.

1. What is/does the profile object/function in the context of goodtables as opposed to the profiles in Data Packages? I agree that if not the same thing they should be named differently
2. Consistency is good but if it means having to always pass empty params is probably pushing it too far. As long as all functions on the API are well documented, I don't think we need to enforce a pattern

[roll]

@amercader
Both profile are pretty close as a dataset characteristic. But technically it's still different things. I'm also a big fan of not having different things with the same names. But this one was tricky)

So let's:

• rename profile to handler (we get input from user and handler handles it)
• remove empty arguments from handler signature

[roll]

I've started to update README using handler but there was a feeling that for end-user this word has to less sense. So I've tried to use word preset (in goodtables could be used different presets to process input data like datapackage preset) - https://github.com/frictionlessdata/goodtables-py/pull/137

[pwalsh]

@roll I saw and approved the PR