-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clib.Session.virtualfile_from_vectors: Now takes a sequence of vectors as its single argument (Passing multiple arguments will be unsupported in v0.16.0) #3522
Conversation
a73a4bc
to
f5b0e8e
Compare
# "_data" is the data that will be passed to the _virtualfile_from function. | ||
# "_data" defaults to "data" but should be adjusted for some cases. | ||
_data = data | ||
match kind: | ||
case "arg" | "file" | "geojson" | "grid" | "image" | "stringio": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just put _data = data
in the case _
below? I'd actually prefer if we make it more explicit like:
case "arg" | "file" | "geojson" | "grid" | "stringio":
_data = data
So that if there's a new kind
in the future, we know to add it explicitly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd actually prefer if we make it more explicit like:
case "arg" | "file" | "geojson" | "grid" | "stringio": _data = data
So that if there's a new
kind
in the future, we know to add it explicitly.
We can't do it like this, because we're currently writing case statements like case "image" if data.dtype != "uint8":
, which only catches the case when kind="image"
and data.dtype != "uint8"
.
We can refactor the codes to:
case "arg" | "file" | "geojson" | "grid" | "stringio":
_data = data
case "image":
_data = data
if data.dtype != "uint8":
# do something
case "matrix":
_data = data
if data.dtype.kind not in "iuf":
# do something
or
case "arg" | "file" | "geojson" | "grid" | "stringio":
_data = data
case "image" if data.dtype != "uint8":
raise ...
case "matrix" if data.dtype.kind not in "iuf":
...
case _:
_data = data # this is necessary to catch cases like kind="matrix" and dtype in "iuf"
I still prefer the current codes, which set _data
to data
by default and the match-case statements only need to deal with exceptions.
So that if there's a new
kind
in the future, we know to add it explicitly.
If there is a new kind
in the future, _data=data
is still the default. If needs special handling and we forget to add it, then the related tests will fail anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok, that makes sense, let's keep _data = data
at the top then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting very close to (finally) implementing #1076!
I've changed the label from 'maintenance' to 'deprecation'. Should we mention this is scheduled for removal in PyGMT v0.16.0?
In the
Session.virtualfile_in
method, we must prepare for_data
that will be passed to differentvirtualfile_from_*
methods. Currently,_data
must be an iterable (e.g.,_data = (data, )
even for the simplest case) and when pass it to_virtualfile_from
, we need to unpack it like:The complexity is because, while most
_virtualfile_from_*
methods only take a single argument, the_virtualfile_from_vectors
takes multiple arguments. The_virtualfile_from_vectors
is defined like_virtualfile_from_vectors(*vectors)
and must be called like_virtualfile_from_vectors(x, y, z)
.This PR changes its definition to
_virtualfile_from_vectors(vectors)
, and now it should be called like_virtualfile_from_vectors((x, y, z))
.With this breaking change, thevirtualfile_in
function can be simplified slightly, which I think is more readable. Then the question is, is it worth a breaking change?Edit: Actually it's possible to introduce the new syntax without breaking backward compatibility. This is done in f5b0e8e.