User Stories for Interface / Feature Design and Documentation
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
Rechercherichtung
Es werden keine Dateien, Tests oder Einstiegspunkte genannt. Beginne damit, die vorgeschlagenen Beispiele und die aktuellen DataFusion-Python-Funktionen zu prüfen, und strukturiere anschließend die Anwendungsfälle der Beitragenden und die Anforderungen an die Schnittstelle; abgeschlossen ist die Aufgabe, wenn eine geklärte, priorisierte Richtung für DataFrame-Operationen und Dokumentation vorliegt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
As discussed in the rust arrow chat, this is a place to chart a way forward by collecting examples of both what people do in other libraries and what they want to do but can't do easily with current tools. In addition to clarifying Python interface requirements, I hope it provides fodder for lower-level functions, encourages knowledgeable folks to explain how to do things (which can then get documented), and clarifies what is important to what types of people and why. There's a daunting amount of work, but the opportunity and potential are tremendous.
For contributors, I'd like to structure this roughly as follows:
- If it's your first post in this thread, a brief description of your background and the types of work you've done/do.
- Examples of operations on data you think are important. Broadly of the form "I can do X in library Y with code sample Z". If it's something that you like, consider saying why. If you don't like it, explain how it could be easier or clearer.
- Examples of things you frequently do but have had to implement yourself and think should be considered for core operations.
- OPTIONALLY: Thoughts you have on what's important to a good data frame API in a dynamic language.
OK, now it's my turn to start.
My background is in statistics, machine learning, and data science. Most of what I do is focused on modeling and analyzing data, though I've done a good bit of pipeline and data processing/cleaning too. As such, I place a premium on in-memory interactive work (notebooks, rmarkdown, etc.). Partly because of this, I think a lot of tools mistake verboseness for clarity, and striving for conciseness often helps readability rather than hurting it if done correctly.
I have the most experience with R's data.table but I've also used dplyr, polars, pandas, and Julia. So here's sampling of a few things I would want in a dataframe library in no particular order.
- Here's an example in
data.tablethat shows features I think are both good and bad.
> dt1 = data.table(t = 1:5, v = 5:1)
> dt2 = data.table(start = c(1, 4), end = c(3, 10), x = c("a", "b"))
> dt1[dt2, x := i.x, on = .(t >= start, t < end)]
> dt1
t v x
1: 1 5 a
2: 2 4 a
3: 3 3 <NA>
4: 4 2 b
5: 5 1 b
First, I find non-equi joins, especially range joins incredibly useful. They're common in SQL but a lot of dataframe libraries don't have them. data.table also makes it easy to update in place with the := operator, which can be used to create new columns as well as update existing ones. As I understand it, arrow strives for immutability, but at the same time, it won't make copies of the whole frame if it doesn't have to, so maybe this is less of an issue. However, I do like the idea of using a join like this to explicitly tag/annotate another table.
-
Reshaping data. These functions transform data between "wide" to "long" (sometimes known as "tidy") formats. Sometimes they go by
cast/meltorpivotand there's even a simpletransposefunction in a lot of packages. It doesn't seem common in database-world, but to me reshaping in-memory data is important for a lot of use cases. -
Rolling groupbys. Both Pandas and Polars have pretty good support for creating overlapping groups and aggregating over them. These are commonly used for time series analysis. I also think the ability to define groups not just by a number of rows, but by a potentially variable-width lookback (like, at most 1 month before the current date) is useful. Polars does a pretty good job at this, and I think Pandas might too.
Alright, that's a few to get started and this is long enough as it is. I'm looking forward to seeing what everyone thinks is important, their thoughts on good DataFrame API design, and what is and isn't currently possible in DataFusion.
- Vorherrschende Sprache
- Python
- Sterne
- 605
- Forks
- 176
- Ø Merge
- 1 T. 23 Std.
- Gemergte PRs (30 T.)
- 8
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus apache/datafusion-python
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
apache/datafusion-python#1757 ·
-
documentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
apache/datafusion-python#1726 ·
-
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 88/100
apache/datafusion-python#1691 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
apache/datafusion-python#1644 ·
-
enhancement
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100
apache/datafusion-python#1737 ·
Alle Issues in apache/datafusion-python
Ähnliche Issues
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
canonical/paas-charm#368 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
tech debt
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
StevenBlack/hosts#3256 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
qualcomm/qai-appbuilder#275 ·