-
-
Notifications
You must be signed in to change notification settings - Fork 167
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
Complete removal of SplitResult
as an internal
#1396
Conversation
SplitResult
as an internal
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1396 +/- ##
=======================================
Coverage 96.00% 96.01%
=======================================
Files 31 31
Lines 5683 5692 +9
Branches 353 353
=======================================
+ Hits 5456 5465 +9
Misses 201 201
Partials 26 26
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
CodSpeed Performance ReportMerging #1396 will improve performances by ×2.2Comparing Summary
Benchmarks breakdown
|
For the future we could store everything in That would get rid of the tuple.. but thats a major change, and since SplitResult is It would be a lot nicer though since it means the encode_url and unencoded_url calls |
#1397 Aims to fully eliminate Val and only construct it lazily |
partially implements #172
It was suggested in #172 to only upgrade to
SplitResult
when needed. This will give us more flexibility to change how the internal structure works in the future and we won't be forever bound to usingSplitResult
.The only place we can't fully get rid of it is for pickle without a breaking change. #172 suggested leaving it for compat, so thats what I did.
In the future we may want to change the split functions to unpack the values into named variables in future. ie
self._scheme, self._netloc, self._path, self._query, self._fragment = val
or store everything inself._cache
as the single source of truth; However that was too large of a redesign for this PR since it would also require changing all the tuple unpacking and pre cache in__new__
.One consideration about getting rid of the
_val
tuple is thatSplitResult
is exposed as an allowed incoming value in new we would have to have code to convert it. With_val
being a normal tuple,SplitResult
can be passed in and its still compatible.It would be a lot nicer if we stored everything in
self._cache
though since it means theencode_url
andpre_encoded_url
calls would return a simple dict that was pre-populated, and it also meanspropcache
would have more keys pre-populated.