Skip to content

reconsider track_offsets[0], track_lengths[0] etc. #24

@JonnyJD

Description

@JonnyJD

The decision to use track_offsets[1] to get the offset for the first track was based on discid_get_track_offset(disc, 1).

This is kind of an 1:1 translation to the libdiscid API, but when using an array tracks we have this:
tracks[0] corresponds to track_offset[1].

Well, the problem is there anyways, since tracks[0] does have the track number 1.
The question rather is:

What is the least suprise?

for track_number in range(1, len(tracks)-1):
    print(track_offset[track_number])

or

for track_number in range(1, len(tracks)-1):
    print(track_offset[track_number-1])

Should the track_offsets be accessed by track_number or by "track_index"?

The decision in the libdiscid API and in this module currently was, that you should index by track_number and having track_*[0] to be something different a way to achieve this.

A related issue is #23 (Track objects?). That doesn't solve the index problem though.

Metadata

Metadata

Assignees

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions