Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Row ordering design choice

Abierto
#356 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
python
Área
data

Línea de trabajo

El issue no menciona archivos, pruebas ni puntos de entrada. Comienza revisando el artículo de dataframe de 2020 citado y el estándar de la API de dataframe existente; después, compara las alternativas de ordenación de filas que se analizan. Se considera terminado cuando el proyecto tiene una política de ordenación de filas acordada y el estándar la documenta.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
106
Forks
22
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de data-apis/dataframe-api

Todos los issues de data-apis/dataframe-api

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.