Cannot read a nc file that contains the diacritic mark tilde (á) in the path

[gitxiaobai667]

What is your issue?

When I use xarray to open a nc file that contains the diacritic mark tilde (á) in the path, I get an error

import xarray as xr
import numpy as np

# Create a new dataset using xarray
data = xr.Dataset(
    {
        "temperature": (("x", "y"), np.random.rand(100, 100))
    },
    coords={
        "x": np.linspace(0, 1, 100),
        "y": np.linspace(0, 1, 100)
    }
)


# I don't know if there are any errors in this step,
# because the actual Chinese text I generated here "example_xarray_谩.nc"
data.to_netcdf('example_xarray_á.nc' )

Running the following one will cause an error

dataset = xr.open_dataset('example_xarray_á.nc')

FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\DELL\\Desktop\\example_xarray_á.nc'

[kmuehlbauer]

@gitxiaobai667 As @max-sixty already told you twice to fill out the bug template properly, please do so. We still miss essential information (eg. OS, version of dependencies). We all have limited bandwidth and rather dedicate our time to well written bug-reports.

This might be an issue with windows system encoding and or netcdf-c/hdf5:

• load_dataset fails when filename is unicode #3974
• netCDF failing roundtrip with unicode chars #5666
• Error opening netcdf in path with "special" characters Unidata/netcdf4-python#941
• Chinese character in the path using netcdf4 dataset Unidata/netcdf4-python#997

Check your issue with recent versions of xarray/netcdf-c/hdf5/netcdf4-python in your environment and see if the issue persists.

I do not close this issue yet. But if you do not provide the full information according to the bug template some other core dev might do so in the next days.

[max-sixty]

That example completes successfully for me. It seems from the issues that @kmuehlbauer linked that this is likely a Windows issue. It's looks like an upstream issue.

Thanks at least for the example @gitxiaobai667 (though as @kmuehlbauer points out, the bug report is not filled out)

But closing as an upstream bug — please follow those issues. If you're confident that your issue is substantially different, please fill out a new bug report template.

[keewis]

I think the misunderstanding here is that they always chose our "issue" template while the template with the more detailed forms is the "bug report" template (so they never saw the other template and are likely confused about what you are asking for). Should we rename the "issue" template? What do you think about "general issue"? Or maybe something not involving the word "issue" might be better?

[kmuehlbauer]

@keewis Oh, ha, that's painful. Sorry, I'll be more careful on that next time. Thanks for making this obvious.

I'm not sure how to improve this to be more specific The question is what do we understand as General issue, that's not a bug report.?

[keewis]

Note that that's just how I interpret this situation, I can't be certain without hearing back from them. However, based on my own experience with foreign languages these things can happen (like, you know what an issue is but are not sure what "bug report" means), and I was wondering how we can make things a bit more obvious. Though in the end, all of this depends on working communication, which is not easy if the language proficiency differs, especially with a technical topic and in writing.

So maybe it could help to ask to fill in the "bug report template" if what was posted sounds like a bug? That might go a long way of making things a bit clearer.

As for the templates, maybe move the blank template below the feature request and change the help text/name to something along the lines of "use only if it doesn't fit the other templates (mostly intended for development organization)"? (since that's how I understood it when we added that template)

[max-sixty]

I think the misunderstanding here is that they always chose our "issue" template while the template with the more detailed forms is the "bug report" template

The first issue was the bug report template! #8529 — they just skipped past most of the fields.

My guess is that they're newer to this, don't have much context, and wanted to get help. Maybe someone suggested they open an issue. I don't think we need to believe people are badly intentioned to hold high standards for issues

I'm very open to feedback on better ways to have done this — I certainly don't revel in closing issues (feedback.maxroos.com !)

---

More generally, I'm holding there are two reasonable equilibria:

1. GH Issues are only used for bug reports / feature requests, and we set clear expectations. Currently at xarray, we follow this model.
2. GH Issues are also for "user support", and there are people who enjoy answering these questions or think it's beneficial enough for the project. (At PRQL we follow this model)

A bad approach is to have expectations of user support but then to not get around it — people write things that don't get responses, issues stack up, we miss out on the high quality bug reports that could have made the library better. So hence me being quite strict here. There's then a gap in user support — to some extent that's inevitable given the relative supply & demand¹.

---

@gitxiaobai667 if you see this — what could have made this experience better for you, aside from having your question answered? Were the instructions unclear? Did you get what you wanted from @kmuehlbauer 's message. We appreciate you at least attempting to engage...

Footnotes

1. Though maybe there's a also a business to be started in allowing maintainers of open-source projects to offer a couple of hours of support — I would be a buyer in some other projects! ↩