`precompute_size_scattering` should always return a tuple (`detail=False`)
See original GitHub issueCame up in conversation with @MuawizChaudhary
The detail
kwarg in precompute_size_scattering
isn’t really justified:
- it is
True
by default - it creates type instability (
int
ortuple
) - getting the
False
version is trivial: it suffices to callsum
on the output - our object-oriented method
self.output_size
, hasdetail=False
by default. I suggest removing that kwarg and simply summing across orders after callingprecompute_size_scattering
Hence i propose to remove it. The only occasion where we need self.output_size()
in the codebase is in the Keras frontend.
Perhaps we can set up a helpful error message if people ever call the non-default: self.output_size(detail=True)
, telling them to call self.meta()
instead?
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:12
Top Results From Across the Web
Python Return Multiple Values – How to Return a Tuple, List ...
In this article, we'll explore how to return multiple values from these data structures: tuples, lists, and dictionaries.
Read more >Python force tuple return type to required one use one line
To get it to use a return type of Tuple[str, str] , which you marked the method as, you need to explicitly return...
Read more >Python Tuples Tutorial - DataCamp
Learn about Python tuples: what they are, how to create them, when to use them, what operations you perform on them and various...
Read more >Tuple Objects — Python 3.11.1 documentation
Return the size of the tuple p, which must be non- NULL and point to a tuple; no error checking is ... The...
Read more >Python Tuples
The "tuple" is a Python type which is like a small list. ... All paths should return a tuple of that same length,...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yes, that’s what we just said … but that would remove useful functionality, namely the
out_size(detail=True)
non-default. So i’m no longer in favor of it (at first, i believed thatout_size()
was currentlydetail
-ed by default, but the opposite is true)Looking back at it, i don’t think there’s much to be done here, except maybe removing the confusing
detail
keyword argument fromprecompute_size_scattering
, and doing the summation insideout_size
. This will be fully backwards compatible and will reduce the number of conditional branches in unit tests.Then, i suggest we go with the breaking change, release v0.3, and if anyone complains about
output_size() got an unexpected keyword argument 'detail'
, i’ll write a helpful error message for v0.3.1. Deal?I disagree. If it’s a variable in the state of the program, then potentially people can modify/delete it, which will lead to antipatterns and strange hacks. Whereas making it the return value of a method (
self.output_size()
) prevents that problem. I see this method as a “getter” on a private field.