Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Discussion: deprecate `read_imro`

未关闭
#351 5 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
冷清
技术栈
python
领域
backend

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.
主要语言
Python
星标
85
派生
49
平均合并
13 小时 47 分钟
30 天内合并 PR
3

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

SpikeInterface/probeinterface 的其他 Issue

查看 SpikeInterface/probeinterface 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。