-
Notifications
You must be signed in to change notification settings - Fork 192
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
List mypy fix #6635
List mypy fix #6635
Changes from 8 commits
3e4f3ef
b6800dc
f415f55
0dabade
2c0948f
ac5473e
7b9e02e
0b6f37f
9ee616f
c0cc484
715d4c2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -9,6 +9,7 @@ | |
"""`Data` sub class to represent a list.""" | ||
|
||
from collections.abc import MutableSequence | ||
from typing import Any | ||
|
||
from .base import to_aiida_type | ||
from .data import Data | ||
|
@@ -81,15 +82,15 @@ def remove(self, value): | |
self.set_list(data) | ||
return item | ||
|
||
def pop(self, **kwargs): | ||
def pop(self, index: int = -1) -> Any: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I did a little history digging, and the b509727#diff-d02f48db7287263f108efca9214eac06220796c1ba81696adb6764852629f71dR259 I don't know if that means anything, but this change still looks quite scary to me, given that we're changing a public method on a such a basic type. 😰 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think these two methods are not directly called but to mimic the regular There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, definitely should be documented in the CHANGELOG just in case. Thanks! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure! (we don't need to worry about this if there was not too much things happened in the code base, so it is not very urgent thing to have a very clear release plan I assume.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @unkcpz I simply had the info in my head. Since I was involved with pretty much all PRs, or would always look at commits made even if not directly involved, I would be aware of what changes were on main. When planning releases, I would go through the commits and write the changelog, marking which commits would contain breaking changes etc. Since I am not fully involved anymore, I think it makes sense to record these changes as we go along as to make it clearer for anyone. Your suggestion to include updates to the CHANGELOG with PRs makes sense to me.
What do you mean with the nightly release here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What in my mind was something like https://pypi.org/project/streamlit-nightly/ (also a lot other python libraries having this). It is build for every commit main (or we can make it build daily/weekly based with scheduled GH action). It is build and pushed to pypi by CI like https://github.com/streamlit/streamlit/blob/develop/.github/workflows/nightly.yml For the changelog part, I was thinking for each PR we add a line in "## Nigthly" section on top of CHANGELOG and the CI will read it and use it as the release description for nightly release. If we decide to make real release, the CI will read it and use it as the release description for nightly release. If we decide to make real release, the items in the "nightly" section can be moved under the release version section and the CI will then pick it and update the description for each release. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess that would work for a simple branching workflow where everything goes on There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, I think so. So probably the most convenient way is to put things in the CHANGELOG (or somewhere else just in case we didn't synchronous too much between multiple developers in the "MAGA" office). |
||
"""Remove and return item at index (default last).""" | ||
data = self.get_list() | ||
item = data.pop(**kwargs) | ||
item = data.pop(index) | ||
if not self._using_list_reference(): | ||
self.set_list(data) | ||
return item | ||
|
||
def index(self, value): | ||
def index(self, value: Any, start: int = 0, stop: int = 0) -> int: | ||
"""Return first index of value..""" | ||
return self.get_list().index(value) | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the error but it seems strange. The
Field
constructor can return None?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just saw #6630 (comment) interesting