Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Calling methods on invalid types

Aberta
#13 3 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
pandas, python
Domínio
api, data

Direção de pesquisa

Comece lendo a discussão vinculada, a issue #11 e a issue #6; em seguida, compare os casos de redução de DataFrame e Series mostrados. A issue não indica arquivos de implementação nem testes; para considerá-la concluída, seria necessária uma política acordada para Dtypes inválidos e um comportamento consistente entre as operações.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

This is a follow up of the discussions in:

See this example:

>>> df[['name', 'population']].mean()
population    2.729748e+07
dtype: float64

Even if the name column is selected, it is being ignored, since the mean of a string columns does not make sense. As opposed to raising an exception.

Many reductions implement a parameter to let control this behavior:

df[['name', 'population']].mean(numeric_only=False)
TypeError: could not convert string to float:

If we consider more methods to be applied directly over a dataframe, for example:

>>> df[['first_'name', 'last_name']].str.lower() 

We may end up with a huge amount of string_only, bool_only, numeric_only parameters. All meaning something similar, but IMO adding a decent amount of complexity, and being difficult to keep the behavior consistent.

My preference would be to always raise, but being a software engineer I'm biased, and I guess many users may want this "magic".

So, I guess implementing an option, for example: pandas.options.mode.invalid_dtype {raise or skip} could make more sense.

The main problem with this approach is probably that it's not as easy to define the behavior for each operation:

(df.mean(numeric_only=True)
   .mean(numeric_only=False))

Personally, I don't see this as an issue. IMO, the behavior depends more on the user than on the operation. I'd say for production code, having to be explicit, and selecting the columns to operate with, makes more sense. While in a notebook, avoiding exceptions with this sort of "magic" seems to be more useful.

I guess for Series/1-column DataFrame (see #6) it always makes sense to raise an exception.

Thoughts?

Linguagem predominante
Python
Estrelas
106
Forks
22
Métricas de merge de PRs
Nenhum PR com merge em 30d

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de data-apis/dataframe-api

Todas as issues de data-apis/dataframe-api

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.