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

Discussion: deprecate `read_imro`

Aperta
  • Qualcosa non va?
#351 5 commenti 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
35/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

Start in src/probeinterface/neuropixels_tools.py at read_imro and _read_imro_string, then inspect pull request #349 and callers to determine whether standalone IMRO reading is used. Done means the project has a settled decision on moving the inference logic and deprecating or retaining read_imro, with the resulting scope documented.

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

Descrizione

When discussing this pull request with @chrishalcrow, I’ve been thinking about the following:

Why do we expose read_imro directly?

The private function _read_imro_string is the one actually used by SpikeGLX and Open Ephys, while read_imro is just a wrapper around it that, for a reason that I can't remember, is exposed.

To make read_imro work, we need quite a bit of logic to infer the imDatPrb_pn (probe model number) from imDatPrb_type (probe type). This code is complex and since it was determined through trial and error when we did not have a general table, maybe not very reliable:

https://github.com/SpikeInterface/probeinterface/blob/27137e99bd31a65d058d34820803ca7be3b2bfa5/src/probeinterface/neuropixels_tools.py#L633-L651

This was necessary when our probe descriptions were based on the probe type. However, now that the official metadata table is organized around imDatPrb_pn (probe part number), this complexity is no longer needed. In other words, this logic doesn’t serve the key functionality anymore, which is reading neuropixel metadata.

Additionally, I’m not sure exposing the functionality to read IMRO tables on their own makes sense. These tables are embedded in the meta file, and trying to read them independently seems like a feature no one has asked for.

Proposed solution:

  1. Move the logic for inferring imDatPrb_pn from imDatPrb_type out of the core function (_read_imro_string) and into the wrapper (read_imro), keeping the complexity at the periphery.
  2. If there is no use for stand-alone reading of imro tables then deprecate read_imro and eventually remove it. This will allow us to eliminate code that is no longer needed now that we can rely on the metadata table.
Lingua principale
Python
Stelle
86
Fork
49
Merge medio
9h 43m
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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

Tutte le issue di SpikeInterface/probeinterface

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.