[Python-Dev] Re: Summary of Python tracker Issues
On Fri, Apr 29, 2022 at 8:12 PM Python tracker wrote: > ACTIVITY SUMMARY (2022-04-22 - 2022-04-29) > Python tracker at https://bugs.python.org/ > > To view or respond to any of the issues listed below, click on the issue. > Do NOT respond to this message. > > Issues counts and deltas: > open7146 ( +0) > closed 51841 ( +0) > total 58987 ( +0) Congrats! We finally managed to stop users from reporting new bugs. Python reached perfection 😍 Victor ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/X4NPUP6OX2AS2E3EWBSAFAO543B7KTYW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How about using modern C++ in development of CPython ?
Denis Kotov writes: > From huge codebase experience with C++, it does not cause > significantly better (1) Readabillity or (2) Maintainability on its > own compared to C But that's not what we're talking about. "Port CPython to C++" is a perennial suggestion that gets rejected fairly quickly, as the C++ stdlib equivalent structures and functions in CPython are efficient and well-tested. I don't know much about Rust but I know that some core modules have already been ported to Rust. Since core devs, with a specific reason (security, it's crypto stuff) to move away from C are involved in that effort I would guess that movint to Rust is far more likely than to C++. The point of C++ standard support level is linking CPython to external codebases using C++, and at least for the standard CPython currently supports, the C++ ABI is specific to each compiler and version (for some compilers), right? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EZ7B7SL233QTMN6GEEA4SJDHIBGFIEIC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How about using modern C++ in development of CPython ?
Stephen J. Turnbull wrote: > The point of C++ standard support level is linking CPython to external > codebases using C++, and at least for the standard CPython currently > supports, the C++ ABI is specific to each compiler and version (for > some compilers), right? Yes, C++ ABI is specific to each compiler, but it is not a problem, because you will anyway recompile CPython for each compiler !! Also g++ and clang++ has the same C++ ABI !! Usually people say that C++ not fit in CPython not knowing C++, it is common thing in psychology: https://en.wikipedia.org/wiki/I_know_that_I_know_nothing https://medium.com/@cogitality/the-dunning-kruger-effect-a-paradox-that-doesnt-apply-to-me-e48de7b3f77f Lets consider the advantages of C++: 1) C++ has objects, Python has objects, C do not have objects (struct is not object in term of OOP) 2) C++ has templates that allow to generate for free function specialization to improve performance 3) C++ has move semantic and switching to C++ you have move object for free !! 4) C++ has RAII (equivalent to CPython __del__), that works the same way to 5) ... and so on ... ... but i will not convince you because it is also another psychology stuff, if you what to believe in something, you will try to find evidences for proving your theory, see also: https://www.youtube.com/watch?v=vUzGV4F7He8 Please, to not take it personally, i just shared my thought about all of this discussion ... I just optimistic all my life that is why I try to impact, even if it is almost impossible ))) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EQ5ETXJKK4DA4APAMQPGDVLRQYBPCA23/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How about using modern C++ in development of CPython ?
Denis Kotov writes: > Yes, C++ ABI is specific to each compiler, but it is not a problem, > because you will anyway recompile CPython for each compiler !! Right, but the point is that we want few C++ compilers people really use to get upset by Python code. Since most changes are backward compatible (or new compilers may have a backward compatibility option) specifying an older standard accomplishes that goal. > Usually people say that C++ not fit in CPython not knowing C++, That's not the issue. There are plenty of people who know C++ who say the benefits of C++ are not worth the bugs, the effort, and the plain old churn that a rewrite in C++ (even if incremental) would require. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XLVVIUVBYLXFQYPRMHY5H3ZRGDCYB45W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] __dunder__ = None
There is a special handling of `__hash__` set to None in the interpreter
core. This is because every class inherited the `__hash__` attribute
from "object", and setting `__hash__ = None` is a simple way to make it
unhashable. It makes hash() raising the correct type of exception
(TypeError), but with unhelpful error message "'NoneType' object is not
callable". The special case was added to make the error message more
relevant: "unhashable type: '{typename}'".
There is similar situation with other special methods defined in
"object" or other common classes. Sometimes we want to cancel the
default inherited behavior.
>>> dir(object)
['__class__', '__delattr__', '__dir__', '__doc__', '__eq__',
'__format__', '__ge__', '__getattribute__', '__getstate__', '__gt__',
'__hash__', '__init__', '__init_subclass__', '__le__', '__lt__',
'__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__sizeof__', '__str__', '__subclasshook__']
I propose to support officially the idiom "__dunder__ = None" and add
special cases to raise more specialized exception instead of "TypeError:
'NoneType' object is not callable" for most of special method where
cancelling the default behavior makes sense (for example I do not think
that we need better error message for `__repr__ = None`).
The question is how to interpret value None:
* Always raise TypeError (with changed message)? This is what happen
currently when you set the method to None, this is the most compatible
option.
* Always raise an error, but allow to change it to more appropriate type
(for example AttributeError for __setattr__)?
* Interpret value None the same way as an absent attribute?
For `__hash__` or `__class_getitem__` all three options mean the same.
But absent `__mro_entries__` and `__mro_entries__ = None` currently give
different results. It is even more complicated for pickling: absent
`__reduce_ex__` and `__reduce_ex__ = None` mean the same in the Python
implementation, but give different results in the C implementation.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/YGAK34DRWJFSIV2VZ4NC2J24XO37GCMM/
Code of Conduct: http://python.org/psf/codeofconduct/
