Ugly shadowing of Client.DEFAULT_ENCODING_PARAMETERS #1847
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#1847
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Client
in source:git/src/allmydata/client.py has a class attribute calledDEFAULT_ENCODING_PARAMETERS
, and an instance attribute also calledDEFAULT_ENCODING_PARAMETERS
that shadows it. This is ugly and confusing.The linked pull request changes the name of the latter to
_encoding_parameters
.(https://github.com/tahoe-lafs/tahoe-lafs/pull/18)
Hmm, given the amount of test code that sets encoding parameters, it may be worth adding a
set_encoding_parameters
method toClient
. So please hold off merging this.Could this be related to #1830?
Replying to zooko:
No, see /tahoe-lafs/trac-2024-07-25/issues/6862#comment:-1.
#1830 is still bothering me (see comment:89856), and fixing this ticket would help because then I wouldn't be distracted by the nagging feeling that this ugly shadowing is somehow interacting with #1830. That is: fixing this ugly shadowing would help me think about #1830, even if the ugly shadowing is not actually causing #1830. ☺ (Or even if, as comment:89856 suggests, #1830 is actually already fixed!)
Replying to zooko:
+1.
comment:12:/tahoe-lafs/trac-2024-07-25/issues/5611 is an example of how this default/shadowing/fall-back code gets in the way of work.
Hi I have made the changes, please review the changes.
review-needed:
https://github.com/tahoe-lafs/tahoe-lafs/pull/65
All test cases are green.
[github comment here]copying
There's a
cscope.out
file that is added and then deleted. Please squash the last two commits so that this file doesn't appear and the commits are easier to review.Also, the fix for this ticket should be independent of #549.
I have made the changes. Please review the code
https://github.com/basu123/tahoe-lafs/commit/8c1219f1ed582db1f00532bbf48715de08b1a8b9
This still has the
cscope.out
file. Also, when the indentation of the first line of a dict literal changes, please change the remaining lines to match.Hi Daira,
I have made the changes.
https://github.com/basu123/tahoe-lafs/commit/51dcecd01a730f588ce439a013d19c67f8f131b9
Reviewing.
Replying to daira:
daira is there any changes I need to do?
reviewed code in last commit. seems fine to my (very fresh[!]) eyes...
I just reviewed this, too, comparing https://github.com/basu123/tahoe-lafs/commit/51dcecd01a730f588ce439a013d19c67f8f131b9#commitcomment-4763253 to https://github.com/daira/tahoe-lafs/commit/ab9216e5728083a671060ba12c98f56638f08517 . I had one question about a way that these two patches differ:
https://github.com/basu123/tahoe-lafs/commit/51dcecd01a730f588ce439a013d19c67f8f131b9#commitcomment-4763253
Also, wiki/CodingStandards says "Prepend a leading underscore to private names.", so the way https://github.com/daira/tahoe-lafs/commit/ab9216e5728083a671060ba12c98f56638f08517 did that is preferred.
Otherwise, I don't see any problem with either of these two patches and either one can be merged to trunk in my opinion.
removing the
review-needed
flagadding the "reviewed" flag to let it be known that either of these two branches could be merged to trunk.
Replying to zooko:
I disagree, because these attributes aren't private. (I count attributes as non-private if they are accessed directly from anywhere outside the class, including tests.) The patch looks fine to me in this respect; I had originally planned to add a method to set parameters, but I think it's not needed.
In /tahoe-lafs/trac-2024-07-25/commit/4889129f3732219cb9cedb1eb27dec3da3f22db2:
Fixed by [77767e9e12cbd3e03f8ad917f6d3e8c1e4918c43/trunk]. (See #2231 for why that didn't show up here automatically.)
In /tahoe-lafs/trac-2024-07-25/commit/4889129f3732219cb9cedb1eb27dec3da3f22db2:
In /tahoe-lafs/trac-2024-07-25/commit/4889129f3732219cb9cedb1eb27dec3da3f22db2: