You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In general pythonic terms, this is fine. However, since many of the fields are initialized to None, and have no other typing, Pyright (and other static type checkers) warn that I'm not allowed to assign spec.sorting = segyio.TraceSortingFormat.CROSSLINE_SORTING because "Literal[1]" is incompatible with "None" (basically int is incompatible with "None").
In the case of spec, I believe a dataclass might be a good fit, but in general, I think the classes should be typed.
Another example is that where segyio.tools.cube calculates the shape of the cube grid, it depends on e.g. the line smps = len(f.samples). Looking at the typing provided (implicitly) by the package:
So f.samples is typed as None, because it's initialized as that. These properties (ilines, xlines, offsets, samples, sorting) that depend on private fields are all implicitly annotated to the initialization value of their private counterparts, which is None. By rather explicitly typing the property functions, these could be typed correctly, like so:
This change would improve the usability of the package for new users, as autocomplete (from correct typing) is one of the most intuitive types of docs a package can provide.
Thanks!
The text was updated successfully, but these errors were encountered:
I'm using segyio for the first time, and Pyright isn't loving all the implicit
None
-typing in the package.E.g. looking at the
spec
-class, it is a simple object class, initialized as so:In general pythonic terms, this is fine. However, since many of the fields are initialized to
None
, and have no other typing, Pyright (and other static type checkers) warn that I'm not allowed to assignspec.sorting = segyio.TraceSortingFormat.CROSSLINE_SORTING
because"Literal[1]" is incompatible with "None"
(basicallyint is incompatible with "None"
).In the case of spec, I believe a dataclass might be a good fit, but in general, I think the classes should be typed.
Another example is that where
segyio.tools.cube
calculates the shape of the cube grid, it depends on e.g. the linesmps = len(f.samples)
. Looking at the typing provided (implicitly) by the package:So
f.samples
is typed asNone
, because it's initialized as that. These properties (ilines, xlines, offsets, samples, sorting
) that depend on private fields are all implicitly annotated to the initialization value of their private counterparts, which is None. By rather explicitly typing the property functions, these could be typed correctly, like so:This change would improve the usability of the package for new users, as autocomplete (from correct typing) is one of the most intuitive types of docs a package can provide.
Thanks!
The text was updated successfully, but these errors were encountered: