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

Slice Probe and ProbeGroup by stable identifiers, not positional integers

Abierto
  • ¿Algo no está bien?
#447 2 comentarios 1 reacción 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
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
backend-api-design, data

Línea de trabajo

Start by reviewing get_slice and the Probe and ProbeGroup APIs, then read the linked discussions and PRs #429 and #446. The work is complete when a stable-identifier-based public selection API and the ProbeGroup identifier behavior have been agreed and implemented for both object types.

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

Descripción

Currently get_slice's argument is array-based: selection is positional indices or a boolean mask. I think this is a bad pattern, and I'd like to either change it or add a method that doesn't rely on it, select_contacts, mirroring SpikeInterface's select_channels. I think this should be the blessed public API for sub-selecting contacts of both Probe and ProbeGroup.

Why? Our libraries merge results from different sources (the recording, the probe, and probably headstage information later), and a positional index keeps an implicit "position i here is position j there" map that collides when those sources are combined and goes stale the moment one of them is sliced or reordered. That is how users get bitten, see the reorder-on-attach case in SpikeInterface #4565. The standard solution in the field is to do what databases do: identify a record by a stable primary key rather than by its position. That is, we create object identifiers that are independent of the internal representation.

Using that in SpikeInterface, for example, would solve the metadata propagation bugs related to slicing, grouping and aggregating #4545, #4546, and #4547. It would also remove the need to solve the annotation feature on the array-like slicing, which does not have natural semantics #446.

Finally, I think it is semantically appropriate for the domain. Probes are not arrays, and we should not have a method that assumes they are.

Note that if you think this idea is good we would require #429 (auto-generate contact_ids when not explicitly set). The ProbeGroup unique identifier is an implementation detail that we can discuss if we think this idea is sound.

Lenguaje dominante
Python
Estrellas
86
Forks
49
Merge medio
9 h 43 min
PR fusionados (30 d)
2

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 SpikeInterface/probeinterface

Todos los issues de SpikeInterface/probeinterface

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.