-
Notifications
You must be signed in to change notification settings - Fork 2
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
Obligatory "Josh just wrote the docs and now has to complain about everything" issue #27
Comments
My best guess is that it's possible-but-difficult with PEP 646, but that's 3.11+ / I haven't looked for a backport. |
Oh, and for the record, I see four great suggestions and no complaints! |
After #34 I think 1-3 are now incorporated and 4 probably won't happen for a while. Would you be willing to copy+paste that into a new issue and close this one? |
@mattwthompson Too easy :) Superseded by #35 |
I'm putting this in an issue so that it doesn't get forgotten (by me if no-one else) when the docs PR is merged, and I'm putting it all in one issue to avoid spam. Here are my thoughts:
to_openmm
would make a great method forQuantity
. This would save users an import when going in that direction. For bonus points, we could define it as a method onUnit
as well and make the free function polymorphic over bothopenff.units.unit
while the three big classes are underopenff.units.units
is confusing.If API breaks are OK,maybe we couldrenamere-exportopenff.units.units
toopenff.units._pint
andQuantity
,Unit
, andMeasurement
fromopenff.units
(either lazily or not) (Fixed in Add documentation #28)Quantity[Array]
in type hints, does anyone know if that's possible? I know they're both part of the value and not the type but the two concepts are kinda fungible in Python. I vaguely remember that people somewhere somewhen were working on it.The text was updated successfully, but these errors were encountered: