@maxmouchet,@ykvch guys, please take a look on this PR when you get a chance.
I'll greatly appreciate initial review, before someone from core developers gets here.

Thanks for tackling this! This looks good to me.

Maybe the__str__ method could be simplified a little as I think (need to find a source) that an IPv4-mapped IPv6 address will never have a scope identifier.

Maybe the__str__ method could be simplified a little as I think (need to find a source) that an IPv4-mapped IPv6 address will never have a scope identifier.

Thanks! Lets discuss it.
Indeed, according toRFC 4007 Section 11.1, IPv6 address 'scoped' format is meaningless and should not be used for global addresses.
At the same time,

This document, however, does not prohibit an implementation from using the format for those special addresses for implementation dependent purposes.

In addition,RFC 4007 Section 4 says that

[1] defines IPv6 addresses with embedded IPv4 addresses as being part
of global addresses. Thus, those addresses have global scope, with
regard to the IPv6 scoped address architecture. However, an
implementation may use those addresses as if they had other scopes
for convenience. For instance, [6] assigns link-local scope to IPv4
auto-configured link-local addresses (the addresses from the prefix
169.254.0.0/16 [7]) and converts those addresses into IPv4-mapped
IPv6 addresses in order to perform destination address selection
among IPv4 and IPv6 addresses. This would implicitly mean that the
IPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration
link-local addresses have link-local scope. This document does not
preclude such a usage, as long as it is limited within the
implementation.

That is all I managed to find regarding the subject.

Please, let me know what you think about it.

Noticed, thatipaddress.IPv6Address.exploded behavior differs from expected after the patch:

>>> addr = IPv6Address('::ffff:8.8.4.4')# Expected>>> addr.exploded'0000:0000:0000:0000:0000:ffff:8.8.4.4'# Actual>>> addr.exploded'0000:0000:0000:0000:0000:ffff:0808:0404'

I'm in progress fixing that.

This PR is stale because it has been open for 30 days with no activity.

All commit authors signed the Contributor License Agreement.

@opavlyuk Could you sign the new CLA by clickingnot signed button in the cpython-cla-bot's message, please?

@arhadthedev Thanks for letting me know! I initially used the wrong SSH key for the commits, but I've fixed it and the CLA is now marked as signed.
Could you suggest what should I do next to move forward with this PR? Should I contact the python-dev mailing list or take any other steps?

For now, we need to wait.

1. Until 3.12b1 is out next month, core devs with network expertise can be busy with release blockers and PEP-grade features
2. Core devs need time to process through their unread notification queue after work (a couple of days or so, maybe sooner, it depends)
3. There is a feedback gathering month to give everybody a chance to participate in the PR.

@arhadthedev Thanks for clearing things up! Then I'll watch out for the 3.12b1 release and return to the PR once all obstacles are cleared.
It's been waiting here for a while, so I'd like to kindly help it move along when the time is right 🙂

@arhadthedev it appears a month has passed since the last update to the PR, during which time we haven't received further feedback. Also, I noticed that version 3.12.0a7 was released just yesterday.
I understand everyone is likely quite busy. Given these circumstances, do you think it might be appropriate to send a gentle reminder to our PR, in order to possibly draw the attention of the core developers?

@encukou as you may recall, we had a conversation during PyCon SK 2022 where you kindly offered your guidance and support. I'm now writing to kindly ask if you could take a look at this PR. I would greatly appreciate your review, or if you could suggest someone who might be the right person for this task. Thank you for your time and consideration!

@asvetlov could you please review this PR at your earliest convenience?
I understand that the ipaddress module has been without a maintainer for a while 😞
I'd appreciate if you could either take a look yourself or recommend someone appropriate for the task.

Thanks@opavlyuk for the PR, and@asvetlov for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

Thanks@opavlyuk for the PR, and@asvetlov for merging it 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

Thanks@opavlyuk for the PR, and@asvetlov for merging it 🌮🎉.. I'm working now to backport this PR to: 3.10.
🐍🍒⛏🤖

Thanks@opavlyuk for the PR, and@asvetlov for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

Thanks@opavlyuk for the PR, and@asvetlov for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

GH-135078 is a backport of this pull request to the3.9 branch.

GH-135079 is a backport of this pull request to the3.10 branch.

GH-135080 is a backport of this pull request to the3.11 branch.

GH-135081 is a backport of this pull request to the3.12 branch.