classification
Title: array.array should remain immutable: add Py_TPFLAGS_IMMUTABLETYPE flag
Type: behavior Stage: patch review
Components: Library (Lib) Versions: Python 3.11, Python 3.10
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: vstinner Nosy List: Guido.van.Rossum, Mark.Shannon, christian.heimes, corona10, erlendaasland, gvanrossum, pablogsal, serhiy.storchaka, shihai1991, shreyanavigyan, vstinner
Priority: deferred blocker Keywords: patch

Created on 2021-04-21 18:52 by gvanrossum, last changed 2021-05-02 12:49 by erlendaasland.

Files
File name Uploaded Description Edit
patch.diff erlendaasland, 2021-04-22 08:20
apply-to-all.diff erlendaasland, 2021-04-23 19:49
list.txt erlendaasland, 2021-04-26 10:24
apply-to-all.diff shreyanavigyan, 2021-04-27 06:31 modified
tests_log.txt shreyanavigyan, 2021-04-27 15:52
Pull Requests
URL Status Linked Edit
PR 25520 merged erlendaasland, 2021-04-22 08:54
PR 25696 merged erlendaasland, 2021-04-28 17:07
PR 25697 merged erlendaasland, 2021-04-28 17:07
PR 25710 merged vstinner, 2021-04-29 07:47
PR 25714 merged erlendaasland, 2021-04-29 09:38
PR 25743 merged erlendaasland, 2021-04-30 10:13
PR 25792 merged christian.heimes, 2021-05-01 20:16
PR 25816 open erlendaasland, 2021-05-02 12:49
Messages (103)
msg391540 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-21 18:52
Hi Victor,

Sorry for making this a deferred blocker. I recall that we had a brief discussion somewhere about an accidental change to the array.array type -- this is now a heap type (Py_TPFLAGS_HEAPTYPE is set), and as a consequence it is no longer immutable.

In 3.9 this is an error:

>>> import array        
>>> array.array.foo = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't set attributes of built-in/extension type 'array.array'
>>>

But in 3.10a7 it passes:

>>> array.array.foo = 1
>>> array.array.foo    
1
>>>

I would like this type (and other types that have been or will be converted to heap types) to remain immutable. How can we do that? I think we may need a new flag bit meaning "built-in type, immutable". This bit should not be inherited of course.

What do you think? (Feel free to close if this is a duplicate -- I couldn't find where we discussed this previously, sorry.)
msg391578 - (view) Author: hai shi (shihai1991) * (Python triager) Date: 2021-04-22 06:46
> I would like this type (and other types that have been or will be converted to heap types) to remain immutable.

  Hi, Guido. I am interested in what have been broken in fact? or it's a defined behavior?

> I think we may need a new flag bit meaning "built-in type, immutable". This bit should not be inherited of course.
  
  Aggreed. Adding a new `tp_flag` is a lightweight solution.
msg391582 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-22 08:20
FWIW, I was the one who converted arraymodule to use heap types in 75bf107c62fbdc00af51ee4f6ab69df4bd201104 (GH-23124) in January. Sorry 'bout the accidental change of behaviour.

> I think we may need a new flag bit meaning "built-in type, immutable". This bit should not be inherited of course.

+1.

See attached PoC patch. As far as I understand, type flags must be explicitly inherited in Objects/typeobject.c, no?

Should all previous static types be immutable, or are there exceptions?
msg391584 - (view) Author: Mark Shannon (Mark.Shannon) * (Python committer) Date: 2021-04-22 08:29
Adding an extra flag seems like the sensible thing to do for 3.10

Longer term, we should decouple immutability from whether something is a heap type.
I don't know why we would care that it is a heap type at all. Which bit of memory it happens to sit in seems irrelevant to anything but the GC.

Erland, could you turn your patch into PR?
msg391585 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-22 08:36
> Erland, could you turn your patch into PR?

Certainly, but despite the issue title, this issue mentions all types that have been converted to heap types. Should we apply the new immutable flag to _all_ heap types in the stdlib?

Guido:
> I would like this type (and other types that have been or will be converted to heap types) to remain immutable.
msg391595 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-22 12:41
Guido:
> Sorry for making this a deferred blocker. I recall that we had a brief discussion somewhere about an accidental change to the array.array type -- this is now a heap type (Py_TPFLAGS_HEAPTYPE is set), and as a consequence it is no longer immutable.

*Many* static types have been converted to heap types in Python 3.9 and Python 3.10. Is there a rule to decide which types should be mutable or not?

All types implemented in Python are mutable, unless the very few which use slots.

By the way, some cases can be inherited or not. Do we care about that?

Example:

$ python3
Python 3.9.2 (default, Feb 20 2021, 00:00:00) 
>>> def f(): pass
... 
>>> class MyFuncType(type(f)): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type 'function' is not an acceptable base type
msg391596 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-22 12:50
Let me propose a flag name: Py_TPFLAGS_IMMUTABLE.

Py_TPFLAGS_IMMUTABLE implies that setattr(type, name, value) fails. A type has a dictionary, but it cannot be modified with type.__dict__[name] = value, since type.__dict__ returns a read-only mapping proxy.


Currently, the limitation of not being able to modify a built-in type is arbitrary, it's not a technical limitation. It is implemented in type_setattro() which is the default implementation of tp_setattro: PyType_Type.tp_setattro = type_setattro.


Not having Py_TPFLAGS_HEAPTYPE flag implies "immutable". I suggest to add a new Py_TPFLAGS_IMMUTABLE flag and modify PyType_Ready() to use the flag if Py_TPFLAGS_HEAPTYPE is not set:

if (!(flags & Py_TPFLAGS_HEAPTYPE)) {
   flags |= Py_TPFLAGS_IMMUTABLE;
}


You can try with this change:

diff --git a/Objects/typeobject.c b/Objects/typeobject.c
index 254d12cc97..4bd02d40c1 100644
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -3875,13 +3875,6 @@ static int
 type_setattro(PyTypeObject *type, PyObject *name, PyObject *value)
 {
     int res;
-    if (!(type->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
-        PyErr_Format(
-            PyExc_TypeError,
-            "can't set attributes of built-in/extension type '%s'",
-            type->tp_name);
-        return -1;
-    }
     if (PyUnicode_Check(name)) {
         if (PyUnicode_CheckExact(name)) {
             if (PyUnicode_READY(name) == -1)


It becomes possible to modify built-in types:

$ ./python
Python 3.10.0a7+ (heads/master-dirty:cdad2724e6, Apr 22 2021, 14:44:44) [GCC 10.2.1 20201125 (Red Hat 10.2.1-9)] on linux
>>> str.x=1
>>> str.x
1
>>> del str.x

>>> del str.__repr__

>>> del str.__repr__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __repr__
msg391597 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-04-22 13:01
Maybe name it Py_TPFLAGS_IMMUTABLETYPE? Just IMMUTABLE can mean that instances of the type are immutable, but we want to make a type itself immutable.
msg391598 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-04-22 13:21
Is there a full list of types converted to heap types? There may be other issues related to differences between heap and static types.

1. Static type with tp_new = NULL does not have public constructor, but heap type inherits constructor from base class. As result, it allows to create instances without proper initialization, that can lead to crash. It was fixed for few standard heap types in issue23815, then reintroduced, then fixed again in issue42694. But it should be checked for every type without constructor.

2. Static types was not pickleable with protocol 0 and 1 by default. Heap types were pickleable by default, as result, you did not get error when pickle instances of newly converted types, but get an error when try to unpickle. It was fixed in general enough case in issue41052, but it is worth to recheck it for every converted type.
msg391600 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-22 13:34
> Maybe name it Py_TPFLAGS_IMMUTABLETYPE?

"TPFLAGS" stands for "type flags". So IMO adding "TYPE" suffix is redundant. If tomorrow, we want to add a flag for immutable instance, we can add a new Py_TPFLAGS_IMMUTABLE_INSTANCE flag.

On the other side, TYPE suffix is consistent with other flags :-)

/* Set if the type object is dynamically allocated */
#define Py_TPFLAGS_HEAPTYPE (1UL << 9)

/* Set if the type allows subclassing */
#define Py_TPFLAGS_BASETYPE (1UL << 10)
msg391636 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-22 22:18
Victor, I've updated PR 25520 so PyType_Ready always sets Py_TPFLAGS_IMMUTABLE for static types.
msg391701 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-23 15:25
Is there going to be a separate PR to actually *set* the IMMUTABLE flag on all built-in type objects? There are many of those.
msg391720 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-23 18:12
Guido, I’ll prepare a separate PR for all converted built-in types, and you can decide what to do with it when consensus is reached :) There are approx. ~90 of these types. Not all of them are added to their respective module dicts though, but I would add the flag nonetheless, as it simplifies creating and reviewing the patch, and it does not have any performance impact.
msg391728 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-23 19:25
BTW, slightly related, AFAICT:
- https://github.com/python/cpython/blob/e047239eafefe8b19725efffe7756443495cf78b/Objects/typeobject.c#L4620-L4668
- bpo-24912
msg391730 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-23 19:45
I've prepared a diff using grep & sed (see attached patch). Let me know if you want it converted to a PR.

I've excluded the test and the _xx extension modules.
msg391756 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-24 03:56
Does the test suite pass for apply-to-all.diff?

Also, quite a hornet's nest you've uncovered (about __class__ assignment). Would that be fixed better with the IMMUTABLE flag?
msg391816 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-24 22:38
> Does the test suite pass for apply-to-all.diff?

No, multiple tests fail. First test_distutils fails, then during the re-run, test_multiprocessing_forkserver, test_multiprocessing_spawn, and test_pdb fail.

> Also, quite a hornet's nest you've uncovered (about __class__ assignment).

Yes, indeed. Apropos, I see that bpo-24991 is still open.

> Would that be fixed better with the IMMUTABLE flag?

That would be a change of functionality, given that we apply the immutable flag to all built-in types. Currently __class__ assignment is allowed for heap types, and it has been so for many years.

I feel reluctant to add apply-to-all.diff to the PR right now.
msg391846 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-25 09:37
The more I read about these issues, the more I feel reluctant to apply PR 25520. Why change the behaviour/traits of heap types without a proper discussion (or PEP)? Applying this PR feels like an arbitrary change. All the related issues and mailing list discussions seems to end without consensus, and fundamental questions (what is an immutable type? which types should be immutable? why is it a problem that a type is mutable?) seems to be avoided all the time.

And, as Victor points out in msg391596 (and which has also been pointed out by others in other discussions):
> Currently, the limitation of not being able to modify a built-in type is arbitrary, it's not a technical limitation

FWIW #1, in pypy3, datetime.timedelta.foo = 1 is ok; in python3 (3.7-3.10) it's not.

FWIW #2, in Python 3.9, functools.partialmethod is implemented in Python, and functools.partial is implemented in C as a static type:
$ python3.9
>>> import functools
>>> functools.partial.foo = 1  # is this a problem?
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't set attributes of built-in/extension type 'functools.partial'
>>> functools.partialmethod.foo = 1  # is this a problem?


If I'm only bringing noise into the discussion, feel free to remove me from the nosy list.
msg391866 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-25 18:37
My main concern is that types that were immutable in previous Python versions shouldn't become mutable as a surprise side effect of making them heap types. I don't know which types have become mutable this way though.

My other concern is that the language design *intentionally* disallowed mutating built-in types (unlike some other languages that allow it, e.g. Ruby). Mutating built-in types is one of those "attractive nuisance" anti-patterns where at a small scale this often appears to be the quickest way to solve a problem, but it tends to break unrelated things in larger-scale  applications (when different libraries using such tricks collide).

(There's also a concern about mutating types that are shared between multiple interpreters, but IIUC heap types are not shared, so this shouldn't be a problem.)

Presumably we should review the list of heap types that you are proposing to make immutable (in a form more easily digestible by humans than a diff) and reach agreement on that. And perhaps the list should include information on when a type became a heap type. (Types that were always heap types probably needn't be changed.)
msg391867 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-25 18:42
Thanks for the background info, Guido! I'll prepare a list. Should we continue the discussion on Discourse or python-dev?
msg391868 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-25 18:45
Let's post the list here and post a brief mention of this issue on
python-dev.
msg391895 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-26 10:24
> Let's post the list here and post a brief mention of this issue on
python-dev.

Attached. The list contains commits, commit dates, affected files, and the name of the PyType_Spec variables (I _can_ resolve these to the actual type names, but I figured this would be ok for now).

I've also posted the list on Discsourse bco. readability. I'll post a notification on python-dev as well.

https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-types/8403
msg391901 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-04-26 11:12
I also opened https://bugs.python.org/issue43916 to track some points raised by Serhiy
msg391918 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-26 13:06
> No, multiple tests fail. First test_distutils fails, then during the re-run, test_multiprocessing_forkserver, test_multiprocessing_spawn, and test_pdb fail.

Can you provide the error output log you're getting? I'm getting a lot of errors for a lot of tests by applying your patch. But the test_pdb error looks related. If test_pdb fails then all the tests after that also fail. I'm not sure if they are related at all.
msg391922 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-26 13:18
> Can you provide the error output log you're getting?

I don't think we should use more time on apply-to-all.diff, since it's probably not going to be applied as it is anyway.
msg391930 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-04-26 13:40
I'm elevating this as a release blocker since this is probably going to involve a moderately big change and we don't want people relying on the new behaviour when we don't intend to.
msg391932 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-04-26 13:44
I think it is safer to merge apply-to-all.diff, and revert the changes for individual types if we have reasons to make them mutable.

Correspondingly, for all converted heap types we should set tp_new = NULL unless they have special tp_new implementation.
msg391933 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2021-04-26 13:44
Could you please land the new flag and typeobject.c code now? I'm happy to take care of "my" code myself.
msg391935 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-26 13:49
> Could you please land the new flag and typeobject.c code now?

I've only got two more questions before I mark it ready for review, and that's regarding Guido's comment in msg391756:
Should the new flag also take care of __class__ assignment, or should we leave that out?
Are there other places where !Py_TPFLAGS_HEAPTYPE is used where we would like to use the immutable flag?

> I'm happy to take care of "my" code myself.

No problem, I'll leave it out of the patch :)
msg391938 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-26 13:58
> I think it is safer to merge apply-to-all.diff, and revert the changes for individual types if we have reasons to make them mutable.

I don't think it's a good idea though. About 10 or 8 tests are failing if apply-to-all.diff is applied. The tests that are not related to it are also failing because of it. After test_pdb fails a segfault error occurs and the remaining tests are never executed. If we want to merge apply-to-all.diff then we need to make some modifications first.
msg391946 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-04-26 16:13
These types were immutable before. If merely making them immutable again makes tests failing then perhaps there is something wrong with these tests or there are other bugs which are needed to be fixed.
msg391947 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-26 16:41
> If merely making them immutable again makes tests failing then perhaps there is something wrong with these tests or there are other bugs which are needed to be fixed.

I've noticed that the test_pdb fails because it expected the a class method to have the __repr__ "some func" but it got "bound method some func at 0x0000000". This may be the affect of this apply-to-all.diff. Other tests failing were actually fixed in other issues but somehow apply-to-all.diff is suddenly triggering them I think. The most fatal test failures is the test_pdb and test_logging because after those tests failed there were some unexpected behaviors like other tests were executed randomly, segfault and most prominent is that they started compiling by themselves! These are the two tests we should really look into right now.
msg391954 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-26 17:24
> > Could you please land the new flag and typeobject.c code now?
>
> I've only got two more questions before I mark it ready for review,
> and that's regarding Guido's comment in msg391756:
> Should the new flag also take care of __class__ assignment,
> or should we leave that out?

Let's leave that out.
It's a separate can of worms and someone else can  look into it later.

> Are there other places where !Py_TPFLAGS_HEAPTYPE is used
> where we would like to use the immutable flag?

Again, I think we can do that later.

So I am in favor of landing your (small) patch that introduces the flag now.

I also think you should try to separately land small patches that add the IMMUTABLETYPE flag to a few very public types, e.g. array.array and the three in _sre (which are exported by re.py).

We can then look into the test failures with a little less time pressure.
msg391959 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-26 17:55
No problem, will do!
msg391960 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-26 18:15
PS. Don't wait for me. I'm going on vacation this Thursday and won't be
back until well after the 3.10b1 release is done, and before I go I'm
pretty busy already.
msg391963 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-26 18:29
@serhiy.storchaka I have no idea what's causing the errors I described in https://bugs.python.org/msg391947. I looked at all the changes in apply-to-all.diff and I don't think any of the errors are related. Do you have any thoughts about this problem? Is it even reproducible?

(I'm attaching a diff combining the patch.diff and apply-to-all.diff together in one file.)
msg391964 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-26 18:30
The solution would be bisection -- apply half of the changes from
apply-to-all, and see if you still get the errors. Etc.
msg391971 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-26 19:25
> The solution would be bisection -- apply half of the changes from
apply-to-all, and see if you still get the errors. Etc.

Getting the same error. These are the errors :-

0:12:14 load avg: 0.92 [115/426] test_distutils
test test_distutils crashed -- Traceback (most recent call last):
  File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 282, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
  File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 229, in _runtest_inner2
    the_module = importlib.import_module(abstest)
  File "C:\github\cpython\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 881, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "C:\github\cpython\lib\test\test_distutils.py", line 15, in <module>
    import distutils.tests
  File "C:\github\cpython\lib\contextlib.py", line 140, in __exit__
    next(self.gen)
  File "C:\github\cpython\lib\test\support\warnings_helper.py", line 179, in _filterwarnings
    raise AssertionError("filter (%r, %s) did not catch any warning" %
AssertionError: filter ('The distutils package is deprecated', DeprecationWarning) did not catch any warning



0:19:05 load avg: 0.07 [212/426/1] test_logging
--- Logging error ---
Traceback (most recent call last):
  File "C:\github\cpython\lib\logging\handlers.py", line 74, in emit
    self.doRollover()
  File "C:\github\cpython\lib\logging\handlers.py", line 179, in doRollover
    self.rotate(self.baseFilename, dfn)
  File "C:\github\cpython\lib\logging\handlers.py", line 117, in rotate
    self.rotator(source, dest)
  File "C:\github\cpython\lib\test\test_logging.py", line 5222, in rotator
    os.rename(source, dest + ".rotated")
FileExistsError: [WinError 183] Cannot create a file when that file already exists: 'C:\\Users\\shrey\\AppData\\Local\\Temp\\test_logging-2-lh2g0lpt.log' -> 'C:\\Users\\shrey\\AppData\\Local\\Temp\\test_logging-2-lh2g0lpt.log.1.test.rotated'
Call stack:
  File "C:\github\cpython\lib\runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\github\cpython\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\github\cpython\lib\test\__main__.py", line 2, in <module>
    main()
  File "C:\github\cpython\lib\test\libregrtest\main.py", line 719, in main
    Regrtest().main(tests=tests, **kwargs)
  File "C:\github\cpython\lib\test\libregrtest\main.py", line 641, in main
    self._main(tests, kwargs)
  File "C:\github\cpython\lib\test\libregrtest\main.py", line 694, in _main
    self.run_tests()
  File "C:\github\cpython\lib\test\libregrtest\main.py", line 521, in run_tests
    self.run_tests_sequential()
  File "C:\github\cpython\lib\test\libregrtest\main.py", line 423, in run_tests_sequential
    result = runtest(self.ns, test_name)
  File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 194, in runtest
    return _runtest(ns, test_name)
  File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 154, in _runtest
    result = _runtest_inner(ns, test_name,
  File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 282, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
  File "C:\github\cpython\lib\test\libregrtest\runtest.py", line 246, in _runtest_inner2
    test_runner()
  File "C:\github\cpython\lib\test\support\__init__.py", line 682, in inner
    return func(*args, **kwds)
  File "C:\github\cpython\lib\test\test_logging.py", line 5503, in test_main
    support.run_unittest(*tests)
  File "C:\github\cpython\lib\test\support\__init__.py", line 1082, in run_unittest
    _run_suite(suite)
  File "C:\github\cpython\lib\test\support\__init__.py", line 959, in _run_suite
    result = runner.run(suite)
  File "C:\github\cpython\lib\test\support\testresult.py", line 169, in run
    test(self.result)
  File "C:\github\cpython\lib\unittest\suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "C:\github\cpython\lib\unittest\suite.py", line 122, in run
    test(result)
  File "C:\github\cpython\lib\unittest\suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "C:\github\cpython\lib\unittest\suite.py", line 122, in run
    test(result)
  File "C:\github\cpython\lib\unittest\case.py", line 652, in __call__
    return self.run(*args, **kwds)
  File "C:\github\cpython\lib\unittest\case.py", line 592, in run
    self._callTestMethod(testMethod)
  File "C:\github\cpython\lib\unittest\case.py", line 549, in _callTestMethod
    method()
  File "C:\github\cpython\lib\test\test_logging.py", line 5229, in test_namer_rotator_inheritance
    rh.emit(self.next_rec())


0:26:02 load avg: 0.46 [250/426/1] test_pdb
test test_pdb failed -- Traceback (most recent call last):
  File "C:\github\cpython\lib\doctest.py", line 2205, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test.test_pdb.test_pdb_issue_20766
  File "C:\github\cpython\lib\test\test_pdb.py", line 1270, in test_pdb_issue_20766

----------------------------------------------------------------------
File "C:\github\cpython\lib\test\test_pdb.py", line 1282, in test.test_pdb.test_pdb_issue_20766
Failed example:
    with PdbTestInput(['continue',
                       'continue']):
        test_function()
Expected:
    > <doctest test.test_pdb.test_pdb_issue_20766[0]>(6)test_function()
    -> print('pdb %d: %s' % (i, sess._previous_sigint_handler))
    (Pdb) continue
    pdb 1: <built-in function default_int_handler>
    > <doctest test.test_pdb.test_pdb_issue_20766[0]>(5)test_function()
    -> sess.set_trace(sys._getframe())
    (Pdb) continue
    pdb 2: <built-in function default_int_handler>
Got:
    > <doctest test.test_pdb.test_pdb_issue_20766[0]>(6)test_function()
    -> print('pdb %d: %s' % (i, sess._previous_sigint_handler))
    (Pdb) continue
    pdb 1: <bound method Pdb.sigint_handler of <pdb.Pdb object at 0x0000025D07BD5950>>
    > <doctest test.test_pdb.test_pdb_issue_20766[0]>(5)test_function()
    -> sess.set_trace(sys._getframe())
    (Pdb) continue
    pdb 2: <bound method Pdb.sigint_handler of <pdb.Pdb object at 0x0000025D07BD5950>>
msg391993 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-26 22:21
So keep cutting in half until the error disappears?
msg392029 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-27 06:31
I ran the test suite without the changes and they still fail. Therefore apply-to-all.diff does not have any bug at all. But the test failures are also a major issue not only for this change but also for others. I'm opening a new issue for those test failures.

(apply-to-all.diff is outdated because Erlend changed the flag name from Py_TPFLAGS_IMMUTABLE to Py_TPFLAGS_IMMUTABLETYPE in the PR. I'm attaching the modified apply-to-all.diff)
msg392038 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-27 07:55
Re-running the failed tests doesn't trigger the errors but running the whole test suite does. And some errors I described are fixed in any of the last 22 commits and PRs. Therefore should we actually look into this matter or should we leave it as it is?
msg392076 - (view) Author: Guido van Rossum (Guido.van.Rossum) Date: 2021-04-27 14:23
Pablo, there seems to be some instability in the tests.

Shreyan, Erlend, maybe merging in master would help?
msg392079 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-27 14:38
I've not seen any failing tests for GH-25653 on the CI or on my computer.

The PR is based off of 1b1f9852bda85c01ef124858f293e9c13e04ffce, which is pretty recent. I can rebase onto master, but I don't see any need for it as long as the tests suite passes and there's no conflicts.
msg392080 - (view) Author: Guido van Rossum (Guido.van.Rossum) Date: 2021-04-27 14:40
Sure. What do you think is causing the failures for Shreyan then? (Are you
two collaborating?)
-- 
--Guido (mobile)
msg392083 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-04-27 14:47
> Pablo, there seems to be some instability in the tests.

Apart from the typical test_asyncio random timeouts I don't see anything on the buildbots or the CI. What are those failing test? Maybe I can try to reproduce on my side
msg392085 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-27 15:01
Let me re-run the test suite again and see if the tests have been fixed in the most recent commits.
msg392086 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-27 15:06
Shreyan, are you running the tests against the PR, or something else? Have you tried make clean (or git clean -fdx)?
msg392087 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-27 15:08
> Are you two collaborating?

No, but any help is of course appreciated.
msg392088 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-27 15:12
> Shreyan, are you running the tests against the PR, or something else? Have you tried make clean (or git clean -fdx)?

I always have a clean branch checked out but the last time I ran the tests it was unsuccessful. I'm re-running the tests now and hoping that the tests will be successful this time. However lot of tests have been fixed.
msg392089 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-27 15:36
> I've not seen any failing tests for GH-25653 on the CI or on my computer.

That would be GH-25520. GH-25653 is the slightly related issue/PR. Both are passing CI, though.
msg392092 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-27 15:52
Re-running tests complete. I'm attaching the results. If the errors are not reproducible then please tell. I'll then rebuild and rerun the tests once more.
msg392098 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-27 16:03
I don't think I've ever successfully managed to complete the test on my
Windows 10 box either (not even in "production" mode -- you seem to be
using debug mode). I recommend using creating a new PR and having the CI
machinery run the tests. It's more reliable that way.
msg392101 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-27 16:18
There are no errors in apply-to-all.diff because I've ran the tests both with and without the changes and both give me the same output. It's safe to proceed with apply-to-all.diff. The only problem is why are the tests failing at all? I ran the tests a few days earlier on this machine only (Windows 10) and it was successful then.
msg392103 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-27 16:56
Since, these changes and the test failures are not related to each other at all, I'm opening a new issue addressing the test failures only. I'm adding everyone in this issue's nosy to the new issue's nosy as well.
msg392105 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-27 17:08
See issue https://bugs.python.org/issue43955 for the test failures.
msg392236 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-28 16:48
Was EVPtype_spec in _hashopenssl.c converted to heap type?
msg392237 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-28 17:00
See msg391933, Shreyan. I think Christian will take care of his types :)
msg392238 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-28 17:02
New changeset 3b52c8d66b25415f09478ab43f93d59a3547dc13 by Erlend Egeberg Aasland in branch 'master':
bpo-43908: Add Py_TPFLAGS_IMMUTABLETYPE flag (GH-25520)
https://github.com/python/cpython/commit/3b52c8d66b25415f09478ab43f93d59a3547dc13
msg392240 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-28 17:58
Is it necessary to add tests just for testing type immutability? We don't have immutability tests for static types then why heap types?
msg392247 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-04-28 19:06
> We don't have immutability tests for static types then why heap types?

Because all static types are immutable, and some have been converted to heap types changing the contract, therefore is a regression and therefore we need regression tests for those.
msg392248 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-28 19:09
Erlend, wouldn't it be easy to apply all the changes in 1 PR?
msg392250 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-28 19:43
Shreyan, see msg391954 earlier in this thread:
"I also think you should try to separately land small patches that add the IMMUTABLETYPE flag to a few very public types, e.g. array.array and the three in _sre (which are exported by re.py)."
msg392251 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-28 19:46
ok.
msg392262 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2021-04-28 22:05
I am not sure tests are needed here. Immutability of the type is mainly an implementation detail. We keep the types immutable because we don't want users to use the feature of mutating these types. I don't think anything bad will happen if in some Python implementation some of these types are Python classes and are mutable. It is not easy to make a Python class immutable. Users will not intentionally write a code depending on mutability of these types because it does not work in CPython.
msg392263 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-04-28 22:14
> Immutability of the type is mainly an implementation detail

I kindly disagree and based on the title of this issue I think more people have a similar opinion.
msg392264 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-04-28 22:18
In any case, that's my personal opinion of course.

What we should do is decide collectively if immutability is defined behaviour. If we decide that it is, we need regression tests. If we define that as "nice to have" but ultimately "implementation-defined" we don't.

In any case, I would argue that having tests is good and allow us to know when the behaviour flips without people intending it to, like what happened in this case.
msg392283 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-29 06:47
New changeset 5daf70b22e72ea1a88c05975f69120b8c4e4927f by Erlend Egeberg Aasland in branch 'master':
bpo-43908: Make re types immutable (GH-25697)
https://github.com/python/cpython/commit/5daf70b22e72ea1a88c05975f69120b8c4e4927f
msg392284 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-29 06:47
New changeset c6ad03fddf4b04c60dca4327140e59fb2dcca8e5 by Erlend Egeberg Aasland in branch 'master':
bpo-43908: Make array.array type immutable (GH-25696)
https://github.com/python/cpython/commit/c6ad03fddf4b04c60dca4327140e59fb2dcca8e5
msg392285 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-29 07:01
The types converted to heap types in 3.10 are different from 3.9 therefore just backporting wouldn't help. Should we now try to apply the flags on other types? If yes then I'd like to volunteer to apply the flags on the types converted in 3.9.
msg392286 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-29 08:19
> BTW, slightly related, AFAICT:
> - https://github.com/python/cpython/blob/e047239eafefe8b19725efffe7756443495cf78b/Objects/typeobject.c#L4620-L4668
> - bpo-24912

object_set_class() must be changed to check for Py_TPFLAGS_IMMUTABLETYPE flag, rather than Py_TPFLAGS_HEAPTYPE.

Erlend: Do you want to write such change?
msg392287 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-29 08:20
> Erlend: Do you want to write such change?

Sure, I'll have a go at it. Thanks.
msg392288 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-29 08:26
New changeset 5bd0619533ed6587ce76402e9b0b118eb4d4dd09 by Victor Stinner in branch 'master':
bpo-43908: Document Static Types in the C API (GH-25710)
https://github.com/python/cpython/commit/5bd0619533ed6587ce76402e9b0b118eb4d4dd09
msg392311 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-29 14:05
check_set_special_type_attr() must also be updated to check for Py_TPFLAGS_IMMUTABLETYPE flag.
msg392312 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-29 14:15
> Erlend: Do you want to write such change?

Erlend created bpo-43973 and PR 25714.
msg392314 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-29 14:21
> check_set_special_type_attr() must also be updated to check for Py_TPFLAGS_IMMUTABLETYPE flag.

Ok, lets just use this issue for the PR. I can fix it in an hour or so.
msg392316 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-29 14:27
> https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-types/8403

In the past, I used _random.Random for manual tests to compare static type and heap types, check which one is mutable.

C type _random.Random is inherited by Python type random.Random which is mutable. Since _random.Random is not directly seen by developers, I don't think that it's worth it to make it immutable.

For the other types, I would not say that they are "built-in types" or that it would be really bad to modify them. I would say that for the other types, the "We are consenting adults" rule stands. You can hack a type for a very specific need, but in this case you are on your own.

For example, people love to hack AST. Maybe the fact that ast.AST became mutable in Python 3.9 will unlock some crazy hack?
msg392318 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-29 14:59
check_set_special_type_attr() is used to prevent setting the following attributes:

* __name__
* __qualname__
* __module__
* __bases__
* __doc__

Right now, I cannot set the attribues on array.array type:

$ ./python
Python 3.10.0a7+ (heads/debug_doc2-dirty:0623fdb60d, Apr 29 2021, 12:06:18)
>>> import array

>>> array.array.__name__ = 'newname'
TypeError: can't set attributes of built-in/extension type 'array.array'

>>> array.array.__qualname__ = 'newname'
TypeError: can't set attributes of built-in/extension type 'array.array'

>>> array.array.__module__ = 'new module'
TypeError: can't set attributes of built-in/extension type 'array.array'

>>> array.array.__bases__ = (int,)
TypeError: can't set attributes of built-in/extension type 'array.array'

>>> array.array.__doc__ = 'doc'
TypeError: can't set attributes of built-in/extension type 'array.array'

I guess that type_setattro() is used and it checks for Py_TPFLAGS_IMMUTABLETYPE flag early.
msg392324 - (view) Author: Guido van Rossum (Guido.van.Rossum) Date: 2021-04-29 16:11
That is as intended, right?

On Thu, Apr 29, 2021 at 07:59 STINNER Victor <report@bugs.python.org> wrote:

>
> STINNER Victor <vstinner@python.org> added the comment:
>
> check_set_special_type_attr() is used to prevent setting the following
> attributes:
>
> * __name__
> * __qualname__
> * __module__
> * __bases__
> * __doc__
>
> Right now, I cannot set the attribues on array.array type:
>
> $ ./python
> Python 3.10.0a7+ (heads/debug_doc2-dirty:0623fdb60d, Apr 29 2021, 12:06:18)
> >>> import array
>
> >>> array.array.__name__ = 'newname'
> TypeError: can't set attributes of built-in/extension type 'array.array'
>
> >>> array.array.__qualname__ = 'newname'
> TypeError: can't set attributes of built-in/extension type 'array.array'
>
> >>> array.array.__module__ = 'new module'
> TypeError: can't set attributes of built-in/extension type 'array.array'
>
> >>> array.array.__bases__ = (int,)
> TypeError: can't set attributes of built-in/extension type 'array.array'
>
> >>> array.array.__doc__ = 'doc'
> TypeError: can't set attributes of built-in/extension type 'array.array'
>
> I guess that type_setattro() is used and it checks for
> Py_TPFLAGS_IMMUTABLETYPE flag early.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue43908>
> _______________________________________
>
-- 
--Guido (mobile)
msg392325 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2021-04-29 16:12
I don’t think we’re waiting for more crazy hacks.

On Thu, Apr 29, 2021 at 07:27 STINNER Victor <report@bugs.python.org> wrote:

>
> STINNER Victor <vstinner@python.org> added the comment:
>
> >
> https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-types/8403
>
> In the past, I used _random.Random for manual tests to compare static type
> and heap types, check which one is mutable.
>
> C type _random.Random is inherited by Python type random.Random which is
> mutable. Since _random.Random is not directly seen by developers, I don't
> think that it's worth it to make it immutable.
>
> For the other types, I would not say that they are "built-in types" or
> that it would be really bad to modify them. I would say that for the other
> types, the "We are consenting adults" rule stands. You can hack a type for
> a very specific need, but in this case you are on your own.
>
> For example, people love to hack AST. Maybe the fact that ast.AST became
> mutable in Python 3.9 will unlock some crazy hack?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue43908>
> _______________________________________
>
-- 
--Guido (mobile)
msg392389 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-30 07:59
Py_TPFLAGS_IMMUTABLETYPE has been applied to array.array by Erlend in https://github.com/python/cpython/pull/25696. Should Py_TPFLAGS_IMMUTABLETYPE be applied to other heap types also (the ones that were converted from static types)?
msg392402 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-30 10:01
Victor:
> check_set_special_type_attr() is used to prevent setting the following attributes:
> [...]
> Right now, I cannot set the attribues on array.array type:
> [...]
> I guess that type_setattro() is used and it checks for Py_TPFLAGS_IMMUTABLETYPE flag early.

Is this always the case? If so, can we turn the check in check_set_special_type_attr() into an assert? In any case, Py_TPFLAGS_IMMUTABLETYPE should be used, not !Py_TPFLAGS_HEAPTYPE.
msg392403 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-30 10:04
> Is this always the case? If so, can we turn the check in check_set_special_type_attr() into an assert? In any case, Py_TPFLAGS_IMMUTABLETYPE should be used, not !Py_TPFLAGS_HEAPTYPE.

I don't know. In case of doubt, I suggest to only replace !Py_TPFLAGS_HEAPTYPE with Py_TPFLAGS_IMMUTABLETYPE.
msg392407 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-30 10:12
Yep, I agree. From my coverage output, it seems that this branch is never executed. BUT, that may of course be because there's no test that exercises this branch.
msg392408 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-30 10:34
Hum, another function should be updated. Do you want to propose a fix Erlend?

static int
type_set_annotations(PyTypeObject *type, PyObject *value, void *context)
{
    if (!(type->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
        PyErr_Format(PyExc_TypeError, "can't set attributes of built-in/extension type '%s'", type->tp_name);
        return -1;
    }
msg392409 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-30 10:36
I just found it myself :) pushing out the PR now!
msg392410 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-30 10:39
Included in GH-25743
msg392413 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-30 10:45
See also bpo-24912 "The type of cached objects is mutable".
msg392416 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-30 11:05
PyStdPrinter_Type implements tp_new, but tp_init always fail:

static int
stdprinter_init(PyObject *self, PyObject *args, PyObject *kwds)
{
    PyErr_SetString(PyExc_TypeError,
                    "cannot create 'stderrprinter' instances");
    return -1;
}

Maybe it should use the Py_TPFLAGS_IMMUTABLETYPE flag instead?

Instances must be created with PyFile_NewStdPrinter() which doesn't use tp_new nor tp_init.

Erlend: do you want to propose a PR?
msg392420 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-30 11:28
https://docs.python.org/dev/c-api/typeobj.html#Py_TPFLAGS_IMMUTABLETYPE says:
"This bit is set for type objects that are immutable: type attributes cannot be set nor deleted."

Is it possible that a metatype (type subtype) overrides tp_setattro and ignores the Py_TPFLAGS_IMMUTABLETYPE flag? Should we suggest that metatypes implemented in C and overridding tp_setattro should take the Py_TPFLAGS_IMMUTABLETYPE flag in account?

When a type overrides tp_setattro, I understand that it's fine since it's only used to set attributes of its instances, not on the type itself.

--

See also bpo-43770 "Rework C types initialization": some types explicitly sets explicitly tp_setattro to PyObject_GenericSetAttr. But it's unrelated since it's used to set attributes of type instances.
msg392421 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-30 11:35
Erlend: would you mind to document the new Py_TPFLAGS_IMMUTABLETYPE flag in the C API section of What's New in Python 3.10?
https://docs.python.org/dev/whatsnew/3.10.html#c-api-changes

In "New Features", something like:

* Add a new :c:data:`Py_TPFLAGS_IMMUTABLETYPE` type flag to (...).
  (Contributed by xxx in :issue:`43908`.)

And in the "Porting to Python 3.10", I don't know if we should suggest reviewing metatypes implemented in C which overrides tp_setattro, to take the new flag in account.

Maybe explain that Py_TPFLAGS_IMMUTABLETYPE should now be checked to decide if a type is mutable or not, rather than relying on Py_TPFLAGS_HEAPTYPE.
msg392422 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-04-30 11:46
Yes, I’ll have a look at it this afternoon. (On mobile now.)
msg392430 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-30 13:25
New changeset 64141382ecbad665d5738ff26d15505f3427c724 by Erlend Egeberg Aasland in branch 'master':
bpo-43908: check_set_special_type_attr() checks Py_TPFLAGS_IMMUTABLETYPE (GH-25743)
https://github.com/python/cpython/commit/64141382ecbad665d5738ff26d15505f3427c724
msg392439 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-30 14:19
Currently, 4 types are declared with Py_TPFLAGS_IMMUTABLETYPE explicitly:

* array.array
* re.Pattern
* re.Match
* _sre.SRE_Scanner
msg392440 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-30 14:19
Moreover, all static types get the Py_TPFLAGS_IMMUTABLETYPE flag automatically. For example, "./python -c pass" initializes 196 immutable static types:

* ArithmeticError
* AssertionError
* AttributeError
* BaseException
* BlockingIOError
* BrokenPipeError
* BufferError
* BytesWarning
* ChildProcessError
* ConnectionAbortedError
* ConnectionError
* ConnectionRefusedError
* ConnectionResetError
* DeprecationWarning
* EOFError
* EncodingMap
* EncodingWarning
* Exception
* FileExistsError
* FileNotFoundError
* FloatingPointError
* FutureWarning
* GeneratorExit
* ImportError
* ImportWarning
* IndentationError
* IndexError
* InterpreterID
* InterruptedError
* IsADirectoryError
* KeyError
* KeyboardInterrupt
* LookupError
* MemoryError
* ModuleNotFoundError
* NameError
* NoneType
* NotADirectoryError
* NotImplementedError
* NotImplementedType
* OSError
* OverflowError
* PendingDeprecationWarning
* PermissionError
* ProcessLookupError
* PyCapsule
* RecursionError
* ReferenceError
* ResourceWarning
* RuntimeError
* RuntimeWarning
* StopAsyncIteration
* StopIteration
* SyntaxError
* SyntaxWarning
* SystemError
* SystemExit
* TabError
* TimeoutError
* Token.MISSING
* TypeError
* UnboundLocalError
* UnicodeDecodeError
* UnicodeEncodeError
* UnicodeError
* UnicodeTranslateError
* UnicodeWarning
* UnraisableHookArgs
* UserWarning
* ValueError
* Warning
* ZeroDivisionError
* _contextvars.Context
* _contextvars.ContextVar
* _contextvars.Token
* _io.BufferedRWPair
* _io.BufferedRandom
* _io.BufferedReader
* _io.BufferedWriter
* _io.BytesIO
* _io.FileIO
* _io.IncrementalNewlineDecoder
* _io.StringIO
* _io.TextIOWrapper
* _io._BufferedIOBase
* _io._BytesIOBuffer
* _io._IOBase
* _io._RawIOBase
* _io._TextIOBase
* _thread._ExceptHookArgs
* anext_awaitable
* async_generator
* async_generator_asend
* async_generator_athrow
* async_generator_wrapped_value
* asyncgen_hooks
* bool
* builtin_function_or_method
* builtin_method
* bytearray
* bytearray_iterator
* bytes
* bytes_iterator
* callable_iterator
* cell
* classmethod
* classmethod_descriptor
* code
* collections.OrderedDict
* complex
* coroutine
* coroutine_wrapper
* dict
* dict_itemiterator
* dict_items
* dict_keyiterator
* dict_keys
* dict_reverseitemiterator
* dict_reversekeyiterator
* dict_reversevalueiterator
* dict_valueiterator
* dict_values
* ellipsis
* enumerate
* fieldnameiterator
* filter
* float
* formatteriterator
* frame
* frozenset
* function
* generator
* getset_descriptor
* hamt
* hamt_array_node
* hamt_bitmap_node
* hamt_collision_node
* instancemethod
* int
* items
* iterator
* keys
* list
* list_iterator
* list_reverseiterator
* longrange_iterator
* managedbuffer
* map
* mappingproxy
* member_descriptor
* memoryview
* method
* method-wrapper
* method_descriptor
* module
* moduledef
* object
* odict_items
* odict_iterator
* odict_keys
* odict_values
* pickle.PickleBuffer
* property
* range
* range_iterator
* reversed
* set
* set_iterator
* signal.struct_siginfo
* slice
* staticmethod
* stderrprinter
* str
* str_iterator
* super
* symtable entry
* sys.flags
* sys.float_info
* sys.hash_info
* sys.int_info
* sys.thread_info
* sys.version_info
* time.struct_time
* traceback
* tuple
* tuple_iterator
* type
* types.GenericAlias
* types.SimpleNamespace
* types.Union
* values
* weakcallableproxy
* weakproxy
* weakref
* wrapper_descriptor
* zip
msg392441 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-30 14:26
Victor, the types, that Py_TPFLAGS_IMMUTABLETYPE flag is yet to be applied to, are different for 3.9 and 3.10. Should we proceed with that? (If yes I'd be happy to collaborate with Erlend to apply the flag on those types.)
msg392443 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-04-30 14:29
> Victor, the types, that Py_TPFLAGS_IMMUTABLETYPE flag is yet to be applied to, are different for 3.9 and 3.10. Should we proceed with that? (If yes I'd be happy to collaborate with Erlend to apply the flag on those types.)

Please don't change the behavior in the 3.9 stable branch.
msg392445 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-30 14:43
Ok
msg392446 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-04-30 14:43
Ok
msg392488 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2021-04-30 18:01
I am decreasing the priority of this to deferred blocker since https://bugs.python.org/issue43916 is mostly fixed
msg392638 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2021-05-01 21:00
What's the plan for heap type exceptions? PyErr_NewException() and PyErr_NewExceptionWithDoc() doesn't accept flags.
msg392670 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2021-05-02 07:47
New changeset 91554e4c5ca3c762998296522f854a7166ba84f0 by Christian Heimes in branch 'master':
bpo-43908: Mark ssl, hash, and hmac types as immutable (GH-25792)
https://github.com/python/cpython/commit/91554e4c5ca3c762998296522f854a7166ba84f0
msg392671 - (view) Author: Shreyan Avigyan (shreyanavigyan) * Date: 2021-05-02 08:04
Should I apply the flags on other newly converted heap types?
msg392693 - (view) Author: Erlend E. Aasland (erlendaasland) * (Python triager) Date: 2021-05-02 12:48
Victor:
> And in the "Porting to Python 3.10", I don't know if we should suggest reviewing metatypes implemented in C which overrides tp_setattro, to take the new flag in account.

I don't know either; perhaps someone else could chime in here. I've added a draft of a minimal What's New (PR comin' up in a few seconds).
History
Date User Action Args
2021-05-02 12:49:12erlendaaslandsetpull_requests: + pull_request24502
2021-05-02 12:48:15erlendaaslandsetmessages: + msg392693
2021-05-02 08:04:06shreyanavigyansetmessages: + msg392671
2021-05-02 07:47:48christian.heimessetmessages: + msg392670
2021-05-01 21:00:10christian.heimessetmessages: + msg392638
2021-05-01 20:16:18christian.heimessetpull_requests: + pull_request24482
2021-04-30 18:01:15pablogsalsetpriority: release blocker -> deferred blocker

messages: + msg392488
2021-04-30 14:43:58shreyanavigyansetmessages: + msg392446
2021-04-30 14:43:44shreyanavigyansetmessages: + msg392445
2021-04-30 14:29:26vstinnersetmessages: + msg392443
2021-04-30 14:26:44shreyanavigyansetmessages: + msg392441
2021-04-30 14:19:37vstinnersetmessages: + msg392440
2021-04-30 14:19:18vstinnersetmessages: + msg392439
2021-04-30 13:25:50vstinnersetmessages: + msg392430
2021-04-30 11:46:11erlendaaslandsetmessages: + msg392422
2021-04-30 11:35:11vstinnersetmessages: + msg392421
2021-04-30 11:28:38vstinnersetmessages: + msg392420
2021-04-30 11:05:25vstinnersetmessages: + msg392416
2021-04-30 10:45:04vstinnersetmessages: + msg392413
2021-04-30 10:39:27erlendaaslandsetmessages: + msg392410
2021-04-30 10:36:33erlendaaslandsetmessages: + msg392409
2021-04-30 10:34:53vstinnersetmessages: + msg392408
2021-04-30 10:13:04erlendaaslandsetpull_requests: + pull_request24433
2021-04-30 10:12:03erlendaaslandsetmessages: + msg392407
2021-04-30 10:04:57vstinnersetmessages: + msg392403
2021-04-30 10:01:21erlendaaslandsetmessages: + msg392402
2021-04-30 07:59:25shreyanavigyansetmessages: + msg392389
2021-04-29 16:12:40gvanrossumsetmessages: + msg392325
title: array.array and re types must be immutable: add Py_TPFLAGS_IMMUTABLETYPE flag -> array.array should remain immutable: add Py_TPFLAGS_IMMUTABLETYPE flag
2021-04-29 16:11:00Guido.van.Rossumsetmessages: + msg392324
2021-04-29 14:59:29vstinnersetmessages: + msg392318
2021-04-29 14:27:57vstinnersettitle: array.array should remain immutable: add Py_TPFLAGS_IMMUTABLETYPE flag -> array.array and re types must be immutable: add Py_TPFLAGS_IMMUTABLETYPE flag
2021-04-29 14:27:39vstinnersetmessages: + msg392316
2021-04-29 14:21:36erlendaaslandsetmessages: + msg392314
2021-04-29 14:15:43vstinnersetmessages: + msg392312
2021-04-29 14:14:53vstinnersettitle: array.array should remain immutable -> array.array should remain immutable: add Py_TPFLAGS_IMMUTABLETYPE flag
2021-04-29 14:05:27vstinnersetmessages: + msg392311
2021-04-29 09:38:48erlendaaslandsetpull_requests: + pull_request24404
2021-04-29 08:26:37vstinnersetmessages: + msg392288
2021-04-29 08:20:26erlendaaslandsetmessages: + msg392287
2021-04-29 08:19:27vstinnersetmessages: + msg392286
2021-04-29 07:47:04vstinnersetpull_requests: + pull_request24399
2021-04-29 07:01:25shreyanavigyansetmessages: + msg392285
2021-04-29 06:47:54vstinnersetmessages: + msg392284
2021-04-29 06:47:18vstinnersetmessages: + msg392283
2021-04-28 22:18:11pablogsalsetmessages: + msg392264
2021-04-28 22:14:16pablogsalsetmessages: + msg392263
2021-04-28 22:05:27serhiy.storchakasetmessages: + msg392262
2021-04-28 19:46:24shreyanavigyansetmessages: + msg392251
2021-04-28 19:43:42erlendaaslandsetmessages: + msg392250
2021-04-28 19:09:30shreyanavigyansetmessages: + msg392248
2021-04-28 19:06:14pablogsalsetmessages: + msg392247
2021-04-28 17:58:46shreyanavigyansetmessages: + msg392240
2021-04-28 17:07:51erlendaaslandsetpull_requests: + pull_request24387
2021-04-28 17:07:08erlendaaslandsetpull_requests: + pull_request24386
2021-04-28 17:02:50vstinnersetmessages: + msg392238
2021-04-28 17:00:52erlendaaslandsetmessages: + msg392237
2021-04-28 16:48:21shreyanavigyansetmessages: + msg392236
2021-04-27 17:08:03shreyanavigyansetmessages: + msg392105
2021-04-27 16:56:16shreyanavigyansetmessages: + msg392103
2021-04-27 16:18:17shreyanavigyansetmessages: + msg392101
2021-04-27 16:03:33gvanrossumsetmessages: + msg392098
2021-04-27 15:52:27shreyanavigyansetfiles: + tests_log.txt

messages: + msg392092
2021-04-27 15:36:20erlendaaslandsetmessages: + msg392089
2021-04-27 15:12:32shreyanavigyansetmessages: + msg392088
2021-04-27 15:08:09erlendaaslandsetmessages: + msg392087
2021-04-27 15:06:19erlendaaslandsetmessages: + msg392086
2021-04-27 15:01:55shreyanavigyansetmessages: + msg392085
2021-04-27 14:47:09pablogsalsetmessages: + msg392083
2021-04-27 14:40:44Guido.van.Rossumsetmessages: + msg392080
2021-04-27 14:38:33erlendaaslandsetmessages: + msg392079
2021-04-27 14:23:19Guido.van.Rossumsetnosy: + Guido.van.Rossum
messages: + msg392076
2021-04-27 07:55:51shreyanavigyansetmessages: + msg392038
2021-04-27 06:31:30shreyanavigyansetfiles: + apply-to-all.diff

messages: + msg392029
2021-04-26 22:21:09gvanrossumsetmessages: + msg391993
2021-04-26 19:25:43shreyanavigyansetmessages: + msg391971
2021-04-26 18:39:09shreyanavigyansetfiles: - patch.diff
2021-04-26 18:30:52gvanrossumsetmessages: + msg391964
2021-04-26 18:29:18shreyanavigyansetfiles: + patch.diff

messages: + msg391963
2021-04-26 18:15:53gvanrossumsetmessages: + msg391960
2021-04-26 17:55:58erlendaaslandsetmessages: + msg391959
2021-04-26 17:24:45gvanrossumsetmessages: + msg391954
2021-04-26 16:41:52shreyanavigyansetmessages: + msg391947
2021-04-26 16:13:27serhiy.storchakasetmessages: + msg391946
2021-04-26 13:58:19shreyanavigyansetmessages: + msg391938
2021-04-26 13:49:52erlendaaslandsetmessages: + msg391935
2021-04-26 13:44:46christian.heimessetnosy: + christian.heimes
messages: + msg391933
2021-04-26 13:44:36serhiy.storchakasetmessages: + msg391932
2021-04-26 13:40:49pablogsalsetpriority: deferred blocker -> release blocker

messages: + msg391930
2021-04-26 13:18:08erlendaaslandsetmessages: + msg391922
2021-04-26 13:06:53shreyanavigyansetmessages: + msg391918
2021-04-26 11:35:07serhiy.storchakasetmessages: - msg391902
2021-04-26 11:34:11serhiy.storchakasetmessages: + msg391902
2021-04-26 11:12:57pablogsalsetnosy: + pablogsal
messages: + msg391901
2021-04-26 10:24:34erlendaaslandsetfiles: + list.txt

messages: + msg391895
2021-04-26 08:01:47shreyanavigyansetnosy: + shreyanavigyan
2021-04-25 18:45:51gvanrossumsetmessages: + msg391868
2021-04-25 18:42:16erlendaaslandsetmessages: + msg391867
2021-04-25 18:37:47gvanrossumsetmessages: + msg391866
2021-04-25 09:37:40erlendaaslandsetmessages: + msg391846
2021-04-24 22:38:50erlendaaslandsetmessages: + msg391816
2021-04-24 03:56:43gvanrossumsetmessages: + msg391756
2021-04-23 19:49:28erlendaaslandsetfiles: + apply-to-all.diff
2021-04-23 19:49:19erlendaaslandsetfiles: - apply-to-all.diff
2021-04-23 19:45:04erlendaaslandsetfiles: + apply-to-all.diff

messages: + msg391730
2021-04-23 19:25:46erlendaaslandsetmessages: + msg391728
2021-04-23 18:12:51erlendaaslandsetmessages: + msg391720
2021-04-23 15:25:48gvanrossumsetmessages: + msg391701
2021-04-22 22:18:58erlendaaslandsetmessages: + msg391636
2021-04-22 13:34:12vstinnersetmessages: + msg391600
2021-04-22 13:21:35serhiy.storchakasetmessages: + msg391598
2021-04-22 13:01:03serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg391597
2021-04-22 12:50:52vstinnersetmessages: + msg391596
2021-04-22 12:41:17vstinnersetmessages: + msg391595
2021-04-22 08:54:00erlendaaslandsetstage: patch review
pull_requests: + pull_request24238
2021-04-22 08:36:10erlendaaslandsetmessages: + msg391585
2021-04-22 08:29:47Mark.Shannonsetmessages: + msg391584
2021-04-22 08:20:29erlendaaslandsetfiles: + patch.diff
keywords: + patch
messages: + msg391582
2021-04-22 07:24:58erlendaaslandsetnosy: + erlendaasland
2021-04-22 06:46:09shihai1991setmessages: + msg391578
2021-04-21 21:01:06vstinnersetnosy: + corona10, shihai1991
components: + Library (Lib)
2021-04-21 18:54:21gvanrossumsetnosy: + Mark.Shannon
2021-04-21 18:52:19gvanrossumcreate