Maybe we can wait for the promoter to answer. I won't open this PR before I decide whether to abandon or remove it.

I looked at the code again and agree with my opinion from 2021: it should be deprecated and eventually removed.

It could be useful to do a code search (e.g., GitHub code search, Hugo's top 5k pypi packages tool) to see how the name is being used.

A possible approach to deprecation could be to remove the current line adding it to _socket, and add a module __getattr__ to both the _socket and socket modules that raises a DeprecationWarning and then returns _socket.socket.

Okay, I'll re-revise this PR so that it throws a warning when calling this type. Call me back in this PR when we consider removing it in the future :)

It seems that the module __getattr__ only works for attributes that do not exist, which makes it necessary to remove the export in socketmodule. But it triggers a deprecation warning. Emmm...

It seems that the module getattr only works for attributes that do not exist, which makes it necessary to remove the export in socketmodule. But it triggers a deprecation warning. Emmm...

It works for any kind of attributes. Please, read PEP-562 for examples on how to use it.

It seems that the module getattr only works for attributes that do not exist, which makes it necessary to remove the export in socketmodule. But it triggers a deprecation warning. Emmm...

It works for any kind of attributes. Please, read PEP-562 for examples on how to use it.

I read the document and modified it. But why does it trigger this

Traceback (most recent call last):
  File "D:\a\cpython\cpython\Lib\test\pythoninfo.py", line 1062, in collect_info
    collect_func(info_add)
    ~~~~~~~~~~~~^^^^^^^^^^
  File "D:\a\cpython\cpython\Lib\test\pythoninfo.py", line 727, in collect_test_socket
    from test import test_socket
  File "D:\a\cpython\cpython\Lib\test\test_socket.py", line 201, in <module>
    HAVE_SOCKET_CAN = _have_socket_can()
  File "D:\a\cpython\cpython\Lib\test\test_socket.py", line 104, in _have_socket_can
    s = socket.socket(socket.PF_CAN, socket.SOCK_RAW, socket.CAN_RAW)
  File "D:\a\cpython\cpython\Lib\socket.py", line 242, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object cannot be interpreted as an integer

Edit
It seems to be a consistent bug since I opened the PR.

I think you need to raise an AttributeError from the __getattr__ if it isn't SocketType.

I have changed them as required. Please review them again :)

@vstinner

@ZeroIntensity

It has no issues. Since I wrote it in the socket, if this property is used, it returns _socket.socket instead of SocketType. In reality, this alias is completely useless and doesn't need to be used. In practical applications, using it only triggers a deprecation warning and causes no other runtime issues.

I don't think it hasn't been solved.

I'll double check, but you wrote it for the socket module, not _socket. Now accessing _socket.SocketType raises an attribute error, yes?

Edit: Yup

Python 3.14.0a0 (heads/pr_126272:261d87f082, Nov  8 2024, 13:59:09) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _socket
>>> _socket.SocketType
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    _socket.SocketType
AttributeError: module '_socket' has no attribute 'SocketType'

Yes. But private modules have always been unstable (in my view, it's not surprising if some features are missing, since we don't encourage their use and remain vigilant about the behavior they exhibit).

From jelle

socket.socket the only type that moat users should care about.

_socket is supposed to be private, yes, but Python is big. If we know something will break downstream, we shouldn't try and brush it off as their fault. I gave examples of some very large downstream users, so we need to add a deprecation for it.

I think we could add a getter in the C code, but I’m not sure how Victor feels about it. He didn’t raise any concerns about this during the audit, so maybe he had other considerations in mind.

Victor likely didn't notice because you marked my comment as resolved :(

Emmm, maybe he saw it but didn’t think there was any issue. We can wait for his reply.
（for adding it at c level, I agree.)

Alright, if possible, it would be better to implement __getattr__ in the _socket module.

I didn't know that _socket.SocketType is used currently.