Skip to content
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

Mutable" no longer being used #727

Closed

Conversation

salman2013
Copy link
Contributor

@salman2013 salman2013 commented Mar 15, 2024

@salman2013 salman2013 marked this pull request as ready for review March 15, 2024 11:01
@salman2013 salman2013 requested a review from farhan March 15, 2024 11:01
@salman2013 salman2013 changed the title chore: remove mutable property Mutable" no longer being used Mar 15, 2024
@@ -703,7 +703,7 @@ def test_setting_the_same_value_marks_field_as_dirty():
# pylint: disable=unsubscriptable-object
class FieldTester(XBlock):
"""Test block for set - get test."""
non_mutable = String(scope=Scope.settings)
# non_mutable = String(scope=Scope.settings)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why have you commented them rather than removing them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i mistakenly left them, i have removed them.

@salman2013 salman2013 requested a review from farhan March 15, 2024 12:26
@farhan
Copy link
Contributor

farhan commented Mar 18, 2024

@salman2013 Approved
please rebase branch

@@ -720,7 +712,6 @@ class Float(JSONField):
something for which float(value) does not throw an error.

"""
MUTABLE = False
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, looking at this more closely, there might be a memory usage implication for this change. It may produce more copies of the defaults than we want for certain objects. Perhaps this is something we need to keep after all.

My thought is this: If whenever we ask for the default value of certain fields, it makes a new copy of the default value via deepcopy then we will increase the memory usage of the application each time a new default is loaded. Given that these are fields in xblocks, that might happen quite a bit, so I wonder if it actually makes more sense to not make this change and instead decide that we're happy with the code as is. @salman2013 @farhan what do you guys think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@feanil I think your point of increasing memory usage makes sense and we should not make this change, actually when i removed it the perception in my mind was the value MUTABLE is true by default

MUTABLE = True
_default = None
# Indicates if a field's None value should be sent to the XML representation.
none_to_xml = False
@@ -334,10 +333,7 @@ def init(self, help=None, default=UNSET, scope=Scope.content, # pylint:disa
@Property
def default(self):
"""Returns the static value that this defaults to."""
if self.MUTABLE:
return copy.deepcopy(self._default)

and its already making a deep copy and maybe it would be for some reason but yeah your point is valid it would increase app memory size whenever it is used.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, let's abandon this PR and close the related issue with a link to this PR and a summary of the reason why we did not pursue it.

@salman2013 salman2013 mentioned this pull request Mar 19, 2024
3 tasks
@salman2013
Copy link
Contributor Author

For the reason of the following discussion i am marking this PR as close and we will not make this change merge.
#727 (comment)

@salman2013 salman2013 closed this Mar 21, 2024
@salman2013 salman2013 deleted the salman/remove-mutable-property branch March 21, 2024 06:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants