-
Notifications
You must be signed in to change notification settings - Fork 44
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
Revision of internal value types #751
Comments
Just a small addendum: Pair = Tuple[T, T]
Quadruple = Tuple[T, T, T, T]
Sextuple = Tuple[T, T, T, T, T, T]
CollectionType = Union[List[T], Tuple[T, ...]]
PairCollectionType = Union[List[T], Pair[T]]
QuadrupleCollectionType = Union[List[T], Quadruple[T]]
SextupleCollectionType = Union[List[T], Sextuple[T]] These would then be used in place of all the explicitly font-related type names (like Coordinate, Angle, Color, etc.). |
@knutnergaard will get you a reply by week's end, start of week has been really busy. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a two-part issue. First, I've spent som time today annotating the
normalizers.py
mdule, and come to the realisation that since there are so many internal types that differ in their input and output scopes, we should probably be more specific when annotating than what (at least) I thought initially necessary. This means that theannotations.py
module will have to be revised. Here's my suggested basic revision:Ideally I would like to do away with all sequential assignments or variable synonyms, but
TransformationInType
/TransformationOutType
are possibly too generic to be useful and clear when denoting both factor, scale and skew angle, even though the actual input and output types are the same for all. Technically, color and bounds values also share the same type inCollectionQuartetType
, but again, I hesitate to use this directly in the code, as it feels too generic.I need some feedback on this before I start revising the annotation in the committed modules.
The second part of this issue is which of these values to document in
objectref.valuetypes.index.rst
and reference in other parts of the documentation. The ability to references certain container types is really handy, especially considering the many elements needed to be spelled out without them (e.g.,':ref:`type-transformation`'
vs.':class:`tuple` or :class:`list` of six :class:`int` or :class:`float` values'
). However, as of now, this part of the documentation is incomplete, which in some cases results in dead links to non-existent references.Any thoughts?
The text was updated successfully, but these errors were encountered: