Parse 0 fill value as "" for str dtype by moradology · Pull Request #2798 · zarr-developers/zarr-python

moradology · 2025-02-04T19:36:06Z

This PR implements fill_value parsing for v2 metadata such that if the dtype specified is str, and 0 is the provided fill_value, this value is replaced with ""

Closes#2792

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/user-guide/*.rst
Changes documented as a new file in changes/
GitHub Actions have all passed
Test coverage is 100% (Codecov passes)

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

moradology · 2025-02-04T19:38:37Z

+ # No zarr_format available here...
+ # fill_value_parsed = parse_fill_value(fill_value, dtype, zarr_format=2)
+ fill_value_parsed = fill_value


Not sure what to make of this. The fill value is parsed way up the stack from here or else the dtype we have to inspect is lost. Should I just toss this out?

d-v-b · 2025-02-05T10:12:15Z

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

Sorry that all the parsing was confusing, we should definitely avoid parsing the same things twice! Could you open an issue for the values that are getting parsed multiple times?

d-v-b · 2025-02-05T10:17:33Z


-def parse_fill_value(data: Any) -> Any:
+def parse_fill_value(fill_value: Any, dtype: Any, zarr_format: ZarrFormat) -> Any:
+ if zarr_format == 2 and (dtype is str or dtype == "str") and fill_value == 0:


I think this needs at least a comment explaining why we are doing this. what was zarr-python 2's behavior in this situation?

moradology · 2025-02-05T14:37:05Z

Looks like this has been superseded by 2799

LDeakin · 2025-02-06T01:17:44Z

@moradology #2799 is resolving a separate issue (None fill values) and does not supersede this PR. But there is uncertainty over how #2792 should be handled, as the behaviour has changed between zarr-python 2/3, see #2792 (comment).

moradology · 2025-02-04T19:36:06Z

This PR implements fill_value parsing for v2 metadata such that if the dtype specified is str, and 0 is the provided fill_value, this value is replaced with ""

Closes#2792

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/user-guide/*.rst
Changes documented as a new file in changes/
GitHub Actions have all passed
Test coverage is 100% (Codecov passes)

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

moradology · 2025-02-04T19:38:37Z

+ # No zarr_format available here...
+ # fill_value_parsed = parse_fill_value(fill_value, dtype, zarr_format=2)
+ fill_value_parsed = fill_value


Not sure what to make of this. The fill value is parsed way up the stack from here or else the dtype we have to inspect is lost. Should I just toss this out?

d-v-b · 2025-02-05T10:12:15Z

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

Sorry that all the parsing was confusing, we should definitely avoid parsing the same things twice! Could you open an issue for the values that are getting parsed multiple times?

d-v-b · 2025-02-05T10:17:33Z


-def parse_fill_value(data: Any) -> Any:
+def parse_fill_value(fill_value: Any, dtype: Any, zarr_format: ZarrFormat) -> Any:
+ if zarr_format == 2 and (dtype is str or dtype == "str") and fill_value == 0:


I think this needs at least a comment explaining why we are doing this. what was zarr-python 2's behavior in this situation?

moradology · 2025-02-05T14:37:05Z

Looks like this has been superseded by 2799

LDeakin · 2025-02-06T01:17:44Z

@moradology #2799 is resolving a separate issue (None fill values) and does not supersede this PR. But there is uncertainty over how #2792 should be handled, as the behaviour has changed between zarr-python 2/3, see #2792 (comment).

moradology · 2025-02-04T19:36:06Z

This PR implements fill_value parsing for v2 metadata such that if the dtype specified is str, and 0 is the provided fill_value, this value is replaced with ""

Closes#2792

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/user-guide/*.rst
Changes documented as a new file in changes/
GitHub Actions have all passed
Test coverage is 100% (Codecov passes)

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

moradology · 2025-02-04T19:38:37Z

+ # No zarr_format available here...
+ # fill_value_parsed = parse_fill_value(fill_value, dtype, zarr_format=2)
+ fill_value_parsed = fill_value


Not sure what to make of this. The fill value is parsed way up the stack from here or else the dtype we have to inspect is lost. Should I just toss this out?

d-v-b · 2025-02-05T10:12:15Z

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

Sorry that all the parsing was confusing, we should definitely avoid parsing the same things twice! Could you open an issue for the values that are getting parsed multiple times?

d-v-b · 2025-02-05T10:17:33Z


-def parse_fill_value(data: Any) -> Any:
+def parse_fill_value(fill_value: Any, dtype: Any, zarr_format: ZarrFormat) -> Any:
+ if zarr_format == 2 and (dtype is str or dtype == "str") and fill_value == 0:


I think this needs at least a comment explaining why we are doing this. what was zarr-python 2's behavior in this situation?

moradology · 2025-02-05T14:37:05Z

Looks like this has been superseded by 2799

LDeakin · 2025-02-06T01:17:44Z

@moradology #2799 is resolving a separate issue (None fill values) and does not supersede this PR. But there is uncertainty over how #2792 should be handled, as the behaviour has changed between zarr-python 2/3, see #2792 (comment).

moradology · 2025-02-04T19:36:06Z

This PR implements fill_value parsing for v2 metadata such that if the dtype specified is str, and 0 is the provided fill_value, this value is replaced with ""

Closes#2792

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/user-guide/*.rst
Changes documented as a new file in changes/
GitHub Actions have all passed
Test coverage is 100% (Codecov passes)

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

moradology · 2025-02-04T19:38:37Z

+ # No zarr_format available here...
+ # fill_value_parsed = parse_fill_value(fill_value, dtype, zarr_format=2)
+ fill_value_parsed = fill_value


Not sure what to make of this. The fill value is parsed way up the stack from here or else the dtype we have to inspect is lost. Should I just toss this out?

d-v-b · 2025-02-05T10:12:15Z

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

Sorry that all the parsing was confusing, we should definitely avoid parsing the same things twice! Could you open an issue for the values that are getting parsed multiple times?

d-v-b · 2025-02-05T10:17:33Z


-def parse_fill_value(data: Any) -> Any:
+def parse_fill_value(fill_value: Any, dtype: Any, zarr_format: ZarrFormat) -> Any:
+ if zarr_format == 2 and (dtype is str or dtype == "str") and fill_value == 0:


I think this needs at least a comment explaining why we are doing this. what was zarr-python 2's behavior in this situation?

moradology · 2025-02-05T14:37:05Z

Looks like this has been superseded by 2799

LDeakin · 2025-02-06T01:17:44Z

@moradology #2799 is resolving a separate issue (None fill values) and does not supersede this PR. But there is uncertainty over how #2792 should be handled, as the behaviour has changed between zarr-python 2/3, see #2792 (comment).

moradology · 2025-02-04T19:36:06Z

This PR implements fill_value parsing for v2 metadata such that if the dtype specified is str, and 0 is the provided fill_value, this value is replaced with ""

Closes#2792

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/user-guide/*.rst
Changes documented as a new file in changes/
GitHub Actions have all passed
Test coverage is 100% (Codecov passes)

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

moradology · 2025-02-04T19:38:37Z

+ # No zarr_format available here...
+ # fill_value_parsed = parse_fill_value(fill_value, dtype, zarr_format=2)
+ fill_value_parsed = fill_value


Not sure what to make of this. The fill value is parsed way up the stack from here or else the dtype we have to inspect is lost. Should I just toss this out?

d-v-b · 2025-02-05T10:12:15Z

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

Sorry that all the parsing was confusing, we should definitely avoid parsing the same things twice! Could you open an issue for the values that are getting parsed multiple times?

d-v-b · 2025-02-05T10:17:33Z


-def parse_fill_value(data: Any) -> Any:
+def parse_fill_value(fill_value: Any, dtype: Any, zarr_format: ZarrFormat) -> Any:
+ if zarr_format == 2 and (dtype is str or dtype == "str") and fill_value == 0:


I think this needs at least a comment explaining why we are doing this. what was zarr-python 2's behavior in this situation?

moradology · 2025-02-05T14:37:05Z

Looks like this has been superseded by 2799

LDeakin · 2025-02-06T01:17:44Z

@moradology #2799 is resolving a separate issue (None fill values) and does not supersede this PR. But there is uncertainty over how #2792 should be handled, as the behaviour has changed between zarr-python 2/3, see #2792 (comment).

moradology · 2025-02-04T19:36:06Z

This PR implements fill_value parsing for v2 metadata such that if the dtype specified is str, and 0 is the provided fill_value, this value is replaced with ""

Closes#2792

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/user-guide/*.rst
Changes documented as a new file in changes/
GitHub Actions have all passed
Test coverage is 100% (Codecov passes)

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

moradology · 2025-02-04T19:38:37Z

+ # No zarr_format available here...
+ # fill_value_parsed = parse_fill_value(fill_value, dtype, zarr_format=2)
+ fill_value_parsed = fill_value


Not sure what to make of this. The fill value is parsed way up the stack from here or else the dtype we have to inspect is lost. Should I just toss this out?

d-v-b · 2025-02-05T10:12:15Z

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

Sorry that all the parsing was confusing, we should definitely avoid parsing the same things twice! Could you open an issue for the values that are getting parsed multiple times?

d-v-b · 2025-02-05T10:17:33Z


-def parse_fill_value(data: Any) -> Any:
+def parse_fill_value(fill_value: Any, dtype: Any, zarr_format: ZarrFormat) -> Any:
+ if zarr_format == 2 and (dtype is str or dtype == "str") and fill_value == 0:


I think this needs at least a comment explaining why we are doing this. what was zarr-python 2's behavior in this situation?

moradology · 2025-02-05T14:37:05Z

Looks like this has been superseded by 2799

LDeakin · 2025-02-06T01:17:44Z

@moradology #2799 is resolving a separate issue (None fill values) and does not supersede this PR. But there is uncertainty over how #2792 should be handled, as the behaviour has changed between zarr-python 2/3, see #2792 (comment).

moradology · 2025-02-04T19:36:06Z

This PR implements fill_value parsing for v2 metadata such that if the dtype specified is str, and 0 is the provided fill_value, this value is replaced with ""

Closes#2792

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/user-guide/*.rst
Changes documented as a new file in changes/
GitHub Actions have all passed
Test coverage is 100% (Codecov passes)

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

moradology · 2025-02-04T19:38:37Z

+ # No zarr_format available here...
+ # fill_value_parsed = parse_fill_value(fill_value, dtype, zarr_format=2)
+ fill_value_parsed = fill_value


Not sure what to make of this. The fill value is parsed way up the stack from here or else the dtype we have to inspect is lost. Should I just toss this out?

d-v-b · 2025-02-05T10:12:15Z

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

Sorry that all the parsing was confusing, we should definitely avoid parsing the same things twice! Could you open an issue for the values that are getting parsed multiple times?

d-v-b · 2025-02-05T10:17:33Z


-def parse_fill_value(data: Any) -> Any:
+def parse_fill_value(fill_value: Any, dtype: Any, zarr_format: ZarrFormat) -> Any:
+ if zarr_format == 2 and (dtype is str or dtype == "str") and fill_value == 0:


I think this needs at least a comment explaining why we are doing this. what was zarr-python 2's behavior in this situation?

moradology · 2025-02-05T14:37:05Z

Looks like this has been superseded by 2799

LDeakin · 2025-02-06T01:17:44Z

@moradology #2799 is resolving a separate issue (None fill values) and does not supersede this PR. But there is uncertainty over how #2792 should be handled, as the behaviour has changed between zarr-python 2/3, see #2792 (comment).

moradology · 2025-02-04T19:36:06Z

This PR implements fill_value parsing for v2 metadata such that if the dtype specified is str, and 0 is the provided fill_value, this value is replaced with ""

Closes#2792

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/user-guide/*.rst
Changes documented as a new file in changes/
GitHub Actions have all passed
Test coverage is 100% (Codecov passes)

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

moradology · 2025-02-04T19:38:37Z

+ # No zarr_format available here...
+ # fill_value_parsed = parse_fill_value(fill_value, dtype, zarr_format=2)
+ fill_value_parsed = fill_value


Not sure what to make of this. The fill value is parsed way up the stack from here or else the dtype we have to inspect is lost. Should I just toss this out?

d-v-b · 2025-02-05T10:12:15Z

As a side note, I was a bit surprised at how many places there were that independently seemed to be concerned with metadata parsing. This... was slightly confusing, as values undergo multiple parse_* steps after having been parsed already (so that it is unclear without printing stack and dropping into a debugger when e.g. dtype was the provided dtype vs when it was the already parsed dtype. In this case, as the dtype of object is produced by parse_dtype in init_array, the only place where it was possible to check on the dtype specified by the user was at that point (way up the stack from calls into v2.py). Not sure I quite understand the organization (though I'm sure there are good reasons for it; perhaps historical and compatibility related) and I'd be very interested in a rough sketch of the motivation that I'm surely failing to see

Sorry that all the parsing was confusing, we should definitely avoid parsing the same things twice! Could you open an issue for the values that are getting parsed multiple times?

d-v-b · 2025-02-05T10:17:33Z


-def parse_fill_value(data: Any) -> Any:
+def parse_fill_value(fill_value: Any, dtype: Any, zarr_format: ZarrFormat) -> Any:
+ if zarr_format == 2 and (dtype is str or dtype == "str") and fill_value == 0:


I think this needs at least a comment explaining why we are doing this. what was zarr-python 2's behavior in this situation?

moradology · 2025-02-05T14:37:05Z

Looks like this has been superseded by 2799

LDeakin · 2025-02-06T01:17:44Z

@moradology #2799 is resolving a separate issue (None fill values) and does not supersede this PR. But there is uncertainty over how #2792 should be handled, as the behaviour has changed between zarr-python 2/3, see #2792 (comment).

github-actionsBot added the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

moradology commented Feb 4, 2025
View reviewed changes

moradology force-pushed the fix/0fill-str-v2 branch from 2e7a739 to fa2f8f5Compare February 4, 2025 19:40

Parse 0 fill value as "" for str dtype
0afbf7e

moradology force-pushed the fix/0fill-str-v2 branch from fa2f8f5 to 0afbf7eCompare February 4, 2025 19:42

github-actionsBot removed the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

d-v-b reviewed Feb 5, 2025
View reviewed changes

moradology closed this Feb 5, 2025

moradology deleted the fix/0fill-str-v2 branch February 5, 2025 14:37

github-actionsBot added the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

moradology commented Feb 4, 2025
View reviewed changes

moradology force-pushed the fix/0fill-str-v2 branch from 2e7a739 to fa2f8f5Compare February 4, 2025 19:40

Parse 0 fill value as "" for str dtype
0afbf7e

moradology force-pushed the fix/0fill-str-v2 branch from fa2f8f5 to 0afbf7eCompare February 4, 2025 19:42

github-actionsBot removed the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

d-v-b reviewed Feb 5, 2025
View reviewed changes

moradology closed this Feb 5, 2025

moradology deleted the fix/0fill-str-v2 branch February 5, 2025 14:37

github-actionsBot added the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

moradology commented Feb 4, 2025
View reviewed changes

moradology force-pushed the fix/0fill-str-v2 branch from 2e7a739 to fa2f8f5Compare February 4, 2025 19:40

Parse 0 fill value as "" for str dtype
0afbf7e

moradology force-pushed the fix/0fill-str-v2 branch from fa2f8f5 to 0afbf7eCompare February 4, 2025 19:42

github-actionsBot removed the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

d-v-b reviewed Feb 5, 2025
View reviewed changes

moradology closed this Feb 5, 2025

moradology deleted the fix/0fill-str-v2 branch February 5, 2025 14:37

github-actionsBot added the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

moradology commented Feb 4, 2025
View reviewed changes

moradology force-pushed the fix/0fill-str-v2 branch from 2e7a739 to fa2f8f5Compare February 4, 2025 19:40

Parse 0 fill value as "" for str dtype
0afbf7e

moradology force-pushed the fix/0fill-str-v2 branch from fa2f8f5 to 0afbf7eCompare February 4, 2025 19:42

github-actionsBot removed the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

d-v-b reviewed Feb 5, 2025
View reviewed changes

moradology closed this Feb 5, 2025

moradology deleted the fix/0fill-str-v2 branch February 5, 2025 14:37

github-actionsBot added the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

moradology commented Feb 4, 2025
View reviewed changes

moradology force-pushed the fix/0fill-str-v2 branch from 2e7a739 to fa2f8f5Compare February 4, 2025 19:40

Parse 0 fill value as "" for str dtype
0afbf7e

moradology force-pushed the fix/0fill-str-v2 branch from fa2f8f5 to 0afbf7eCompare February 4, 2025 19:42

github-actionsBot removed the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

d-v-b reviewed Feb 5, 2025
View reviewed changes

moradology closed this Feb 5, 2025

moradology deleted the fix/0fill-str-v2 branch February 5, 2025 14:37

github-actionsBot added the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

moradology commented Feb 4, 2025
View reviewed changes

moradology force-pushed the fix/0fill-str-v2 branch from 2e7a739 to fa2f8f5Compare February 4, 2025 19:40

Parse 0 fill value as "" for str dtype
0afbf7e

moradology force-pushed the fix/0fill-str-v2 branch from fa2f8f5 to 0afbf7eCompare February 4, 2025 19:42

github-actionsBot removed the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

d-v-b reviewed Feb 5, 2025
View reviewed changes

moradology closed this Feb 5, 2025

moradology deleted the fix/0fill-str-v2 branch February 5, 2025 14:37

github-actionsBot added the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

moradology commented Feb 4, 2025
View reviewed changes

moradology force-pushed the fix/0fill-str-v2 branch from 2e7a739 to fa2f8f5Compare February 4, 2025 19:40

Parse 0 fill value as "" for str dtype
0afbf7e

moradology force-pushed the fix/0fill-str-v2 branch from fa2f8f5 to 0afbf7eCompare February 4, 2025 19:42

github-actionsBot removed the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

d-v-b reviewed Feb 5, 2025
View reviewed changes

moradology closed this Feb 5, 2025

moradology deleted the fix/0fill-str-v2 branch February 5, 2025 14:37

github-actionsBot added the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

moradology commented Feb 4, 2025
View reviewed changes

moradology force-pushed the fix/0fill-str-v2 branch from 2e7a739 to fa2f8f5Compare February 4, 2025 19:40

Parse 0 fill value as "" for str dtype
0afbf7e

moradology force-pushed the fix/0fill-str-v2 branch from fa2f8f5 to 0afbf7eCompare February 4, 2025 19:42

github-actionsBot removed the needs release notes Automatically applied to PRs which haven't added release notes label Feb 4, 2025

d-v-b reviewed Feb 5, 2025
View reviewed changes

moradology closed this Feb 5, 2025

moradology deleted the fix/0fill-str-v2 branch February 5, 2025 14:37

Uh oh!

Uh oh!

Conversation

moradology commented Feb 4, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-v-b commented Feb 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

moradology commented Feb 5, 2025

Uh oh!

LDeakin commented Feb 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

moradology commented Feb 4, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-v-b commented Feb 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

moradology commented Feb 5, 2025

Uh oh!

LDeakin commented Feb 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

moradology commented Feb 4, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-v-b commented Feb 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

moradology commented Feb 5, 2025

Uh oh!

LDeakin commented Feb 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

moradology commented Feb 4, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

moradology commented Feb 4, 2025•
edited
Loading

moradology commented Feb 4, 2025•
edited
Loading

moradology commented Feb 4, 2025•
edited
Loading

moradology commented Feb 4, 2025•
edited
Loading

moradology commented Feb 4, 2025•
edited
Loading