Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Row ordering design choice

Aperta
#356 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
python
Ambito
data

Direzione di ricerca

La issue non indica file, test o punti di ingresso. Inizia esaminando l’articolo del 2020 citato su dataframe e lo standard esistente dell’API dataframe, quindi confronta le alternative per l’ordinamento delle righe discusse. Il lavoro è completato quando il progetto dispone di una policy concordata per l’ordinamento delle righe e lo standard la registra.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

API design

Why do I even think it is necessary to maintain order?

This matches the definition of dataframes from the article. If we take the approach of defining based on articles about dataframes and their algebra, then we can also look for new articles and do a more in-depth comparative analysis (since the article I cited is from 2020).

Are there any use cases where this is important?

I think it’s obvious that there are workloads for which the order of the data is important. For example, values were recorded in some area over time, without recording timestamps, to reduce the size of the dataset. Any use of operations that violate the order invalidates the trends that can be obtained from these data.

Why not come up with a new concept that has characteristics of both dataframes and relational tables?

For ease of DataFrame API adaptation, it seems that all that is needed is to more or less successfully combine current concepts that will conveniently coexist in one interface (at least for first stable release). With this approach, libraries belonging to one of these groups may need to implement the characteristics of another group. In the case of a new concept, the number of other characteristics groups may increase to two.

Solution.

Based on the fact that these two concepts have existed for a long time and have not been completely united during this time, and that at the moment there are many hybrids that implement the interface of the opposite group using their own basis of operations, I believe that the solution should not be ideal, but just quite flexible.

So let's allow the order to be preserved or not, based on the user's choices, be it additional function parameters, environment variables, or context managers.

This way there will be enough flexibility in relation to libraries that implement the relational approach (they will also be performant, since there will be no need to maintain order using an additional index column or other tricks) and at the same time, a greater number of user cases will be covered by the standard.

Lingua principale
Python
Stelle
106
Fork
22
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di data-apis/dataframe-api

Tutte le issue di data-apis/dataframe-api

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.