[issue32604] [subinterpreters] PEP 554 implementation: add interpreters module

2020-06-16 Thread Eric Snow


Eric Snow  added the comment:

@Pablo, yeah, I'll try to take a look this week.  Are these new failures?

Keep in mind that these tests can sometimes expose existing bugs in our runtime 
(as we fix runtime issues elsewhere) rather than regressions, though that isn't 
necessarily the case here. :)

--

___
Python tracker 
<https://bugs.python.org/issue32604>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32604] [subinterpreters] PEP 554 implementation: add interpreters module

2020-06-16 Thread Eric Snow


Eric Snow  added the comment:


New changeset 818f5b597ae93411cc44e404544247d436026a00 by Eric Snow in branch 
'master':
bpo-32604: Clean up test.support.interpreters. (gh-20926)
https://github.com/python/cpython/commit/818f5b597ae93411cc44e404544247d436026a00


--

___
Python tracker 
<https://bugs.python.org/issue32604>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32604] [subinterpreters] PEP 554 implementation: add interpreters module

2020-06-16 Thread Eric Snow


Change by Eric Snow :


--
pull_requests: +20105
pull_request: https://github.com/python/cpython/pull/20926

___
Python tracker 
<https://bugs.python.org/issue32604>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39075] types.SimpleNamespace should preserve attribute ordering (?)

2020-05-15 Thread Eric Snow


Change by Eric Snow :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue39075>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40572] Support basic asynchronous cross-interpreter operations.

2020-05-08 Thread Eric Snow


Change by Eric Snow :


--
keywords: +patch
pull_requests: +19323
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/20012

___
Python tracker 
<https://bugs.python.org/issue40572>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40572] Support basic asynchronous cross-interpreter operations.

2020-05-08 Thread Eric Snow


New submission from Eric Snow :

(This is a continuation of the work from bpo-33608.  That issue ended up with a 
lot of baggage and clutter (due to problems that have since been resolved), so 
we closed it.  This issue is where we're picking it up fresh.)

When two interpreters are cooperating, there are sometimes operations that one 
of them needs the other to perform.  Thus far this is limited to mutation or 
release of data/objects owned by that "other" interpreter.  We need safe, 
reliable public C-API to facilitate such operations.

All the necessary machinery already exists ("pending calls"), exposed in the 
internal C-API: _Py_AddPendingCall().  (There is a public Py_AddPendingCall(), 
but it should be removed.)  That API adds a function to a per-interpreter 
queue, from which it is executed later (asynchronously) by the ceval loop of 
the interpreter's main thread.  The challenge is that the repercussions of such 
async operations within the eval loop are not fully explored.  We have some 
confidence because this is the same machinery used to handle signals.  However, 
it's better avoid as much complexity in those async operations as possible.  
That is why we don't just expose `_Py_AddPendingCall()` in the public C-API.

Instead the plan is to add a small number of public C-API functions that are 
each specific to a focused use case, ideally with with little/no chance of 
errors or other side effects.  Initially we will target `Py_DECREF()`, 
`PyMem_Free()`, and `PyBuffer_Release()`.  If we need more then we can assess 
those needs later.

--
assignee: eric.snow
components: C API
messages: 368476
nosy: eric.snow, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Support basic asynchronous cross-interpreter operations.
type: enhancement
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40572>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32604] Expose the subinterpreters C-API in Python for testing use.

2020-05-07 Thread Eric Snow


Eric Snow  added the comment:


New changeset a1d9e0accd33af1d8e90fc48b34c13d7b07dcf57 by Eric Snow in branch 
'master':
bpo-32604: [_xxsubinterpreters] Propagate exceptions. (GH-19768)
https://github.com/python/cpython/commit/a1d9e0accd33af1d8e90fc48b34c13d7b07dcf57


--

___
Python tracker 
<https://bugs.python.org/issue32604>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40533] Subinterpreters: don't share Python objects between interpreters

2020-05-06 Thread Eric Snow


Eric Snow  added the comment:

Yep, before per-interpreter GIL is official we must get to the point where *no* 
PyObject objects are shared.

Making PyObject.ob_refcnt atomic until then (only as part of the experiment) 
should be fine.

--

___
Python tracker 
<https://bugs.python.org/issue40533>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40058] Running test_datetime twice fails with: module 'datetime' has no attribute '_divide_and_round'

2020-05-06 Thread Eric Snow


Eric Snow  added the comment:

FYI, with the following additions in Lib/test/test_datetime.py...

   before = set(sys.modules)
   try:
   pure_tests = import_fresh_module(TESTS, fresh=['datetime', '_strptime'],
 blocked=['_datetime'])
   _pure = set(sys.modules)
   fast_tests = import_fresh_module(TESTS, fresh=['datetime',
  '_datetime', '_strptime'])
   _fast = set(sys.modules)
   print(f'added (pure): {sorted(_pure-before)}')
   print(f'added (fast): {sorted(_fast-before)}')
   print('---')
   finally:
  ...

I get the following output running "./python -m test test_datetime 
test_datetime":

   0:00:00 load avg: 0.52 Run tests sequentially
   0:00:00 load avg: 0.52 [1/2] test_datetime
   added (pure): ['_decimal', '_strptime', '_testcapi', 'decimal', 'numbers', 
'test.datetimetester']
   added (fast): ['_decimal', '_strptime', '_testcapi', 'decimal', 'numbers', 
'test.datetimetester']
   ---
   0:00:05 load avg: 0.52 [2/2] test_datetime
   added (pure): ['_datetime', '_strptime', 'datetime']
   added (fast): ['_datetime', '_strptime', 'datetime']
   ---
   [snipped]

That definitely tells a story. :)  Unfortunately, for now I don't have any more 
time to investigate.  Sorry.

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue40058>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40514] Add --experimental-isolated-subinterpreters build option

2020-05-05 Thread Eric Snow


Eric Snow  added the comment:

It would probably make sense to remove the build option in the 3.9 release.  We 
can leave it in master, but remove it in the 3.9 branch once it has been 
created.

--

___
Python tracker 
<https://bugs.python.org/issue40514>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40010] Inefficient signal handling in multithreaded applications

2020-05-05 Thread Eric Snow


Eric Snow  added the comment:

Good catch on this, Victor.  Thanks for doing it.

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue40010>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40513] Move _PyRuntimeState.ceval to PyInterpreterState

2020-05-05 Thread Eric Snow


Eric Snow  added the comment:

If this issue covers the GIL (which it seems to) then I'd expect 
_PyRuntimeState.gilstate to be handled here too.

--

___
Python tracker 
<https://bugs.python.org/issue40513>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40513] Move _PyRuntimeState.ceval to PyInterpreterState

2020-05-05 Thread Eric Snow


Eric Snow  added the comment:

>From a user perspective, does it make sense to have a different 
>recursion_limit per interpreter?  I don't see a problem with it.  However, 
>does it make sense to also keep a global value that we default to when a 
>per-interpreter value is not set?  I think it might.

I suppose a bigger question is what users will expect the recursion limit (AKA 
"sys.getrecursionlimit()") to be for a newly created subinterpreter.  Will it 
be some global default?  Will it be the value from the parent interpreter?  I'd 
go with a global default, which would imply that the default value should be 
stored under _PyRuntimeState like we had it (but still keep the actual 
per-interpreter field for the actual value).

FWIW, the existing docs don't really block either approach.

--

___
Python tracker 
<https://bugs.python.org/issue40513>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40513] Move _PyRuntimeState.ceval to PyInterpreterState

2020-05-05 Thread Eric Snow


Eric Snow  added the comment:

FWIW, I think it would make sense to keep "signals_pending" under 
_PyRuntimeState rather than moving it to PyInterpreterState.

Signals are only handled by the main interpreter (in its main thread).  Even 
though "signals_pending" is useful to only one interpreter in the runtime, 
making it per-interpreter sends the wrong message that it is significant at 
that level.  This may be confusing to readers of the code.

At the very least there should be a clear comment with the field in 
Include/internal/pycore_interp.h explaining how it is only used by the main 
interpreter and why we made it per-interpreter anyway.

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue40513>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38880] Subinterpreters: List interpreters associated with a channel end

2020-05-01 Thread Eric Snow


Eric Snow  added the comment:

Thanks again, Lewis!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue38880>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40390] Implement _xxsubinterpreters.channel_send_wait().

2020-05-01 Thread Eric Snow


Eric Snow  added the comment:

Thanks for working on this, Ben!  FWIW, I've put up a separate PR to 
demonstrate how I was thinking we would solve this:  
https://github.com/python/cpython/pull/19829.

--

___
Python tracker 
<https://bugs.python.org/issue40390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40350] modulefinder chokes on numpy - dereferencing None in spec.loader

2020-05-01 Thread Eric Snow


Eric Snow  added the comment:

Ah, namespace packages. :)  Yeah, the code is not taking the "spec.loader is 
None" case into account.  I expect the fix would be to add handling of that 
case a few lines up in the code, right after handling BuiltinImporter and 
FrozenImporter.  Offhand I'm not sure if the "type" should be _PKG_DIRECTORY or 
some new one just for namespace packages.  How does imp.find_module() (on which 
modulefinder._find_module() is based) respond to namespace packages?

[1] 
https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.loader

--
nosy: +barry, brett.cannon, eric.smith, eric.snow

___
Python tracker 
<https://bugs.python.org/issue40350>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40350] modulefinder chokes on numpy - dereferencing None in spec.loader

2020-05-01 Thread Eric Snow


Change by Eric Snow :


--
stage:  -> test needed
versions: +Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40350>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40417] PyImport_ReloadModule emits deprecation warning

2020-05-01 Thread Eric Snow


Eric Snow  added the comment:

Did you have a need for this to be fixed in 3.8 or earlier?  This seems 
reasonably and simple enough to backport.  I suppose someone could be relying 
on an implicit import of the "imp" module, but that seems highly unlikely and 
suspect anyway. :)

--
nosy: +brett.cannon, ncoghlan

___
Python tracker 
<https://bugs.python.org/issue40417>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40417] PyImport_ReloadModule emits deprecation warning

2020-05-01 Thread Eric Snow


Eric Snow  added the comment:

Yeah, that looks like an oversight.  I've approved your PR.  Thanks!

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue40417>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40453] Add PyConfig._isolated_interpreter: isolated subinterpreters

2020-05-01 Thread Eric Snow


Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue40453>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32604] Expose the subinterpreters C-API in Python for testing use.

2020-04-30 Thread Eric Snow


Change by Eric Snow :


--
pull_requests: +19149
pull_request: https://github.com/python/cpython/pull/19829

___
Python tracker 
<https://bugs.python.org/issue32604>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32604] Expose the subinterpreters C-API in Python for testing use.

2020-04-28 Thread Eric Snow


Change by Eric Snow :


--
pull_requests: +19090
pull_request: https://github.com/python/cpython/pull/19770

___
Python tracker 
<https://bugs.python.org/issue32604>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40390] Implement _xxsubinterpreters.channel_send_wait().

2020-04-28 Thread Eric Snow


Eric Snow  added the comment:

Thanks, Ben.  I'll take a look.

--
components: +Library (Lib) -C API
title: Implement a C API for channel_send_wait for subinterpreters. -> 
Implement _xxsubinterpreters.channel_send_wait().

___
Python tracker 
<https://bugs.python.org/issue40390>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32604] Expose the subinterpreters C-API in Python for testing use.

2020-04-28 Thread Eric Snow


Change by Eric Snow :


--
pull_requests: +19088
pull_request: https://github.com/python/cpython/pull/19768

___
Python tracker 
<https://bugs.python.org/issue32604>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40360] Deprecate lib2to3 (and 2to3) for future removal

2020-04-22 Thread Eric Snow


Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue40360>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37266] Daemon threads must be forbidden in subinterpreters

2020-04-08 Thread Eric Snow


Eric Snow  added the comment:

I've opened bpo-40234 to address backward incompatibility from this
change (e.g. affecting mod-wsgi).

--

___
Python tracker 
<https://bugs.python.org/issue37266>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40234] Disallow daemon threads in subinterpreters optionally.

2020-04-08 Thread Eric Snow


New submission from Eric Snow :

In bpo-37266 we strictly disallowed creation of daemon threads in 
subinterpreters.  However, this is backward-incompatible for existing users of 
the subinterpreter C-API (such as mod-wsgi).

Rather than reverting that change I suggest that we make it opt-in through the 
interpreter config.  That would preserve backward-compatibility.  It would also 
make it so we can disallow daemon threads in subinterpreters created through 
PEP 554.  We could also deprecate use of daemon threads in *all* 
subinterpreters, with the goal of dropping support after a while.

--
components: Interpreter Core
messages: 366029
nosy: eric.snow, grahamd, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Disallow daemon threads in subinterpreters optionally.
type: behavior
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40234>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2020-04-08 Thread Eric Snow


Eric Snow  added the comment:

> I close this issue with a complex history.
>
> If someone wants to continue to work on this topic, please open an issue with 
> a very clear description of what should be done and how it is supposed to be 
> used.

Yeah, there is more to do.  I'll create a new issue.

--

___
Python tracker 
<https://bugs.python.org/issue33608>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40077] Convert static types to PyType_FromSpec()

2020-04-08 Thread Eric Snow


Eric Snow  added the comment:

> Wouldn't having less static types slow down startup time?

FWIW, I've been considering an approach where the main interpreter
keeps using static types but subinterpreters use heap types.  If it
isn't too much effort (or too hacky) then it might be a sufficient
solution for now.

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue40077>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2020-03-27 Thread Eric Snow


Eric Snow  added the comment:

FYI, in bpo-39984 Victor moved pending calls to PyInterpreterState, which was 
part of my reverted change.  However, there are a few other pieces of that 
change that need to be applied before this issue is resolved.  I'm not sure 
when I'll get to it, but hopefully soon.

--

___
Python tracker 
<https://bugs.python.org/issue33608>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39984] Move pending calls from _PyRuntime to PyInterpreterState

2020-03-27 Thread Eric Snow


Eric Snow  added the comment:

Awesome!  Thanks for doing this, Victor.  I'll take a look when I can and 
adjust the changes for bpo-33608.  If you'll recall, I made a similar change as 
part of the solution for that issue, which we later reverted due to problems we 
discovered with daemon threads during runtime finalization.

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue39984>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39829] __len__ called twice in the list() constructor

2020-03-09 Thread Eric Snow


Eric Snow  added the comment:

I'm not opposed. :)  I just don't want to impose on your time.

--
assignee:  -> pablogsal
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

___
Python tracker 
<https://bugs.python.org/issue39829>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39829] __len__ called twice in the list() constructor

2020-03-09 Thread Eric Snow


Eric Snow  added the comment:

FWIW, I encouraged Kim to file this.  Thanks Kim!

While it isn't part of any specification, it is an unexpected change in 
behavior that led to some test failures.  So I figured it would be worth 
bringing up. :)  I did find it surprising that we were not caching the result, 
but don't think that's necessarily a problem.

All that said, the change did not actually break anything other than some tests 
(not the code they were testing).  So I don't have a problem with closing this.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue39829>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37497] Add inspect.Signature.from_text().

2020-03-06 Thread Eric Snow


Eric Snow  added the comment:

Honestly, I don't recall exactly the concrete use case for which I opened this. 
:)  I *think* it was related to applying a more restrictive signature onto an 
existing function (e.g. with a decorator).

--

___
Python tracker 
<https://bugs.python.org/issue37497>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17422] language reference should specify restrictions on class namespace

2020-03-06 Thread Eric Snow


Eric Snow  added the comment:

Thanks for fixing that, Caleb!

FWIW, I've opened a separate issue (#39879) for adding a note in the language 
reference about dict ordering.  Sorry for the confusion.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue17422>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39879] Update language reference to specify that dict is insertion-ordered.

2020-03-06 Thread Eric Snow


New submission from Eric Snow :

As of 3.7 [1], dict is guaranteed to preserve insertion order:

  the insertion-order preservation nature of dict
  objects has been declared to be an official part
  of the Python language spec.

However, at least one key part of the language reference [2] was not updated to 
reflect this:  "3.2. The standard type hierarchy" > "Mappings" > "Dictionaries".

Note that the library docs [3] *were* updated.


[1] https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights
[2] https://docs.python.org/3/reference/datamodel.html#index-30
[3] https://docs.python.org/3/library/stdtypes.html#typesmapping

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 363533
nosy: docs@python, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Update language reference to specify that dict is insertion-ordered.
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39879>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33234] Improve list() pre-sizing for inputs with known lengths

2020-03-02 Thread Eric Snow


Eric Snow  added the comment:

Possible backward incompatibility caused by this issue: issue39829

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue33234>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17422] language reference should specify restrictions on class namespace

2020-02-27 Thread Eric Snow


Eric Snow  added the comment:

Thanks for working on this.  Sorry I didn't get a chance to see your PR sooner. 
 There was one small thing that needs to be changed back, as I implied in my 
comment on the PR [1].  Please undo the change in the text from "ordered 
mapping" to "dict".

The original "is initialised as an empty ordered mapping" text line should be 
restored.  "dict" is currently still not correct (the language spec does not 
dictate that dict be ordered).  However, PEP 520 specifies that it must be 
ordered.

Thanks!


[1] https://github.com/python/cpython/pull/18559#pullrequestreview-366098695

--
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.4, Python 3.5

___
Python tracker 
<https://bugs.python.org/issue17422>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

2020-02-07 Thread Eric Snow


Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue1635741>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

2020-02-04 Thread Eric Snow


Eric Snow  added the comment:

> This is pretty much one of the two approaches I have been considering.

The other approach is to leave the current static singletons alone and
only use them for the main interpreter.  Each subinterpreter would get
its own copy, created when that interpreter is initialized.

--

___
Python tracker 
<https://bugs.python.org/issue39511>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

2020-02-04 Thread Eric Snow


Eric Snow  added the comment:

On Sun, Feb 2, 2020 at 3:32 PM Raymond Hettinger  wrote:
> Random idea (not carefully thought-out):  Would it be simpler to have these 
> objects just
> ignore their refcount by having dealloc() be a null operation or having it 
> set the refcount
> back to a positive number).  That would let sub-interpreters share the 
> objects without
> worrying about race-conditions on incref/decref operations.

This is pretty much one of the two approaches I have been considering. :)

Just to be clear, singletons normally won't end up with a refcount of
0, by design.  However, if there's a incref race between two
interpreters (that don't share a GIL) then you *can* end up triggering
dealloc (via Py_DECREF) and even get negative refcounts (which cause
Py_FatalError() on debug builds).  Here are some mitigations:

* (as noted above) make dealloc() for singletons a noop
* (as noted above) in dealloc() set the refcount back to some positive value
* make the initial refcount sufficiently large such that it is
unlikely to reach 0 even with races
* incref each singleton once during each interpreter initiialization
(and decref once during interp. finalization)

We would have to special-case refleak checks for singletons, to avoid
false positives.

Also note that currently extension authors (and CPython contributors)
can rely on the runtime to identify when then accidentally
incref/decref a singleton too much (or forget to do so).  So it may
make sense to do something in the "singleton dealloc()" in debug
builds to provide similar checks.

>  To make this work, the objects can register themselves as permanent, shared, 
> objects;
> then, during shutdown, we could explicitly call a hard dealloc on those 
> objects.

great point

--

___
Python tracker 
<https://bugs.python.org/issue39511>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

2020-02-04 Thread Eric Snow


Eric Snow  added the comment:

On Sun, Feb 2, 2020 at 2:53 PM Raymond Hettinger  wrote:
> Is the sub-interpreter PEP approved?

PEP 554 is not approved yet (and certainly is not guaranteed, though
I'm hopeful).  However, that PEP is exclusively about exposing
subinterpreters in the stdlib.

There is no PEP for the effort to isolate subinterpreters and stop
sharing the GIL between them.  We are not planning on having such a
PEP since the actual proposal is so basic ("make the GIL
per-interpreter") and there has been no controversy.

I need to do a better job about communicating the difference, as folks
keep conflating PEP 554 with the effort to stop sharing the GIL
between subinterpreters.  Note that both are part of my "multi-core
Python" project. [1]

> If not, I had thought the plan was to only
> implement PRs that made clean-ups that would have been necessary anyway.

Right.  In this case the "cleanup" is how singletons are finalized
when the runtime shuts down.  This has a material impact on projects
that embed the CPython runtime.  Currently runtime finalization is a
mess.

That said, making the singletons per-interpreter isn't a prerequisite
of that cleanup.  For specific case of the per-interpreter GIL world,
we just need an approach that addresses their life cycle in a
thread-safe way.

[1] https://github.com/ericsnowcurrently/multi-core-python

--

___
Python tracker 
<https://bugs.python.org/issue39511>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37224] test__xxsubinterpreters fails randomly

2020-02-04 Thread Eric Snow


Eric Snow  added the comment:

Thanks, Kyle.  That helps at least a little. :)

--

___
Python tracker 
<https://bugs.python.org/issue37224>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39516] ++ does not throw a SyntaxError

2020-02-04 Thread Eric Snow


Eric Snow  added the comment:

FWIW, this is the sort of thing that is usually best suited to be reported by 
linters, not the Python runtime.

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue39516>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code

2020-01-29 Thread Eric Snow


Eric Snow  added the comment:

FTR:

As Martin noted in #19514, there isn't any performance difference for statics, 
whether local or global.  For static locals the compiler (at least on linux) 
generates symbols named as ".<#>" and they are treated as global.

One key difference (again, at least on linux; seen using "nm") is that symbols 
for static globals preserve identifying information, like the originating 
source file.  For static locals the filename is not preserved and, when there 
are duplicates, you do not know from which function a particular symbol comes.  
So compiled symbols for static globals are *much* easier to identify in the 
source than symbols for static locals.

Hence static locals complicate something I'm working on: tooling to identify 
global variables in our source code.  So I'm a fan of efforts to remove 
duplicates (and move static locals to the explicit global namespace).  Thank 
you! :)

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue39487>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue15600] expose the finder details used by the FileFinder path hook

2020-01-29 Thread Eric Snow


Eric Snow  added the comment:

I have many other things higher on my todo list. :)  I'll re-open this issue if 
I get back to the project that motivated this (i.e. "source translation via 
import hooks for filename suffix").

--
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue15600>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38076] Make struct module PEP-384 compatible

2020-01-24 Thread Eric Snow


Eric Snow  added the comment:

> there's still probably some underlying issue in multiprocessing.

Whoa, I've never heard that before!  

--

___
Python tracker 
<https://bugs.python.org/issue38076>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39395] The os module should unset() environment variable at exit

2020-01-24 Thread Eric Snow


Eric Snow  added the comment:

FTR, #39376 is related (avoid the process-global env vars in the first place).

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue39395>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39443] Inhomogeneous behaviour for descriptors in between the class-instance and metaclass-class pairs

2020-01-24 Thread Eric Snow


Eric Snow  added the comment:

@Raymond, What do you think about adding a helpful note or two in the docs?

--
nosy: +rhettinger

___
Python tracker 
<https://bugs.python.org/issue39443>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39443] Inhomogeneous behaviour for descriptors in between the class-instance and metaclass-class pairs

2020-01-24 Thread Eric Snow


Eric Snow  added the comment:

First of all, thanks for asking about this.  Everything is working as expected. 
 Let's look at why.

First, be sure the behavior of descriptors is clear: the descriptor protocol is 
only triggered by "dotted access" on an object ("obj.attr").  So you should 
expect it only where you see that syntax used.

Let's look at your examples now.

> FirstClass().descriptor = None

In this case there are 2 dotted accesses.  The first one happens in __init__() 
when the object is created.  The second is the rest of the above line.

> class SecondClass(metaclass=SecondClassMeta):
>descriptor = None
>
> SecondClass.descriptor = None

In this case there is only one dotted access, in that last line.  The object in 
this case is SecondClass and its class is SecondClassMeta.  Unlike with 
FirstClass, the *class* in the second example (SecondClassMeta) does not have a 
__init__() with the dotted access.  Instead there is only the one dotted access 
afterward.  If SecondClassMeta had the same __init__() that FirstClass had then 
you would have seen a second trigger of the descriptor.

It seems you expected assignments (name binding) in the class definition body 
to be treated the same as dotted access.  They are not.  This is because when a 
class definition body is evaluated, the class object does not exist yet.  The 
steps for class creation go like this:

1. figure out the metaclass (by default "type")
2. calls its __prepare__() method to get a namespace
3. execute the class body (like a function) with that namespace as the locals
4. create the class object, passing in that namespace

Python has worked this way since version 2.2 (PEP 252).  See: 
https://docs.python.org/3/reference/datamodel.html#creating-the-class-object

If you want to get clever you could return a namespace object from your 
metaclass __prepare__ that triggers the descriptor protocol as you expected.  
However, I would not recommend that.  Getting clever with metaclasses is best 
avoided.  The default behavior is much simpler.  That won't be changing.

> It looks to me like an undesirable asymmetry between the descriptors 
> behaviour when in classes vs when in metaclasses. Is that intended? If it is, 
> I think it should be highlighted in the descriptors documentation.

Regardless, metaclasses are used infrequently and combining them with 
descriptors (especially relative to class definitions) is even less common.  So 
pointing out the caveats of this case may not be worth the time of all future 
readers of those docs.

That said, clearly it would have helped you in this case. :)  So here are some 
*possible* places to clarify (very briefly):

* descriptors howto
   + about mixing descriptors with metaclasses
   + a list enumerating places where descriptors are *not* invoked
* language reference (metaclasses section)
   + a warning saying something like "Avoid metaclasses if you can help it and 
only use them if you have a clear understanding of Python's object model (and 
dotted access)"
* language reference (descriptors/dotted access section)
   + a list enumerating places where descriptors are *not* invoked

Which of those do you think would have helped you the most?

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue39443>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39376] Avoid modifying the process global environment (not thread safe)

2020-01-17 Thread Eric Snow


Eric Snow  added the comment:

+1

This has impact on subinterpreters once they stop sharing the GIL.  (It's 
already on my list of global resources that need better protection.)

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue39376>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36710] Pass _PyRuntimeState as an argument rather than using the _PyRuntime global variable

2020-01-17 Thread Eric Snow


Eric Snow  added the comment:

Thanks, Victor!

--

___
Python tracker 
<https://bugs.python.org/issue36710>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37224] test__xxsubinterpreters fails randomly

2020-01-17 Thread Eric Snow


Eric Snow  added the comment:

On Wed, Jan 15, 2020 at 12:20 AM Kyle Stanley  wrote:
> As can be seen from the results above, the interpreter is not even running in 
> the first place before
> it's destroyed, so of course destroy() won't raise an RuntimeError. I think 
> this proves that
> interpreters.destroy() is _not_ where we should be focusing our efforts (at 
> least for now). Instead,
> we should first investigate why it's not even running at this point.

Good catch.

> I suspect the issue _might_ be a race condition within the "_running()" 
> context manager that's
> preventing the interpreter from being ran, but I'll have to do some further 
> investigation.

Sounds good.

> Notably, a rather difficult and hard to explain side effect occurred from 
> adding the new assertion.
> [snip]
> But, I have no explanation for this.

Yeah, that sounds a bit strange.  Keep in mind that there have been
other changes in this part of the runtime code, so this might be
related.  Or I suppose it could be a side effect of calling
is_running() (though that definitely should not have side effects).

> do you think it might be worth adding in the changes I made to 
> DestroyTests.test_still_running above?

Yeah, it's a good sanity check on the assumptions made by the test.
Please do open a PR and request a review from me.

--

___
Python tracker 
<https://bugs.python.org/issue37224>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39075] types.SimpleNamespace should preserve attribute ordering (?)

2019-12-27 Thread Eric Snow


Eric Snow  added the comment:

> IMHO, dropping the sort should be a default behavior. If some user need
> this feature, maybe we could supply a param to open the sort function or not?

Consider opening a separate issue (or start a thread on python-ideas)
about adding a more sophisticated implementation to the stdlib's
"reprlib" module.  If you do so then please draw from the
argparse._AttributeHolder implementation.

--

___
Python tracker 
<https://bugs.python.org/issue39075>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39076] Use types.SimpleNamespace for argparse.Namespace

2019-12-27 Thread Eric Snow


Eric Snow  added the comment:

Anyway, this probably isn't a discussion worth extending much further.  I don't 
think it's important enough. :)  So if you have reservations about this then 
feel free to close the issue.

--

___
Python tracker 
<https://bugs.python.org/issue39076>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39076] Use types.SimpleNamespace for argparse.Namespace

2019-12-27 Thread Eric Snow


Eric Snow  added the comment:

Sorry if there was any confusion.  I didn't mean to suggest we get rid
of argparse.Namespace (in favor of SimpleNamespace).  Rather, the
former would subclass the latter.

> * types.SimpleNamespace() sorts attributes, so this would get in the way of 
> issue #39058.

hence issue 39075

> * argparse.Namespace() supports a __contains__() method that isn't offered by 
> types.SimpleNamespace():

As I suggested originally, there isn't any problem here if
argparse.Namespace subclasses SimpleNamespace.

> * Argparse is sensitive to start-up time so we mostly want to avoid adding 
> new dependencies.

I agree on avoiding extra imports.  The simple solution right now is
to use "type(sys.implementation)", though that isn't the clearest
code.

FWIW, this would also be solved if we added SimpleNamespace to the
builtins, but that is a separate discussion. :)

> * The __repr__ for SimpleNamespace() doesn't round-trip and isn't what we 
> have now with Namespace.

We could certainly fix the repr, but that's kind of irrelevant here if
argparse.Namespace is a subclass.

FWIW, this is also resolved if we add SimpleNamespace to the builtins
(as "namespace").

> * Ironically, the class name "Namespace" is simpler than "SimpleNamespace" ;-)

Agreed. :)  We only used that long name because putting it in the
"types" module mean it needed to have an extra clear name.

That said, it is irrelevant here if argparse.Namespace is a subclass

> * Much of the code in argparse.Namespace() inherits from _AttributeHolder, so 
> switching to types.SimpleNamespace() doesn't really save us much code.

Honestly, _AttributeHolder isn't needed.  The only thing it provides
is a nice repr (like SimpleNamespace does), with some extra
functionality for dynamically sorting/filtering down the attrs shown
in the repr.   There are 3 subclasses and Namespace doesn't even use
the attr filtering.  The implementation doesn't seem to warrant a
dedicated base class and it would be simpler for those 2 subclasses to
each to have a dedicated __repr__ implementation (and for Namespace to
subclass SimpleNamespce), rather than to subclass _AttributeHolder.
Subclassing from _AttributeHolder gives the illusion that there is
something more going on there than there actually is.

Aside from that, there's the weaker argument about consistency and
avoiding duplication (i.e. SimpleNamespace is the canonical "simple"
namespace implementation in Python).  Also, if SimpleNamespace had
existed when argparse was written then I expect it would have been
used instead.

> Are there any upsides to switching?  Attribute lookup is almost equally fast 
> using either approach, so there is no speed benefit:

Yeah, I didn't expect there to much difference in performance.

--

___
Python tracker 
<https://bugs.python.org/issue39076>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26219] implement per-opcode cache in ceval

2019-12-27 Thread Eric Snow


Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue26219>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37340] remove free_list for bound method objects

2019-12-23 Thread Eric Snow


Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue37340>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36476] Runtime finalization assumes all other threads have exited.

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

So I see 3 things to address here:

1. Python daemon threads
2. Python threads created in atexit handlers
3. non-Python threads accessing the C-API

Possible solutions (starting point for discussion):

1. stop them at the point we stop waiting for non-daemon threads (at the 
beginning of finalization)
2. disallow them?  do one more pass of wait-for-threads?
3. cause all (external) attempts to access the C-API to fail once finalization 
begins

Regarding daemon threads, the docs already say "Daemon threads are abruptly 
stopped at shutdown." [1]  So let's force them to stop.  Can we do that?  If we 
*can* simply kill the threads, can we do so without leaking resources?  
Regardless, the mechanism we currently use (check for finalizing each(?) time 
through the eval loop) mostly works fine.  The problem is when C code called 
from Python in a daemon thread blocks long enough that it makes C-API calls (or 
even the eval loop) *after* we've started cleaning up the runtime state.  So if 
there was a way to interrupt that blocking code, that would probably be good 
enough.

The other two possible solutions are, I suppose, a bit more drastic.  What are 
the alternatives?


[1] https://docs.python.org/3/library/threading.html#thread-objects

--
nosy: +nanjekyejoannah, ncoghlan, pablogsal, pitrou, tim.peters, vstinner

___
Python tracker 
<https://bugs.python.org/issue36476>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36476] Runtime finalization assumes all other threads have exited.

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

To put it another way:

(from issue33608#msg358748)

> The docs [1] aren't super clear about it, but there are some fundamental
> assumptions we make about runtime finalization:
>
> * no use of the C-API while Py_FinalizeEx() is executing (except for a
> few helpers like Py_Initialized)
> * only a small portion of the C-API is available afterward (at least
> until Py_Initialize() is run)
>
> I guess the real question is what to do about this?
> 
>[1] https://docs.python.org/3/c-api/init.html#c.Py_FinalizeEx

Adding to that list:

* no other Python threads are running once we start finalizing the runtime (not 
far into Py_FinalizeEx())

--

___
Python tracker 
<https://bugs.python.org/issue36476>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36476] Runtime finalization assumes all other threads have exited.

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

Analysis by @pconnell:

* https://bugs.python.org/issue33608#msg357169
* https://bugs.python.org/issue33608#msg357170
* https://bugs.python.org/issue33608#msg357179

tl;dr daemon threads and external C-API access during/after runtime 
finalization are causing crashes.

--

___
Python tracker 
<https://bugs.python.org/issue36476>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

Thanks for the detailed analysis, Phil.  I think the results are pretty 
conclusive: daemon threads are the worst. :)  But seriously, thanks.

As you demonstrated, it isn't just Python "daemon" threads that cause the 
problem.  It is essentially any external access of the C-API once runtime 
finalization has started.  The docs [1] aren't super clear about it, but there 
are some fundamental assumptions we make about runtime finalization:

* no use of the C-API while Py_FinalizeEx() is executing (except for a few 
helpers like Py_Initialized)
* only a small portion of the C-API is available afterward (at least until 
Py_Initialize() is run)

I guess the real question is what to do about this?

Given that this is essentially a separate problem, let's move further 
discussion and effort over related to sorting out problematic threads to 
#36476, "Runtime finalization assumes all other threads have exited."  @Phil, 
would you mind attaching those same two files to that issue?


[1] https://docs.python.org/3/c-api/init.html#c.Py_FinalizeEx

--

___
Python tracker 
<https://bugs.python.org/issue33608>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36476] Runtime finalization assumes all other threads have exited.

2019-12-20 Thread Eric Snow


Change by Eric Snow :


--
nosy: +pconnell

___
Python tracker 
<https://bugs.python.org/issue36476>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36476] Runtime finalization assumes all other threads have exited.

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

Problems with lingering threads during/after runtime finalization continue to 
be a problem.  I'm going to use this issue as the focal point for efforts to 
resolve this.


Related issues:
* #36479 "Exit threads when interpreter is finalizing rather than runtime."
* #24770 "Py_Finalize() doesn't stop daemon threads"
* #23592 "SIGSEGV on interpreter shutdown, with daemon threads running wild"
* #37127 "Handling pending calls during runtime finalization may cause 
problems."
* #33608 "Add a cross-interpreter-safe mechanism to indicate that an object may 
be destroyed."
* #36818 "Add PyInterpreterState.runtime."
* #36724 "Clear _PyRuntime at exit"
* #14073 "allow per-thread atexit()"
* #1596321 "KeyError at exit after 'import threading' in other thread"
* #37266 "Daemon threads must be forbidden in subinterpreters"
* #31517 "MainThread association logic is fragile"

--

___
Python tracker 
<https://bugs.python.org/issue36476>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24770] Py_Finalize() doesn't stop daemon threads

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

I'm closing this in favor of #36476 "Runtime finalization assumes all other 
threads have exited."

--
nosy: +eric.snow
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Runtime finalization assumes all other threads have exited.
versions: +Python 3.8, Python 3.9 -Python 3.6

___
Python tracker 
<https://bugs.python.org/issue24770>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36476] Runtime finalization assumes all other threads have exited.

2019-12-20 Thread Eric Snow


Change by Eric Snow :


--
stage:  -> needs patch
versions: +Python 3.9 -Python 3.7

___
Python tracker 
<https://bugs.python.org/issue36476>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36476] Runtime finalization assumes all other threads have exited.

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

Adding to the list:

* any OS threads created by an extension module or embedding application

--

___
Python tracker 
<https://bugs.python.org/issue36476>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13077] Unclear behavior of daemon threads on main thread exit

2019-12-20 Thread Eric Snow


Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue13077>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34296] Speed up python startup by pre-warming the vm

2019-12-20 Thread Eric Snow


Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue34296>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31517] MainThread association logic is fragile

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

probably a duplicate: issue #39042 "Use the runtime's main thread ID in the 
threading module."

--

___
Python tracker 
<https://bugs.python.org/issue31517>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue14073] allow per-thread atexit()

2019-12-20 Thread Eric Snow


Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue14073>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28812] Deadlock between GIL and pystate head_mutex.

2019-12-20 Thread Eric Snow


Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue28812>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1332869] Fatal Python error: Interpreter not initialized

2019-12-20 Thread Eric Snow


Change by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue1332869>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1596321] KeyError at exit after 'import threading' in other thread

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

related: issue #39042 "Use the runtime's main thread ID in the threading 
module."

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue1596321>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38918] Add __module__ entry for function type in inspect docs table.

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

Thanks for working on this, @parthsharma2!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue38918>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39042] Use the runtime's main thread ID in the threading module.

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

I don't see a reason not to consider this is a regression.

The only problem with the fix would be for any users that rely on the 
inaccurate reporting of the threading module.  Considering that possibly 
includes only some embedders (and folks using _thread module directly), I 
expect the impact would be extremely small.  A porting entry in the whats-new 
doc.

--
keywords: +3.8regression
priority: normal -> release blocker
stage: test needed -> needs patch
versions: +Python 3.8

___
Python tracker 
<https://bugs.python.org/issue39042>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39110] It seems that list() changes the value of the parameter

2019-12-20 Thread Eric Snow


Eric Snow  added the comment:

Your problem is with UserList.  This is from the implementation:

def __getitem__(self, i):
if isinstance(i, slice):
return self.__class__(self.data[i])
else:
return self.data[i]

So each slice is creating a new Tree.  Then the __setitem__() of that new Tree 
gets triggered for each item, causing the owner to be set to the new Tree.  So 
that's the cause.

Is there a particular reason you are subclassing UserList?  Consider 
subclassing list or collections.abc.MutableSequence instead.  Or deal with the 
slice semantics manually.

Also, perhaps you expected that a slice would produce a view into the sequence? 
 I know that's how it works in some programming languages (but not Python, 
though you could make it do that if you wanted to).

Regardless, as far as I can tell everything is working as designed.  I 
recommend closing this.

--
nosy: +eric.snow
resolution:  -> not a bug
status: open -> pending
versions: +Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39110>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38904] "signal only works in main thread" in main thread

2019-12-17 Thread Eric Snow


Eric Snow  added the comment:

So resolving issue39042 would be enough, particularly if we backported
the change to 3.8?

--

___
Python tracker 
<https://bugs.python.org/issue38904>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39042] Use the runtime's main thread ID in the threading module.

2019-12-17 Thread Eric Snow

Eric Snow  added the comment:

Hmm, I wonder if this should be considered a regression in 3.8.  As 
demonstrated in issue38904, the following code changed behavior as of 3.8, 
under certain conditions:


import signal
import threading

def int_handler():
   ...

if threading.current_thread() == threading.main_thread():
signal.signal(signal.SIGINT, int_handler)


Note the specific conditions:

* threading and signal have not been imported yet
* the current thread when the module is *imported* is not the main thread (this 
only affects folks embedding Python)

Also note that the only other help we offer is a "private" function in the 
C-API: _PyOS_IsMainThread().  That would have given the correct answer, but we 
do not expect users to call it, and it doesn't help them from Python code 
anyway.

Also, the same problem existed pre-3.8 if signal and threading were imported in 
different threads before the above script ran.

Finally, I'm (mostly) confident that this would be a backward-compatible fix.

What do you think about this being a 3.8 regression, Ɓukasz?

--
nosy: +lukasz.langa

___
Python tracker 
<https://bugs.python.org/issue39042>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39058] argparse should preserve argument ordering in Namespace

2019-12-17 Thread Eric Snow


Eric Snow  added the comment:

FWIW, I've also opened issue #39076 about subclassing types.SimpleNamespace.

--

___
Python tracker 
<https://bugs.python.org/issue39058>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39076] Use types.SimpleNamespace for argparse.Namespace

2019-12-17 Thread Eric Snow


New submission from Eric Snow :

types.SimpleNamespace does pretty much exactly the same thing as 
argparse.Namespace.  We should have the latter subclass the former.  I expect 
the only reason that wasn't done before is because SimpleNamespace is newer.

The only thing argparse.Namespace does differently is it supports the 
contains() builtin.  So the subclass would look like this:

class Namespace(types.SimpleNamespace):
"""..."""
def __contains__(self, key):
return key in self.__dict__

Alternately, we could add __contains__() to SimpleNamespace and then the 
subclass would effectively have an empty body.

--
components: Library (Lib)
messages: 358555
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: Use types.SimpleNamespace for argparse.Namespace
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39076>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39075] types.SimpleNamespace should preserve attribute ordering (?)

2019-12-17 Thread Eric Snow


Change by Eric Snow :


--
stage:  -> needs patch

___
Python tracker 
<https://bugs.python.org/issue39075>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39058] argparse should preserve argument ordering in Namespace

2019-12-17 Thread Eric Snow


Eric Snow  added the comment:

> Currently, Namespace() objects sort the attributes in the __repr__.  This is 
> annoying because argument
> order matters and because everywhere else in the module we preserve order 
> (i.e. users see help in the
> order that arguments are added).

Hmm, I was going to suggest switching to types.SimpleNamespace, but
realized we sort that repr too (likely for the same reason).  I've
opened issue #39075 to address that.

In writing up that issue, I considered that a sorted repr can be
useful in some cases.  However, I don't think any of those cases
really apply here.

Anyway, I agree with your conclusion. :)

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue39058>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39075] types.SimpleNamespace should preserve attribute ordering (?)

2019-12-17 Thread Eric Snow


New submission from Eric Snow :

types.SimpleNamespace was added in 3.3 (for use in sys.implementation; see PEP 
421), which predates the change to preserving insertion order in dict.  At the 
time we chose to sort the attributes in the repr, both for ease of reading and 
for a consistent output.

The question is, should SimpleNamespace stay as it is (sorted repr) or should 
it show the order in which attributes were added?

On the one hand, alphabetical order can be useful since it makes it easier for 
readers to find attributes, especially when there are many.  However, for other 
cases it is helpful for the repr to show the order in which attributes were 
added.

FWIW, I favor changing the ordering in the repr to insertion-order.  Either is 
relatively trivial to get after the fact (whether "sorted(vars(ns))" or 
"list(vars(ns))"), so I don't think any folks that benefit from alphabetical 
order will be seriously impacted.

--
components: Interpreter Core
messages: 358553
nosy: eric.snow
priority: normal
severity: normal
status: open
title: types.SimpleNamespace should preserve attribute ordering (?)
type: enhancement
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39075>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37224] test__xxsubinterpreters fails randomly

2019-12-17 Thread Eric Snow


Eric Snow  added the comment:

On Fri, Dec 13, 2019 at 8:08 PM Kyle Stanley  wrote:
> Yeah, I named it "_PyInterpreterIsFinalizing" and it's within 
> Include/cpython. Definitely open
> to suggestions on the name though, it's basically just a private getter for 
> interp->finalizing.

For a struct-specific getter we usually end the prefix with an
underscore: _PyInterpreter_IsFinalizing.  Otherwise, that's the same
name I would have used. :)

> Oh, awesome! In that case, I'll do some more rigorous testing before opening 
> the PR then;
> [snip]
> This might be a bit of a time consuming process, but I should have time in 
> the next week
> or so to work on it.

No worries (or hurries).  Just request a review from me when you're
ready.  Thanks again for working on this!

--

___
Python tracker 
<https://bugs.python.org/issue37224>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

I'm out of time and this deserves some careful discussion.  I'll get to it next 
Friday (or sooner if possible).  Sorry!

--

___
Python tracker 
<https://bugs.python.org/issue33608>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

Sorry for the delay, Phil.  I'll try to take a look in the next couple of hours.

--

___
Python tracker 
<https://bugs.python.org/issue33608>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38904] "signal only works in main thread" in main thread

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

Before 3.8, the "signal" module checked against the thread in which the module 
was initially loaded, treating that thread as the "main" thread.  That same was 
true (and still is) for the "threading" module.  The problem for both modules 
is that the Python runtime may have actually been initialized in a different 
thread, which is the actual "main" thread.

Since Python 3.8 we store the ID of the thread where the runtime is initialized 
and use that in the check the "signal" module does.  However, the "threading" 
module still uses the ID of the thread where it is first imported.  So your 
check against "threading.main_thread()" must be in code that isn't running in 
the same thread where you ran Py_Initialize().  It probably used to work 
because you imported "signal" and "threading" for the first time in the same 
thread.

So what next?

First, I've created issue39042 to address the current different meanings of 
"main thread".  That should resolve the discrepancy between the signal and 
threading modules.

Second, what can we do to help embedders make sure they are running their code 
in the main thread (e.g. when setting signals)?  Is there any C-API we could 
add which would have helped you here?

--
nosy: +eric.snow, vstinner

___
Python tracker 
<https://bugs.python.org/issue38904>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39042] Use the runtime's main thread ID in the threading module.

2019-12-13 Thread Eric Snow


New submission from Eric Snow :

The threading module has a "main_thread()" function that returns a Thread 
instance for the "main" thread.  The main thread is the one running when the 
runtime is initialized and has a specific role in various parts of the runtime. 
 Currently the threading module instead uses the ID of the thread where the 
module is imported for the first time.  Usually this isn't a problem. (perhaps 
only in embedding cases?)

Since 3.8 we store the ID of the thread where the runtime was initialized 
(_PyRuntime.main_thread).  By using this in the threading module we can be 
consistent across the runtime about what the main thread is.

This is particularly significant because in 3.8 we also updated the signal 
module to use _PyRuntime.main_thread (instead of calling 
PyThread_get_thread_ident() when the module is loaded).  See issue38904.

We should also consider backporting this change to 3.8, to resolve the 
difference between the threading and signal modules.

--
components: Library (Lib)
messages: 358362
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: Use the runtime's main thread ID in the threading module.
type: behavior
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39042>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37224] test__xxsubinterpreters fails randomly

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

On Sat, Nov 30, 2019 at 9:23 PM Kyle Stanley  wrote:
> I have a few ideas that I'd like to test out for fixing this failure, and if 
> any of them produce positive results I'll report back.

Sounds good.

> Since the failures are still consistently occurring, I have not yer revised 
> GH-16293. I'll do that when/if I come up with a more thorough solution.

We don't need everything to be fixed in a single PR.  Feel free to
create a PR just for the "finalizing" fix.

--

___
Python tracker 
<https://bugs.python.org/issue37224>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37224] test__xxsubinterpreters fails randomly

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

On Sat, Nov 30, 2019 at 9:23 PM Kyle Stanley  wrote:
> Based on the above hint, I was able to make some progress on a potential 
> solution. Thanks Eric.

That's great!

> Instead of only checking "frame->f_executing", I changed "_is_running()" to 
> also check the
> "finalizing" field of PyInterpreterState. The "finalizing" field is set to 1 
> in "Py_EndInterpreter()",
> so this ensures that an interpreter in the process of being destroyed is 
> considered "running",
> so that operations (such as running scripts, destroying the interpreter, etc) 
> can't occur during
> finalization.

Ah, that makes sense.

> I had to add a private function to the C-API in order to access 
> "interp->finalizing" from
> Modules/_xxsubinterpretersmodule.c due to the struct for PyInterpreterState 
> being internal only.

Yep, it has to use the public C-API just like any other module.  The
function has a "_Py" prefix and be defined in Include/cpython, right?

--

___
Python tracker 
<https://bugs.python.org/issue37224>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37776] Test Py_Finalize() from a subinterpreter

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

On Fri, Dec 13, 2019 at 11:22 AM Lewis Gaul  wrote:
> So it looks like adding a specific testcase for this is likely to weed out an 
> actual issue here!

+1

--

___
Python tracker 
<https://bugs.python.org/issue37776>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38858] new_interpreter() should reuse more Py_InitializeFromConfig() code

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

Thanks for working on this.  It really does have far-reaching benefits, not 
just for the subinterpreter stuff I'm interested in. :)

--

___
Python tracker 
<https://bugs.python.org/issue38858>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36854] GC operates out of global runtime state.

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

On Wed, Dec 4, 2019 at 4:36 AM STINNER Victor  wrote:
> Each time I tried to fix a bug in the Python finalization, I introduced worse 
> bugs :-D

:)

> We cannot fix all bugs at once, we have to work incrementally.

+1

> I like the idea of introducing workarounds specific to subinterpreters: leave 
> the code path for the main interpreter unchanged. It helps to iterate on the 
> code to slowly fix the code.

+1

> I prefer to not open an issue, since the Python finalization is broken is so 
> many ways :-D Anyway, I'm hitting issues on the finalization each time I'm 
> working on subinterpeter changes, so it's hard to forget about it :-)

Sounds good. :)

On Wed, Dec 4, 2019 at 4:39 AM STINNER Victor  wrote:
> I'm a believer that subinterpreters is one of the most realistic solution to 
> make Python faster. I said it in my EuroPython keynote on CPython performance 
> ;-)

Again, thanks for that!

--

___
Python tracker 
<https://bugs.python.org/issue36854>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38962] Reference leaks in subinterpreters

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

Thanks for all the work on this!

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue38962>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1021318] PyThreadState_Next not thread safe

2019-12-13 Thread Eric Snow


Eric Snow  added the comment:

On Wed, Dec 11, 2019 at 7:02 AM STINNER Victor  wrote:
> We may have to fix this API first, and clarify the scope of the different 
> locks.

+1

--

___
Python tracker 
<https://bugs.python.org/issue1021318>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules

2019-11-26 Thread Eric Snow


Eric Snow  added the comment:

Exactly. :)

I'd expect PEP 499 to specify changing __module__ of classes and functions from 
__main__ to the module name (__spec__.name).  This aligns closely with the 
whole point of the PEP. :)  As a bonus, it will simplify things for pickling 
(which doesn't inherently deal well with __main__).

--

___
Python tracker 
<https://bugs.python.org/issue36375>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38918] Add __module__ entry for function type in inspect docs table.

2019-11-26 Thread Eric Snow


New submission from Eric Snow :

The docs page for the inspect module has a large table describing the special 
attributes of various important types.  One entry for function attributes is 
missing: __module__.  It should be added.

Note that __module__ *is* included in the function attributes listed in the 
language reference. [2]

The same goes for the "method" (really "instance method") section of the table: 
it should also have __module__. [3]


[1] https://docs.python.org/3/library/inspect.html#types-and-members
[2] https://docs.python.org/3/reference/datamodel.html#index-34
[3] https://docs.python.org/3/reference/datamodel.html#index-36

--
assignee: docs@python
components: Documentation
keywords: easy, newcomer friendly
messages: 357502
nosy: docs@python, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Add __module__ entry for function type in inspect docs table.
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue38918>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules

2019-11-25 Thread Eric Snow


Eric Snow  added the comment:

FWIW, I have some feedback on the PEP.  (See msg357448.)  Can we discuss here 
or should I open a mailing list thread?

--
nosy: +eric.snow

___
Python tracker 
<https://bugs.python.org/issue36375>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   4   5   6   7   8   9   10   >