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
^ This still doesn't feel quite right, but it's a starting point.
The end goal is to be able to create bn128_FQ2 with a reference to a single thing (like this new NamedTuple)
Of course, this approach comes at the downside of having to import the curve to create an FQ. Maybe a little more annoying at the REPL. But for the caller in a file, it means fewer magic strings and less likelihood for a typo with a confusing error. For the library, hopefully better readability.
This would happen in the second phase of the refactoring upgrading process where, even the curves would be generalized and all their properties would be encapsulated as a NamedTuple.
py_ecc/fields/__init__.py
has a lot of duplications and is at high risk of typos (like importing the coeffs or field modulus from the wrong curve).Let's think about alternatives to this setup. Maybe something like:
^ This still doesn't feel quite right, but it's a starting point.
The end goal is to be able to create
bn128_FQ2
with a reference to a single thing (like this newNamedTuple
)Of course, this approach comes at the downside of having to import the curve to create an
FQ
. Maybe a little more annoying at the REPL. But for the caller in a file, it means fewer magic strings and less likelihood for a typo with a confusing error. For the library, hopefully better readability.Originally posted by @carver in https://github.com/_render_node/MDI0OlB1bGxSZXF1ZXN0UmV2aWV3Q29tbWVudDI0OTIyNTg5NQ==/comments/review_comment
The text was updated successfully, but these errors were encountered: