GeezerVison

warnings are a mecanism for a module author to communicate about bad usage to other developers calling the code, not to communicate with end-users: https://docs.python.org/3/howto/logging.html#when-to-use-logging

So using logging.warning() here should be appropriate?

Edit: I'm not really sure between logging.info, warnings.warn and logging.warning. This function can be used in both libraries and end user apps.

• it's not necessarily true (but can be) that client app needs to be modified -- for example if it needs to always extract all files, it can be changed to use ZipFile module
• it's also not true that client app cannot do anything about it -- it can potentially use ZipFIle module or 3rd party module or custom logic.
• logging.info seems not specific enough because we're warning somebody (user or developer) that files are skipped.

This might be an edge case that falls between warnings.warn and logging.warning? If so, I don't mind using one that you prefer.

I looked for a similar usages in the library and found this:

it's very similar in that both cases warn about something being lost when creating / unpacking a zip file: some contained files and a part of a comment respectively. That warning was added in 2014.

Good find! @serhiy-storchaka added that change, maybe he can comment here.

I just replaced existing prints with warnings. I am not sure that it is a good solution, but it at least gives the user some control: warnings can be printed, silenced or converted to exceptions.

I found another example where warning would be for the end user rather than app author: https://github.com/pganssle/zoneinfo/blob/c54d700fcba78b20733390ee3014809ad69858f6/src/backports/zoneinfo/_tzpath.py#L58

-- this one is from 2020 by Paul Ganssle

However I think for this use case, I don't see any issue with using logging.warning or logging.error. But I wonder which one of those would be more appropriate. It fits the description of logging.error more closely but at the same time treating it as an "error" might be too strong.

In general logging.warning would be cleaner here than using the warnings module. As Éric says, this is a data-driven problem that is of interest to the end-user, less so to the developer of the application.

@akulakov you could in fact ask on python-dev about the general practice if you want feedback; but I don't think this is particularly controversial: libraries can log things to end-users, and many do. I'd just use the logging module here, and as a follow-up task, fix the other warnings call you found in zipfile.

@ambv: I agree; I was going to update it but got a little distracted -- will push an update today or tomorrow.. Thanks for looking at this as well!

A few functions in shutil.py accept logger as an arg and use it to print info/debug logs. I think in this case there's no reason to follow this pattern because we want the warnings to be displayed by default.