Riccardo Cappuzzo

> My question would however be: should they be exposed in skrub's namespace, or in another namespace, such as "skrub.api"? I'm asking to avoid polluting the tab-completion on the main...

> I agree singlecolumntransformer and rejectcolumn are more advanced / less frequently used, however maybe we can find a grouping that is a bit more intuitive than 'api' otherwise I'm...

> regarding tab completion, WDYT of defining a `skrub.__dir__()` in which we list the most frequently-used names? At the moment, there are already too many for tab-completion to be very...

> Actually, I would love us to start more systematically using "import skrub as skb" in our example (seems like a "good first issue"). What do people think? It makes...

Looking at what tab completing skrub does, I noticed a couple of things - I just found out that `compute_ngram_distance` is a public function, I've never seen it before. -...

> My recommendation: > 1. Address the three first points > 2. Sleep on the last point, and discuss it more broadly About the first part: how should we address...

> > For some reason, Drop (not DropCols) is a public class, when it clearly shouldn't be. This should be fixed. > > they are both public, and both are...

> it is always possible to > > from skrub import data_ops as do > However I'm not sure this is better than the convenience of `skrub.X()`, `skrub.choose_from(...)` I quite...

From today's IRL meeting on skrub: - Anything Data Ops should be moved to a `skrub.data_ops` namespace, which should be imported as `import skrub.data_ops as do`. The migration should be...

> • Anything Data Ops should be moved to a skrub.data_ops namespace, which should be imported as import skrub.data_ops as do. > I would do "skrub.do" and not "skrub.data_ops", not...