[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

2020-06-28 Thread Nick Coghlan


Nick Coghlan  added the comment:

Removing issue assignment, as I'm no longer actively investigating this.

--
assignee: ncoghlan -> 

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



[issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)

2020-06-28 Thread Nick Coghlan


Nick Coghlan  added the comment:

Removing issue assignment, as I'm not actively investigating this.

--
assignee: ncoghlan -> 

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



[issue34206] Move and clarify Py_Main documentation

2020-06-28 Thread Nick Coghlan


Nick Coghlan  added the comment:

Added 3.8 back in to the target versions. However, if the automatic backport 
doesn't work for that branch, I'll probably skip it rather than fixing any 
conflicts.

--
versions: +Python 3.8

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



[issue34206] Move and clarify Py_Main documentation

2020-06-28 Thread Nick Coghlan


Nick Coghlan  added the comment:

Adjusted target versions, as I never previously got around to merging this PR.

--
versions: +Python 3.10, Python 3.9 -Python 3.7, Python 3.8

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



[issue31898] Add a `recommended-packages.txt` file

2020-06-28 Thread Nick Coghlan


Nick Coghlan  added the comment:

Removing the issue assignment, as I'm not actively working on this (although I 
still think it's a reasonable idea).

--
assignee: ncoghlan -> 

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



[issue31899] Ensure backwards compatibility with recommended packages

2020-06-28 Thread Nick Coghlan


Nick Coghlan  added the comment:

Removing the issue assignment, as I'm not actively working on this (although I 
still think it's a reasonable idea).

--
assignee: ncoghlan -> 

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



[issue17490] Improve ast.literal_eval test suite coverage

2020-06-28 Thread Nick Coghlan


Nick Coghlan  added the comment:

Belatedly removing the issue assignment here, as I'm not actively working on 
this.

I've also marked this as an easy newcomer friendly task, as all that's involved 
is taking the `test_ast.py` changes from 
https://bugs.python.org/file29520/issue17490_ast_literal_eval_converters.diff 
and turning them into a test suite PR on GitHub.

--
assignee: ncoghlan -> 
keywords: +easy, newcomer friendly -patch
stage: patch review -> needs patch

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



[issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds

2020-06-28 Thread Nick Coghlan


Nick Coghlan  added the comment:

Belatedly clearing the issue assignment here - while I do still sometimes 
ponder this problem, I haven't been actively working on it since the 2017 core 
sprint where Greg & I made our last serious attempt at trying to improve the 
situation.

Mark's PR at https://github.com/python/cpython/pull/18334 looks very promising 
to me, though - my main request was just to bring over the tests I wrote at the 
2017 core dev sprints, and confirm that the revised eval breaker logic solves 
the issue.

--
assignee: ncoghlan -> 

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



[issue24048] remove_module() needs to save/restore exception state

2020-06-28 Thread Nick Coghlan


Nick Coghlan  added the comment:

Belatedly marking this as resolved.

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

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



[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)

2020-06-17 Thread Nick Coghlan

Nick Coghlan  added the comment:

I'm seeing this as well when attempting to run an optimised Python 3.8 build on 
an old Debian 9 system (with the curses and socket extension modules).

For example:

cpython/Modules/socketmodule.c: In function ‘PyInit__socket’:
cpython/Modules/socketmodule.c:8304:1: error: the control flow of function 
‘PyInit__socket’ does not match its profile data (counter ‘arcs’) 
[-Werror=coverage-mismatch]
cpython/Modules/socketmodule.c:8304:1: error: the control flow of function 
‘PyInit__socket’ does not match its profile data (counter ‘time_profiler’) 
[-Werror=coverage-mismatch]

That said, I did install missing optional dependendencies and then do a 
reconfigure without doing a "make clean", which is pretty dubious.

So David's assessment here sounds good to me: the bug is that "make clean" 
should be removing the intermediate PGO files, but is currently leaving them 
lying around.

--
nosy: +ncoghlan

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



[issue33944] Deprecate and remove code execution in pth files

2020-05-12 Thread Nick Coghlan


Nick Coghlan  added the comment:

While it's still not entirely accurate, I've tweaked the title on the issue to 
refer to the arbitrary code execution behavior.

Getting "Make pth file sys.path modifications easier to debug" in there as well 
would be rather tricky :)

--

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



[issue33944] Deprecate and remove code execution in pth files

2020-05-12 Thread Nick Coghlan


Change by Nick Coghlan :


--
title: Deprecate and remove pth files -> Deprecate and remove code execution in 
pth files

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



[issue28180] Implementation of the PEP 538: coerce C locale to C.utf-8

2020-03-22 Thread Nick Coghlan


Nick Coghlan  added the comment:

The test cases for locale coercion *not* triggering still assume that 
bpo-19977, using surrogateescape on the standard streams in the POSIX locale, 
has been implemented (since that was implemented in Python 3.5).

Hence the various test cases complaining that they found "ascii:strict" (Py 3.4 
behaviour without bpo-19977) where they expected "ascii:surrogateescape" (the 
Py 3.5+ behaviour *with* bpo-19977).

To get a PEP 538 backport to work as intended on 3.4, you'd need to backport 
that earlier IO stream error handling change as well.

--

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



[issue39976] Add "**other_popen_kwargs" to subprocess API signatures in docs

2020-03-16 Thread Nick Coghlan


New submission from Nick Coghlan :

Two of my colleagues missed the "The arguments shown above are merely the most 
common ones, ..." caveat on the subprocess.run documentation, and assumed that 
Python 3.5 only supported the "cwd" option in the low level Popen API, and not 
any of the higher level APIs.

Something we could potential do is include a "**other_popen_kwargs" placeholder 
in the affected API signatures (run, call, check_call, check_output) that makes 
it clear there are more options beyond the explicitly listed ones.

--
assignee: docs@python
components: Documentation
messages: 364295
nosy: docs@python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add "**other_popen_kwargs" to subprocess API signatures in docs
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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



[issue39892] Enable DeprecationWarnings by default when not explicit in unittest.main()

2020-03-15 Thread Nick Coghlan


Nick Coghlan  added the comment:

Issue 10535 says they should already be on by default in unittest.

I seem to recall checking that was still true when implementing the default 
warning filter changes in 3.7.

--

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



[issue39824] Multi-phase extension module (PEP 489): don't call m_traverse, m_clear nor m_free before the module state is allocated

2020-03-15 Thread Nick Coghlan


Nick Coghlan  added the comment:

Petr's point that any subclass state should be managed in the subclass cleanup 
functions is a good one, so I withdraw my concern:

* custom module subclasses should clean up like any other class instance
* the module slots are then only needed if the module state actually gets 
populated, so we can safely skip them if it never even gets allocated

--

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



[issue39725] unrelated `from None` exceptions hide prior exception information

2020-03-15 Thread Nick Coghlan


Nick Coghlan  added the comment:

Tweaked title to be "hide" rather "lose" (all the info is theoretically still 
there in various places, it's just hidden by the default traceback printing 
machinery, and hard to extract from the exception tree).

Issue #18861 is the original report of this problem.

My concern with Serhiy's suggestion is that it would take us from merely hiding 
information to actually losing it.

I'm wondering if we're actually missing a piece of lower level infrastructure: 
a query API that reports *all* live exceptions in a thread.

For example, there might be a "sys.active_exceptions()" API that returned a 
list of all active exceptions.

* []: No exception active
* [exc]: Running an except/finally/__exit__ for "exc"
* [exc_inner, exc_outer]: Running an except/finally/__exit__ for "exc_inner" 
inside one for "exc_outer"
* etc

So in Serhiy's example, at the point where the context is suppressed, that new 
API would report [ValueError(), TypeError()] (with the relevant caught 
exception instances).

Given that extra low level API, we would gain more options for populating 
attributes on exceptions.

Alternatively, Serhiy's suggested approach might be sufficient, even without 
that new API, if we added a new __suppressed_context__ attribute to capture the 
original value of __context__ before it was replaced.

--
title: unrelated  `from None` exceptions lose prior exception information -> 
unrelated  `from None` exceptions hide prior exception information

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



[issue34822] Simplify AST for slices

2020-03-07 Thread Nick Coghlan


Nick Coghlan  added the comment:

The one thing in the PR that makes me slightly wary is the point Vedran raised: 
in the old AST _Unparser code, the fact that index tuples containing slices 
should be printed without parentheses was encapsulated in the ExtSlice node 
type, but with Index and ExtSlice removed, that behaviour is now instead 
implemented by duplicating the visit_Tuple logic directly in visit_Subscript, 
purely to omit the surrounding parens.

So I agree that the parse tree simplification is an improvement, but I'm 
wondering if it might make sense to add an "is_subscript" attribute to 
expression nodes.

That way the Tuple vs ExtSlice and Expr vs Index distinctions would be 
preserved, but the representation of those distinctions would change in a way 
that meant that most consuming code didn't need to care that the distinctions 
existed (ExtSlice would become a Tuple with is_subscript set to True, and 
similarly, Index would become Expr instances with is_subscript set to True).

It's been so long since I changed the AST, though, that I'm not sure how 
painful adding that attribute would be.

--

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



[issue39824] Multi-phase extension module (PEP 489): don't call m_traverse, m_clear nor m_free before the module state is allocated

2020-03-07 Thread Nick Coghlan


Nick Coghlan  added the comment:

One of the intended use cases for Py_mod_create is to return instances of 
ModuleType subclasses rather than straight ModuleType instances. And those are 
definitely legal to define:

>>> import __main__
>>> class MyModule(type(__main__)): pass
... 
>>> m = MyModule('example')
>>> m


So it isn't valid to skip calling the cleanup functions just because md_state 
is NULL - we have no idea what Py_mod_create might have done that needs to be 
cleaned up.

It would *probably* be legitimate to skip calling the cleanup functions when 
there's no Py_mod_create slot defined, but then the rules for "Do I need to 
account for md_state potentially being NULL or not?" are getting complicated 
enough that the safest option for a module author is to always assume that 
md_state might be NULL and handle that case appropriately.

--

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



[issue39465] Design a subinterpreter friendly alternative to _Py_IDENTIFIER

2020-02-08 Thread Nick Coghlan


Nick Coghlan  added the comment:

As Petr notes, as long as all subinterpreters share the GIL, and share str 
instances, then the existing _Py_IDENTIFIER mechanism will work fine for both 
single phase and multi-phase initialisation.

However, that constraint also goes the other way: as long as we have modules 
that use the existing _Py_IDENTIFIER mechanism, then subinterpreters *must* 
share str instances, and hence *must* share the GIL.

Hence the "enhancement" classification: there's nothing broken right now, but 
if we're ever going to achieve the design goal of using subinterpreters to 
exploit multiple CPU cores without the overhead of running multiple full 
interpreter processes, we're going to need to design a different way of 
handling this.

Something to keep in mind with `_Py_IDENTIFIER` and any replacement API: the 
baseline for performance comparisons is 
https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_InternFromString

The reason multi-phase initialisation makes this more complicated is that it 
means we can't use the memory addresses of C process globals as unique 
identifiers any more, since more than one module object may be created from the 
same C shared library.

However, if we assume we've moved to per-module state storage (to get unique 
memory addresses back), then we can largely re-use the existing 
`_Py_IDENTIFIER` machinery to make the lookup as fast as possible, while still 
avoiding conflicts between subinterpreters.

--

___
Python tracker 
<https://bugs.python.org/issue39465>
___
___
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 Nick Coghlan


Nick Coghlan  added the comment:

In the subinterpreter context: perhaps it would make sense to move *all* 
Py_IDENTIFIER declarations to file scope?

That would make it much clearer which of our extension modules actually have 
hidden state for caching purposes.

If we did that though, we'd also want to update the usage instructions in 
object.h

--

___
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



[issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code

2020-01-29 Thread Nick Coghlan


Nick Coghlan  added the comment:

My apologies, my comment above was based on an outdated understanding of how 
the identifier structs get initialised (it's the usage that initialises them, 
not the declaration).

That means this is a useful refactoring to help identify blockers to full 
subinterpreter support.

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

___
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



[issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code

2020-01-29 Thread Nick Coghlan


Nick Coghlan  added the comment:

We can't make this change, as it means the statics get initialised before the 
Python interpreter has been initialised, and won't be reinitialised if the 
interpreter is destroyed and recreated.

--
nosy: +ncoghlan
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
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



[issue39153] Clarify refcounting semantics of PyDict_SetItem[String]

2020-01-29 Thread Nick Coghlan


Nick Coghlan  added the comment:


New changeset e1e80002e28e1055f399a20918c49d50d093709e by Joannah Nanjekye in 
branch 'master':
bpo-39153: Clarify C API *SetItem refcounting semantics (GH-18220)
https://github.com/python/cpython/commit/e1e80002e28e1055f399a20918c49d50d093709e


--

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



[issue39465] Design a subinterpreter friendly alternative to _Py_IDENTIFIER

2020-01-27 Thread Nick Coghlan


Change by Nick Coghlan :


--
type:  -> enhancement

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



[issue39465] Design a subinterpreter friendly alternative to _Py_IDENTIFIER

2020-01-27 Thread Nick Coghlan


New submission from Nick Coghlan :

Both https://github.com/python/cpython/pull/18066 (collections module) and 
https://github.com/python/cpython/pull/18032 (asyncio module) ran into the 
problem where porting them to multi-phase initialisation involves replacing 
their usage of the `_Py_IDENTIFIER` macro with some other mechanism.

When _posixsubprocess was ported, the replacement was a relatively ad hoc 
combination of string interning and the interpreter-managed module-specific 
state: 
https://github.com/python/cpython/commit/5a7d2e11aaea2dd32878dc5c6b1aae8caf56cb44

I'm wondering if we may able to devise a comparable struct-field based system 
that replaces the `_Py_IDENTIFIER` local static variable declaration macro and 
the `Py_Id_` lookup convention with a combination like (using the posix 
subprocess module conversion as an example):

// Identifier usage declaration (replaces _Py_IDENTIFIER)
_Py_USE_CACHED_IDENTIFIER(_posixsubprocessstate(m), disable);

// Identifier usage remains unchanged, but uses a regular local variable
// rather than the static variable declared by _Py_IDENTIFIER
result = _PyObject_CallMethodIdNoArgs(gc_module, _disable);

And then the following additional state management macros would be needed to 
handle the string interning and reference counting:

// Module state struct declaration
typedef struct {
// This would declare an initialised array of _Py_Identifier structs
// under a name like __cached_identifiers__. The end of the array
// would be indicated by a strict with "value" set to NULL.
_Py_START_CACHED_IDENTIFIERS;
_Py_CACHED_IDENTIFIER(disable);
_Py_CACHED_IDENTIFIER(enable);
_Py_CACHED_IDENTIFIER(isenabled);
_Py_END_CACHED_IDENTIFIERS;
);
} _posixsubprocessstate;

// Module tp_traverse implementation
_Py_VISIT_CACHED_IDENTIFIERS(_posixsubprocessstate(m));

// Module tp_clear implementation (also called by tp_free)
_Py_CLEAR_CACHED_IDENTIFIERS(_posixsubprocessstate(m));

With the requirement to declare usage of the cached identifiers, they could be 
lazily initialized the same way the existing static variables are (even 
re-using the same struct declaration).

Note: this is just a draft of one possible design, the intent of this issue is 
to highlight the fact that this issue has now come up multiple times, and it 
would be good to have a standard answer available.

--
messages: 360766
nosy: eric.snow, ncoghlan, petr.viktorin, shihai1991
priority: normal
severity: normal
status: open
title: Design a subinterpreter friendly alternative to _Py_IDENTIFIER

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



[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

2020-01-20 Thread Nick Coghlan


Nick Coghlan  added the comment:


New changeset 1e420f849d0c094098543d2c27d35eaec69b2784 by Nick Coghlan in 
branch 'master':
bpo-35134: Migrate frameobject.h contents to cpython/frameobject.h (GH-18052)
https://github.com/python/cpython/commit/1e420f849d0c094098543d2c27d35eaec69b2784


--

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



[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

2020-01-20 Thread Nick Coghlan


Change by Nick Coghlan :


--
pull_requests: +17475
pull_request: https://github.com/python/cpython/pull/18052

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



[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

2020-01-18 Thread Nick Coghlan


Change by Nick Coghlan :


--
pull_requests: +17447
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18052

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



[issue39048] Change the lookup order of __aenter__ and __aexit__ for async with

2020-01-14 Thread Nick Coghlan


Change by Nick Coghlan :


--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: behavior -> enhancement
versions:  -Python 3.8

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



[issue39048] Change the lookup order of __aenter__ and __aexit__ for async with

2020-01-14 Thread Nick Coghlan

Nick Coghlan  added the comment:


New changeset 1d1b97ae643dd8b22d87785ed7bd2599c6c8dc8d by Nick Coghlan (Géry 
Ogam) in branch 'master':
bpo-39048: Look up __aenter__ before __aexit__ in async with (GH-17609)
https://github.com/python/cpython/commit/1d1b97ae643dd8b22d87785ed7bd2599c6c8dc8d


--
nosy: +ncoghlan

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



[issue39301] Specification of bitshift on integers should clearly state floor division used

2020-01-11 Thread Nick Coghlan


Nick Coghlan  added the comment:

Aye, adding "floor" to the existing footnote would be the minimal fix. I'm just 
wondering whether it's also worth stating that this means that positive 
integers saturate at zero, while negative integers saturate at -1.

--

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



[issue26515] Update extending/embedding docs to new way to build modules in C

2020-01-11 Thread Nick Coghlan


Nick Coghlan  added the comment:

Changed target version as per Petr's comment (PEP 573 is close to being 
accepted for 3.9 - it just needs some editing to improve clarity in the PEP 
itself, rather than needing any changes to the technical proposal)

--
versions: +Python 3.9 -Python 3.6, Python 3.7, Python 3.8

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



[issue39302] Language reference does not clearly describe modern operand coercion

2020-01-11 Thread Nick Coghlan


New submission from Nick Coghlan :

While reviewing ISO-IECJTC1-SC22-WG23's latest draft of their Python security 
annex, I found a description of operand coercion that was based on the legacy 
coercion model described at https://docs.python.org/2.5/ref/coercion-rules.html

That's still the second highest link if you search for "Python operand 
coercion", while the highest link is this old, very brief, summary from Python 
in a Nutshell: 
https://www.oreilly.com/library/view/python-in-a/0596001886/ch04s05.html (still 
based on the old semantics where the inputs were coerced to a common type 
before calling the slot method, rather than giving the method direct access to 
the original operands).

The third highest link at least goes to PEP 208 
(https://www.python.org/dev/peps/pep-0208/), which correctly describes the 
modern semantics, but it describes them in terms of the CPython C slot API, not 
the Python level special method APIs.

https://docs.python.org/3.7/reference/datamodel.html#emulating-numeric-types 
does technically provide the required information, but it's implicit in the 
description of the numeric arithmetic methods, rather than being clearly 
spelled out as a clear description of "Python operand coercion". (There are 
also some oddities around operand coercion for three-argument pow() that I'm 
going to file as their own issue)

https://docs.python.org/3/library/constants.html#NotImplemented references 
https://docs.python.org/3/library/numbers.html#implementing-the-arithmetic-operations
 which describes defining new numeric ABCs in a coercion-friendly way, but 
still doesn't spell out the operand precedence and coercion dance.

We could likely improve this situation by adding a new "Special method 
invocation" subject at the end of 
https://docs.python.org/3.7/reference/datamodel.html, moving the existing 
"Special method lookup" subsection under it, and then adding a second 
subsection called "Operand precedence and coercion".

That new subsection would then cover the basic principles of:

* for unary operands, there is no ambiguity
* for binary operands of the same type, only the forward operation is tried (it 
is assumed that if the forward operation doesn't work, the reflected one won't 
either)
* for binary operands where the type of the RHS is a subclass of the type of 
the LHS, the reflected operation is tried first (if it exists), followed by the 
forward operation if the reflected call does not exist or returns the 
NotImplemented singleton
* for binary operands of unrelated types, the forward operation is tried first 
(if it exists), followed by the reflected operation if the forward call does 
not exist or returns the NotImplemented singleton
* for ternary operands (i.e. 3 argument pow()), the behaviour is currently 
implementation defined (as the test suite doesn't enforce any particular 
behaviour, and what CPython does isn't obviously useful)

Other specific points to be covered would be:

* any argument coercion that occurs is up to the individual method 
implementations
* logical short-circuiting expressions (and, or, if/else) only call the 
equivalent of bool(expr)

While the corresponding reflected operations for the binary operators are 
covered in the documentation of the forward operations, it would also likely be 
worthwhile including a summary table in this new subsection of exactly which 
special methods support reflection, and what the reflected method names are.

--
messages: 359788
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Language reference does not clearly describe modern operand coercion
type: enhancement
versions: Python 3.8, Python 3.9

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



[issue39301] Specification of bitshift on integers should clearly state floor division used

2020-01-10 Thread Nick Coghlan


New submission from Nick Coghlan :

While reviewing ISO-IECJTC1-SC22-WG23's latest draft of their Python security 
annex, I noticed that 
https://docs.python.org/3.7/library/stdtypes.html#bitwise-operations-on-integer-types
 doesn't explicitly state that *floor* division is used for right shift 
operations, so right-shifting a negative number by more bits than it contains 
gives -1 rather than 0.

This is consistent with the way the language spec defines both binary 
right-shifts (as division by "pow(2, n)" and floor division (as rounding 
towards negative infinity), so this is just a documentation issue to note that 
we should make it clearer that this behaviour is intentional.

--
assignee: docs@python
components: Documentation
messages: 359786
nosy: docs@python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Specification of bitshift on integers should clearly state floor 
division used
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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



[issue37194] Move new vector private declarations to the internal C API

2020-01-07 Thread Nick Coghlan


Change by Nick Coghlan :


--
pull_requests:  -17306

___
Python tracker 
<https://bugs.python.org/issue37194>
___
___
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-30 Thread Nick Coghlan


Nick Coghlan  added the comment:

Thinking about that idea further, I don't think that change would help much, 
since the relevant operations should already be checking for thread termination 
when they attempt to reacquire the GIL.

That means what we're missing is:

1. When daemon threads still exist after the non-daemon threads terminate, 
deliberately giving them additional time to run (and hence terminate)
2. Explicitly attempting to kick daemon threads out of blocking system calls by 
sending them signals to provoke EINTR (I have no idea if there's a windows 
equivalent for this, but we should be able to use pthread_kill on POSIX 
systems. However, choosing *which* wakeup signal to send could be fraught with 
compatibility problems)

--

___
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-30 Thread Nick Coghlan


Nick Coghlan  added the comment:

Perhaps we need a threading.throw() API, similar to the one we have for 
generators and coroutines?

If we had that, then Py_FinalizeEx() could gain a few new features:

* throw SystemExit into all daemon threads and then give them a chance to 
terminate before calling any atexit handlers (printing a warning if some of the 
threads don't exit)
* throw SystemExit into all daemon and non-daemon threads after running atexit 
handlers (printing a warning if any such threads exist at all, along with 
another warning if some of the threads don't exit)

Adding that would require an enhancement to the PendingCall machinery, though, 
since most pending calls are only processed in the main thread (there's no way 
to route them to specific child threads).

A simpler alternative would be to have an atomic "terminate_threads" counter in 
the ceval runtime state that was incremented to 1 to request that SystemExit be 
raised in daemon threads, and then to 2 to request that SystemExit be raised in 
all still running threads. When a thread received that request to exit, it 
would set a new flag in the thread state to indicate it was terminating, and 
then raise SystemExit. (The thread running Py_FinalizeEx would set that flag in 
advance so it wasn't affected, and other threads would use it to ensure they 
only raised SystemExit once). The runtime cost of this would just be another 
_Py_atomic_load_relaxed call in the eval_breaker branch. (Probably inside 
`make_pending_calls`, so it gets triggered both by the eval_breaker logic, and 
by explicit calls to `Py_MakePendingCalls`).

--

___
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



[issue20443] __code__. co_filename should always be an absolute path

2019-12-30 Thread Nick Coghlan


Nick Coghlan  added the comment:

With the sys.argv[0] change reverted, I think this overall issue is fixed now - 
code objects will get absolute paths, while sys.argv[0] will continue to 
reflect how __main__ was identified.

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

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



[issue39037] Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation

2019-12-29 Thread Nick Coghlan

Nick Coghlan  added the comment:


New changeset 226e6e7d4326cf91ef37e13528eb1f62de1bb832 by Nick Coghlan (Géry 
Ogam) in branch 'master':
bpo-39037: Fix lookup order of magic methods in with statement documentation 
(GH-17608)
https://github.com/python/cpython/commit/226e6e7d4326cf91ef37e13528eb1f62de1bb832


--

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



[issue39161] Py_NewInterpreter docs need updating for multi-phase initialization

2019-12-29 Thread Nick Coghlan


New submission from Nick Coghlan :

The Py_NewInterpreter docs only cover the behaviour of extension modules that 
use single-phase initialization: 
https://docs.python.org/3/c-api/init.html#c.Py_NewInterpreter

Multi-phase initialization allows each subinterpreter to get its own copy of 
extension modules as well, with only C/C++ level static and global variables 
being shared.

--
assignee: docs@python
components: Documentation
messages: 359019
nosy: docs@python, ncoghlan, petr.viktorin
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_NewInterpreter docs need updating for multi-phase initialization
type: enhancement
versions: Python 3.8, Python 3.9

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



[issue39153] Clarify refcounting semantics of PyDict_SetItem[String]

2019-12-29 Thread Nick Coghlan


Nick Coghlan  added the comment:

Right, that's why I don't think the other "*SetItem*" operations should get a 
Sphinx note - just a sentence, as was already done for PySequence_SetItem.

If it weren't for PyList_SetItem being different, none of the others would need 
the clarification at all.

--

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



[issue39153] Clarify refcounting semantics of PyDict_SetItem[String]

2019-12-29 Thread Nick Coghlan


Change by Nick Coghlan :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.8, Python 3.9

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



[issue39153] Clarify refcounting semantics of PyDict_SetItem[String]

2019-12-29 Thread Nick Coghlan


New submission from Nick Coghlan :

The documentation for PyList_SetItem is explicit that it steals a reference to 
the passed in value, and drops the reference for any existing entry: 
https://docs.python.org/3.3/c-api/list.html?highlight=m#PyList_SetItem

The documentation for PyDict_SetItem leaves the semantics unspecified, forcing 
the reader to either make assumptions, or else go read the source code (as was 
done for the SO answer at 
https://stackoverflow.com/questions/40700251/reference-counting-using-pydict-setitemstring)

Since the default assumption is actually correct, I don't think a Sphinx note 
is warranted, but an extra explicit sentence would be helpful.

PySequence_SetItem has such a sentence already: "This function does *not* steal 
a reference to v."

My suggestion is that we also add that sentence to the documentation for:

* PyObject_SetItem
* PyMapping_SetItemString
* PyDict_SetItem
* PyDict_SetItemString

--
messages: 358988
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Clarify refcounting semantics of PyDict_SetItem[String]

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



[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-15 Thread Nick Coghlan


Nick Coghlan  added the comment:


New changeset 79f02fee1a542c440fd906fd54154c73fc0f8235 by Nick Coghlan (Xtreak) 
in branch 'master':
bpo-39033: Fix NameError in zipimport during hash validation (GH-17588)
https://github.com/python/cpython/commit/79f02fee1a542c440fd906fd54154c73fc0f8235


--
nosy: +ncoghlan

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



[issue38021] Modify AIX platform_tag so it provides PEP425 needs

2019-12-15 Thread Nick Coghlan


Nick Coghlan  added the comment:

Thanks for your patience Michael!

I made some cosmetic changes to the error handling logic that you may want to 
include in the PyPA patches. (I'd intended to make it so that a malformed build 
date resulted in the "Unknown" "9898" build date being used, rather than 
triggering a ValueError on import of the AIX support module, but my except 
clause was too narrow. A PR to widen it to trap ValueError as well would 
definitely be acceptable).

For detection of tag variants, counting hyphens has the benefit of being able 
to distinguish more variants than just two, but checking the final field would 
indeed work for distinguishing the current two formats.

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

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



[issue38021] Modify AIX platform_tag so it provides PEP425 needs

2019-12-15 Thread Nick Coghlan


Nick Coghlan  added the comment:


New changeset 39afa2d3147e4b05a1161cc90dbf09b95072c2bb by Nick Coghlan (Michael 
Felt) in branch 'master':
bpo-38021: Modify AIX platform_tag so it covers PEP 425 needs (GH-17303)
https://github.com/python/cpython/commit/39afa2d3147e4b05a1161cc90dbf09b95072c2bb


--

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



[issue37292] _xxsubinterpreters: Can't unpickle objects defined in __main__

2019-12-15 Thread Nick Coghlan


Nick Coghlan  added the comment:

There's a reason multiprocessing in spawn mode jumps through the hoops that it 
does: it's the only way to get __main__ pickling to work when you're not 
forking the entire process.

You also don't want to naively re-run __main__ in the subprocess for the same 
reason multiprocessing doesn't: doing so would also re-run the script parts, 
not just the class and function definition parts.

So while I don't think it should be implicit the way it is for multiprocessing 
spawn mode, I do think it would make sense to offer a way to explicitly opt-in 
to re-running __main__ in a child interpreter as "__si_main__", aliasing the 
subinterpreter's __main__ module to that, and also aliasing "__si_main__" to 
"__main__" in the parent interpreter.

--
nosy: +ncoghlan

___
Python tracker 
<https://bugs.python.org/issue37292>
___
___
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-12-15 Thread Nick Coghlan


Nick Coghlan  added the comment:

Leaving the relationship between pickle and __name__ alone wasn't an oversight, 
as folks already rely on that to gracefully transition from single-file modules 
to multi-file packages without breaking pickle compatibility in either 
direction. The trick is to do a "from ._submodule import *" in the package's 
__init__.py (exposing all the names), and then a "__name__ = __package__" in 
the submodule itself.

Thus the second snippet above, as a way to port code that was specifically 
relying on the double import to provide pickle compatibility without risking 
introducing other unintended incompatibility problems.

--

___
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



[issue39037] Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation

2019-12-15 Thread Nick Coghlan


Nick Coghlan  added the comment:

It's a matter of historical timing: PEP 343 was written before 
try/except/finally was allowed, when try/finally and try/except were still 
distinct statements.

However, PEP 341 was *also* accepted and implemented for Python 2.5, allowing 
for the modern try/except/finally form: 
https://docs.python.org/dev/whatsnew/2.5.html#pep-341-unified-try-except-finally

--

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



[issue38021] Modify AIX platform_tag so it provides PEP425 needs

2019-12-08 Thread Nick Coghlan


Nick Coghlan  added the comment:

There's a compatibility problem with changing the AIX distutils platform prefix 
from aix to AIX: any existing code that does 
"distutils.get_platform().startswith('aix')" will break. (There isn't any code 
in the standard library that does that, it all checks sys.platform() instead, 
but it's a reasonable assumption that there's going to be code in the wild that 
does a prefix check on the distutils API output).

So I think we'll want to make the distinction between the two formats based on 
the number of hyphens they contain, rather than changing the prefix.

I *haven't* made that change directly to the PR myself, as I want to give you a 
chance to consider the question first, but I do think it's a required 
compatibility improvement before we move ahead with this.

--

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



[issue38021] Modify AIX platform_tag so it provides PEP425 needs

2019-12-08 Thread Nick Coghlan


Nick Coghlan  added the comment:

Removing 3.9 from the target versions, as similar to other platform tag 
improvements, emulation on older release versions will be the domain of 
cross-version libraries, rather than changing the standard library in a 
maintenance.

--
versions:  -Python 3.8

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



[issue38021] pep425 tag for AIX is inadequate

2019-11-23 Thread Nick Coghlan


Nick Coghlan  added the comment:

For folks that aren't aware, Michael and I have been discussing the AIX package 
tagging problem via email since his initial distutils-sig posts about it.

It's genuinely murky as fixing the AIX problem doesn't *technically* require 
any PEP 425 changes, as the main problem with the status quo is in the way the 
platform string is calculated, rather than in the way that then gets 
incorporated into a PEP 425 compatibility tag.

I think the subtlety I may not have cconveyed clearly though is that installers 
only do exact string matches on platform tags, working through a set of 
increasingly less specific candidates.

So if the goal is the same model that we use for Windows and Mac OS X, where 
the Python interpreter build defines the exact platform string that packages 
need to use, then all that's needed is the new platform string logic. That then 
places constraints on how AIX extension modules are built, but doesn't require 
a new PEP for installer logic changes. I think this is a good level of support 
to target.

There's then a further option that *would* require a new PEP: teaching 
installers to be more permissive in the compatibility tags they accept for AIX, 
based on the AIX ABI compatibility guidelines. I *don't* think that's a good 
idea - better to deal with that on the publication side, the way it is done for 
Windows and Mac OS X extensions.

--

___
Python tracker 
<https://bugs.python.org/issue38021>
___
___
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-12 Thread Nick Coghlan


Nick Coghlan  added the comment:

[Belatedly updating this issue with the current status as of March]

Cameron's implementation generally looks good, but there are couple of 
compatibility/migration questions that we need to consider, as spelled out in 
the PEP update that added me as BDFL-Delegate: 
https://github.com/python/peps/pull/946/files

* We need a generic porting guide entry to handle projects that turn out to 
have been relying on their name *not* being bound in sys.modules. For example, 
adding this preamble:

if __name__ == "__main__":
# To prevent inadvertent double imports, the -m
# switch in Python 3.9+ defaults to aliasing __main__
# under the executed module's import name. We actually
# want the double import, so remove the alias if it exists
import sys
_main_module = sys.modules.get(__name__)
_spec_module = sys.modules.get(__spec__.name)
if _main_module is _spec_module:
sys.modules.pop(__spec__.name)

We'd test the above snippet by adding it to the `pdb` module (and reverting the 
other compatibility changes to that module)

* We need to understand the implications for pickle compatibility, and provide 
a porting guide snippet, similar to the one above for explicitly requesting the 
double-import behaviour. For example:

if __name__ == "__main__":
# To prevent inadvertent double imports, the -m
# switch in Python 3.9+ defaults to aliasing __main__
# under the executed module's import name. We need
# pickle to use the real module name for objects from
# __main__ though, so we set the import name here
_running_as_main = True
__name__ = __spec__.name

--

___
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



[issue20443] __code__. co_filename should always be an absolute path

2019-10-23 Thread Nick Coghlan


Nick Coghlan  added the comment:

This change isn't in Python 3.8 though, it's only in Python 3.9 (the PR merge 
date is after the beta 1 branch date).

Unless it was backported in a Python 3.8 PR that didn't link back to this issue 
or the original Python 3.9 PR?

--

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



[issue38524] functools.cached_property is not supported for setattr

2019-10-20 Thread Nick Coghlan


Nick Coghlan  added the comment:

After writing my previous comment, I double-checked the code, and 
cached_propery is actually one of the cases where a simple "self.attrname = 
'age3'" *will* do the right thing, as cached_property never checks the class 
information.

That won't work in the general case though, and I think it makes more sense for 
the cached_property documentation to provide advice that will generalise to 
arbitrary descriptors (i.e. call `descr.__set_name__(target, "attr")`)

--

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



[issue38524] functools.cached_property is not supported for setattr

2019-10-20 Thread Nick Coghlan


Nick Coghlan  added the comment:

Regarding the "attrname" property idea: unfortunately, that won't work, as 
`__set_name__` doesn't just provide the attribute name, it also provides a 
reference to the class itself.

cached_property needs both pieces of information, not just the attribute name.

--

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



[issue38524] functools.cached_property is not supported for setattr

2019-10-20 Thread Nick Coghlan


Nick Coghlan  added the comment:

Another interesting question this raises is whether type.__setattr__ should be 
checking for values that have `__set_name__` methods defined and calling those 
methods automatically.

Unfortunately, I think the answer to that is "If we'd thought of that when 
writing PEP 487, then sure, but it's too late now, as too many folks will be 
calling it explicitly, and implicitly calling it a second time will cause 
other, potentially harder to find problems".

So +1 for updating the cached_property docs specifically to mention this problem

However, I'm also wondering if there's somewhere else we should be mentioning 
it as a general problem.

Perhaps in the docs for __set_name__ itself, noting it as something that 
authors of descriptors *using* __set_name__ should mention in their docs, with 
suggested wording?

Something like:

===
`__set_name__`` is only called implicitly as part of the ``type`` constructor, 
so it will need to be called explicitly with the appropriate parameters when a 
descriptor is added to a class after initial creation::

descr = custom_descriptor()
cls.attr = descr
descr.__set_name__(cls, 'attr')
===

(The normal sequence is for the descriptor to already be part of the class 
namespace before __set_name__ gets called)

--

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



[issue20443] __code__. co_filename should always be an absolute path

2019-10-20 Thread Nick Coghlan


Nick Coghlan  added the comment:

I think that's a valid point regarding sys.argv[0] - it's the import system and 
code introspection that wants(/needs) absolute paths, whereas sys.argv[0] gets 
used in situations (e.g. usage messages) where we should retain whatever the OS 
gave us, since that best reflects what the user entered.

That's straightforward to selectively revert, though: remove the 
"config->run_filename != NULL" clause at 
https://github.com/python/cpython/blob/24dc2f8c56697f9ee51a4887cf0814b6600c1815/Python/initconfig.c#L2201
 and add a comment with the reason for the deliberate omission.


That way the OS-provided argv entry will continue to be passed through to 
sys.argv[0], while everywhere else will get the absolute path.

--
versions: +Python 3.9 -Python 3.5

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



[issue38457] __package__ is None in __init__.py until an import is used

2019-10-20 Thread Nick Coghlan


Nick Coghlan  added the comment:

Yes, this is a design flaw in the Python 2 import system - it derives 
`__package__` from `__name__` the first time it needs the information and 
`__package__` isn't already set.

The problem was fixed for the Python 3 series by way of PEP 451, which made 
substantial changes to the way module initialisation works, allowing the import 
system to instead derive `__package__` from `__spec__` as part of module 
creation.

Depending on your reasons for being interested in this, the `importlib2` 
package may be of interest: https://pypi.org/project/importlib2/

(Judging from the version number, Eric last updated that for Python 3.5, which 
means it will include the PEP 451 behaviour)

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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



[issue32856] Optimize the `for y in [x]` idiom in comprehensions

2019-10-20 Thread Nick Coghlan


Nick Coghlan  added the comment:

The benefit offered by the parent local scoping was that it made assignment 
expressions usable as a straightforward way to implement comprehension-based 
accumulators where you actually do want access to the final value after the 
comprehension completes (for example, pulling the example or counter-example 
out of a call to any() or all()).

The downside is that you need an explicit "del j" after the comprehension to 
ensure prompt cleanup in those cases where you *don't* need the temporary 
variable after the comprehension has finished running:

>>> [(j:=i*i)+1/j for i in range(1, 3)]; del j # Clean up temp

However, that's still going to be clearer to most readers than writing:

[j+1/j for i in range(1, 3) for j in [i*i]]

So even with the parent local scoping semantics, PEP 572 is still enough to 
make Yury's comment above still hold (i.e. the use case is too obscure to 
justify the extra code needed to optimise it)

--

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



[issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)

2019-10-20 Thread Nick Coghlan


Nick Coghlan  added the comment:

(Removed the patch keyword, as the linked PR was for an old change that didn't 
cover the remaining test issues)

--

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



[issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)

2019-10-20 Thread Nick Coghlan


Nick Coghlan  added the comment:

There are a couple of cases that the C locale coercion tests skip because I 
don't (or didn't) know what they *should* do:

* 
https://github.com/python/cpython/blob/24dc2f8c56697f9ee51a4887cf0814b6600c1815/Lib/test/test_c_locale_coercion.py#L262
 (skips the "LANG=UTF-8" test)
* 
https://github.com/python/cpython/blob/24dc2f8c56697f9ee51a4887cf0814b6600c1815/Lib/test/test_c_locale_coercion.py#L37
 (only adds "POSIX" to the expected C locale equivalents list on non-Android 
Linux systems)

With the interpreter explicitly checking for "POSIX" now, at least the latter 
special case could potentially be removed, with "POSIX" just always being part 
of the EXPECTED_C_LOCALE_EQUIVALENTS list. (It was only removed because it used 
to break on FreeBSD and Mac OS X)

I don't think we ever figured out why the "LANG=UTF-8" case didn't work the way 
we expected, so I suspect where going to need to keep that skip for now.

--

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



[issue22257] PEP 432 (PEP 587): Redesign the interpreter startup sequence

2019-10-05 Thread Nick Coghlan


Nick Coghlan  added the comment:

Agreed. I've also added PEP 587 to the issue title to make the connection to 
that PEP more obvious.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: PEP 432: Redesign the interpreter startup sequence -> PEP 432 (PEP 587): 
Redesign the interpreter startup sequence

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



[issue18578] Rename and document test.bytecode_helper as test.support.bytecode_helper

2019-10-05 Thread Nick Coghlan


Nick Coghlan  added the comment:

Just noting for the record that the reason a new warning wasn't needed here is 
because there is already a general "No compatibility guarantees" warning for 
the entire test package: https://docs.python.org/3/library/test.html

Thanks for getting this resolved!

--

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



[issue38326] Concerns with the last minute changes to the PEP 587 API

2019-09-30 Thread Nick Coghlan


Change by Nick Coghlan :


--
keywords: +patch
pull_requests: +16084
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/16496

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



[issue38326] Concerns with the last minute changes to the PEP 587 API

2019-09-30 Thread Nick Coghlan


Nick Coghlan  added the comment:

(I'm currently working a PR for this that Victor can review)

--
assignee:  -> ncoghlan

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



[issue38326] Concerns with the last minute changes to the PEP 587 API

2019-09-30 Thread Nick Coghlan


New submission from Nick Coghlan :

(Nosy list is RM, PEP 587 BDFL-Delegate, PEP 587 author)

Filing as a release blocker, given that I don't think we should ship rc1 until 
consensus has been reached on the last minute changes to the PEP 587 
configuration API.

Thread at 
https://mail.python.org/archives/list/python-...@python.org/thread/C7Z2NA2DTM3DLOZCFQAK5A2WFYO3PHHX/

--
messages: 353573
nosy: lukasz.langa, ncoghlan, twouters, vstinner
priority: release blocker
severity: normal
stage: commit review
status: open
title: Concerns with the last minute changes to the PEP 587 API
type: enhancement

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



[issue38304] PEP 587 implementation is not ABI forward compatible

2019-09-29 Thread Nick Coghlan


Nick Coghlan  added the comment:

The hidden _config_version field wasn't in the accepted PEP.

Both it and struct_size should be removed, as we don't support updating an 
embedded Python runtime to a new X.Y.0 release without rebuilding the embedding 
application.

--
nosy: +ncoghlan

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



[issue37937] Mention ``frame.f_trace`` in :func:`sys.settrace` docs.

2019-09-20 Thread Nick Coghlan


Nick Coghlan  added the comment:

Thanks for the PR, Ram, and the initial review, Serhiy.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8

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



[issue37937] Mention ``frame.f_trace`` in :func:`sys.settrace` docs.

2019-09-20 Thread Nick Coghlan


Nick Coghlan  added the comment:


New changeset 9c2682efc69568e1b42a0c1759489d6f2e3b30ea by Nick Coghlan (Ram 
Rachum) in branch 'master':
bpo-37937: Mention frame.f_trace in sys.settrace docs (GH-15439)
https://github.com/python/cpython/commit/9c2682efc69568e1b42a0c1759489d6f2e3b30ea


--
nosy: +ncoghlan

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



[issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds

2019-09-14 Thread Nick Coghlan


Nick Coghlan  added the comment:

It's also not unique to with statements - it applies to all finally clauses. 
The longstanding workaround when deterministic cleanup is absolutely critical 
has been to run the "real" application in a subthread, and devote the main 
thread to gracefully terminating the subthread when requested.

When cleanup is critical, but doing it in a deterministic order is less so, 
__del__ methods are often used to fill the gap (although they too can be 
interrupted by a subsequent Ctrl-C).

I also realized that allowing infinite loops in cleanup code to ignore Ctrl-C 
may actually be a tolerable outcome: in the worst case, users can still 
escalate to Ctrl-Break/kill -9/Force stop/etc and pull the entire OS process 
out from under the interpreter. It's not good, but may be worth it in order to 
better handle users pressing Ctrl-C multiple times.

--

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



[issue33095] Cross-reference isolated mode from relevant locations

2019-09-13 Thread Nick Coghlan


Nick Coghlan  added the comment:


New changeset bdd6945d4dbd1fe6a7fcff95f7d6908db7d791a1 by Nick Coghlan (Xtreak) 
in branch 'master':
bpo-33095: Add reference to isolated mode in -m and script option (GH-7764)
https://github.com/python/cpython/commit/bdd6945d4dbd1fe6a7fcff95f7d6908db7d791a1


--

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



[issue37941] python -m and runpy.run_module set different __name__ by default

2019-09-11 Thread Nick Coghlan


Nick Coghlan  added the comment:

There is one, it just isn't public: runpy._run_module_as_main.

It's a private API that the -m switch implementation calls, and was introduced 
after the original runpy.run_module was found not to offer everything the 
switch needed.

It isn't possible to fully emulate -m from Python code though, as the lifecycle 
of the real main module is intertwined with the lifecycle of the underlying 
interpreter.

So if folks really want to try to do this, the source code is there to look at, 
but we're not giving the false impression that it's easy to do correctly with 
no unintended consequences.

--

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



[issue30076] Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL are too long

2019-09-11 Thread Nick Coghlan


Nick Coghlan  added the comment:

So we'd be going with a naming convention where "VAR" corresponds to the star 
syntax, and whether it means packing or unpacking, or refers to arguments or 
parameters is context dependent?

I could definitely support that, given that the ambiguity already exists at the 
Python syntax level.

--

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



[issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds

2019-09-11 Thread Nick Coghlan


Nick Coghlan  added the comment:

There is also the draft test case at https://github.com/ncoghlan/cpython/pull/2

That needs updating to account for the eval loop changes since I last worked on 
it, though. (I think that conflict may also be keeping the bots from running, 
even after I updated the issue title to use the modern convention)

--

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



[issue30076] Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL are too long

2019-09-03 Thread Nick Coghlan


Nick Coghlan  added the comment:

Reviewing this again now, I think my previous naming suggestion is problematic, 
as it encourages conflating two different concepts that use similar syntax:

* collecting arbitrary positional parameters in a tuple (VAR_POSITIONAL) or 
arbitrary keyword parameters in a dictionary (VAR_POSITIONAL, VAR_KEYWORD)
* unpacking function arguments from iterables (BUILD_VAR_POSITIONAL) or 
mappings (BUILD_VAR_KEYWORD)

I think the fix for that error is straightforward though: replace "VAR" with 
"ARG" in the new opcode names, giving:

* BUILD_ARG_POSITIONAL
* BUILD_ARG_KEYWORD

That should also read nicely with Zackery's documentation updates.

--

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



[issue37398] contextlib.ContextDecorator decorating async functions

2019-09-03 Thread Nick Coghlan


Nick Coghlan  added the comment:

The query in #37743 highlights that generator functions and other wrapped 
iterator factories actually face a similar problem: they need the function body 
to contain "yield from wrapped(*args, **kwargs)" if the CM is going to be 
closed after the iterator terminates (or is closed), rather than closing 
immediately after the iterator is created.

--

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



[issue37743] How should contextmanager/ContextDecorator work with generators?

2019-09-03 Thread Nick Coghlan


Nick Coghlan  added the comment:

This is a documentation bug, as the current behaviour is as intended, but the 
documented equivalence doesn't hold for generator functions: for a generator 
function, the CM will only be applied when the generator is instantiated, 
whereas the inline context manager version will be held open until the 
generator is closed or destroyed.

That said, an approach similar to the one discussed in #37398 could also be 
applied, here, with a separate "ContextDecorator.generator()" class method 
added to give the "wrapped yield from" behaviour. If anyone is interested in 
pursuing that, it can be filed as a separate enhancement issue (leaving this 
bug to cover the fact that the existing documentation is only accurate for 
regular synchronous functions)

--
assignee: ncoghlan -> 
components: +Documentation -Library (Lib)

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



[issue37398] contextlib.ContextDecorator decorating async functions

2019-09-03 Thread Nick Coghlan


Nick Coghlan  added the comment:

It isn't the simple case where the auto-detection idea concerns me, it's 
decorator stacking cases like:

@outer
@magic_detection
@inner_forces_async
def sync_native_api():
...

(With the original asyncio.coroutine being one example, but there are other 
situations where this comes up, like a wrapper that bundles synchronous calls 
up into an executor invocation)

That said, I'd be completely fine with a combination where:

* ContextDecorator grew a coroutine() classmethod (open to suggestions for 
bikeshed colours)
* The regular ContextDecorator constructor emitted a warning suggesting 
"cls.coroutine" when it was applied to a synchronous function

Then the original example would provide distinct spellings for the sync and 
async case, without the definition of PerfTimer needing to change:

  @PerfTimer.coroutine('query_async')
  async def query_or_throw(self, q):
  return _parse_result(await self._send_query(q))

  @PerfTimer('query_sync')
  def query_or_throw(self, q):
  return _parse_result(self._send_query_sync(q))

That way we're still refusing to guess in the face of ambiguity (does the user 
want the coroutine version of the context manager, or did they accidentally mix 
a potentially blocking synchronous context manager into their async code?), but 
the warning can be usefully explicit regarding how to resolve the ambiguity.

--

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



[issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level

2019-09-03 Thread Nick Coghlan


Nick Coghlan  added the comment:

We never actually coded a reproducer for this, but if we had, it would have 
been a crash bug.

--
type:  -> crash

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



[issue31874] [feature] runpy.run_module should mimic script launch behavior for sys.path

2019-09-03 Thread Nick Coghlan


Nick Coghlan  added the comment:

Good point regarding the heuristic: it would need to take the requested module 
name into account to be correct.

* check if the requested module was found relative to the current directory 
(can be worked out from __main__.__spec__ and the current working directory)
* if it was, make sys.path[0] the absolute path of the current directory
* otherwise, remove sys.path[0] entirely

--
nosy: +ncoghlan

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



[issue37941] python -m and runpy.run_module set different __name__ by default

2019-09-03 Thread Nick Coghlan


Nick Coghlan  added the comment:

Yes, this is deliberate. From the run_module documentation: "__name__ is set to 
run_name if this optional argument is not None, to mod_name + '.__main__' if 
the named module is a package and to the mod_name argument otherwise."

This allows arbitrary code to be executed to populate a namespace, but you have 
to explicitly opt-in to having a second pseudo-__main__ module run in the same 
process (with all the potential pickle compatibility issues that doing so 
creates).

--
resolution:  -> not a bug

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



[issue37941] python -m and runpy.run_module set different __name__ by default

2019-09-03 Thread Nick Coghlan


Change by Nick Coghlan :


--
stage:  -> resolved
status: open -> closed

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



[issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level

2019-08-29 Thread Nick Coghlan


Nick Coghlan  added the comment:


New changeset 06145230c833c3db5dab8858e11bcd550a37c57f by Nick Coghlan in 
branch 'master':
bpo-37947: Avoid double-decrement in symtable recursion counting (GH-15593)
https://github.com/python/cpython/commit/06145230c833c3db5dab8858e11bcd550a37c57f


--

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



[issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level

2019-08-29 Thread Nick Coghlan


Nick Coghlan  added the comment:

Reviewing all the code that touches recursion_depth (both in the symtable and 
in the thread state), I'm not seeing any sanity checks that ensure our 
increments and decrements *balance*.

So I'm going to add one to PySymTable_BuildObject.

--

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



[issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level

2019-08-29 Thread Nick Coghlan


Nick Coghlan  added the comment:

Reviewing the PR post-merge, I'm pretty sure this has introduced a 
double-decrement bug due to the original code being hard to read (the error 
cases did the decrement inside the helper function, while the success case did 
it in the calling function).

https://github.com/python/cpython/pull/15593 builds on your PR by removing the 
recursion counter adjustments from inside the helper function, leaving only the 
ones in the calling function.

--
nosy: +ncoghlan

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



[issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level

2019-08-29 Thread Nick Coghlan


Change by Nick Coghlan :


--
pull_requests: +15269
pull_request: https://github.com/python/cpython/pull/15593

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



[issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots

2019-08-29 Thread Nick Coghlan


Nick Coghlan  added the comment:

Thank you Pablo!

Even having seen your fix, it still took me a couple of rescans of the original 
PR to figure out exactly how I'd broken it in the first place (refactoring to 
call an existing function without noticing that the replaced code included an 
extra DECREF).

--

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



[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-25 Thread Nick Coghlan


Nick Coghlan  added the comment:

Merged for 3.8b4 after Emily's review.

Thanks to all involved in the PEP update and change discussion!

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

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



[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-25 Thread Nick Coghlan


Nick Coghlan  added the comment:


New changeset 6ca030765db49525f16b8fabff4153238148b58d by Nick Coghlan in 
branch '3.8':
[3.8] bpo-37757: Disallow PEP 572 cases that expose implementation details 
(GH-15491)
https://github.com/python/cpython/commit/6ca030765db49525f16b8fabff4153238148b58d


--

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



[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-25 Thread Nick Coghlan


Change by Nick Coghlan :


--
pull_requests: +15178
pull_request: https://github.com/python/cpython/pull/15491

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



[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-25 Thread Nick Coghlan


Nick Coghlan  added the comment:


New changeset 5dbe0f59b7a4f39c7c606b48056bc29e406ebf78 by Nick Coghlan in 
branch 'master':
bpo-37757: Disallow PEP 572 cases that expose implementation details (GH-15131)
https://github.com/python/cpython/commit/5dbe0f59b7a4f39c7c606b48056bc29e406ebf78


--

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



[issue37830] continue and break in finally with return in try results with segfault

2019-08-14 Thread Nick Coghlan


Nick Coghlan  added the comment:

Even though it doesn't fully resolve this crash, I'd still like us to consider 
reverting the change to allow "continue" in try/finally blocks.

It doesn't seem to have a compelling practical motivation behind it (beyond the 
fact that it's nice not to impose arbitrary restriction on users), and even if 
it's feasible in CPython now, it still creates a non-trivial amount of work for 
other Python implementations that are trying to remain consistent with what 
CPython allows.

--
nosy: +ncoghlan

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



[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-13 Thread Nick Coghlan


Nick Coghlan  added the comment:

The outcome of the python-dev discussion was that we agreed to switch to 
raising a plain SyntaxError, as that's what we do everywhere else that this 
kind of problem comes up (e.g. conflicts between global and nonlocal 
declarations, or between those and parameter declarations, as well as the 
various other cases of "that statement/expression is fine in isolation, but you 
can't use it *here*").

Both PRs have been updated accordingly, and the PEP PR has been merged.

--

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



[issue37398] contextlib.ContextDecorator decorating async functions

2019-08-09 Thread Nick Coghlan


Nick Coghlan  added the comment:

I wouldn't be OK with magic switching in the behaviour of ContextDecorator 
(that's not only semantically confusing, it's also going to make the contextlib 
function wrappers even slower than they already are).

I'm also entirely unclear on what you would expect a synchronous context 
manager to do when applied to an asynchronous function, as embedding an "await" 
call inside a synchronous with statement is unlikely to end well.

--

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



[issue37636] Deprecate slicing and ordering operations on sys.version

2019-08-09 Thread Nick Coghlan


Nick Coghlan  added the comment:

Regarding the "Would releasing 4.0 instead avoid problems?" Anthony actually 
did that experiment, too: it broke third party projects even more impressively 
than the 3.10 build did.

I think Serhiy's point is fairly compelling though - check whether or not 
pylint checks for this, and then close this issue with either a pointer to 
their documentation, or else a pointer to a feature request on their issue 
tracker.

--

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



[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-05 Thread Nick Coghlan


Nick Coghlan  added the comment:

I believe our main motivation for separating it out was the fact that even 
though TargetScopeError is a compile-time error, the affected code is 
syntactically fine - there are just issues with unambiguously inferring the 
intended read/write location for the affected target names. (Subclassing 
SyntaxError is then a pragmatic concession to the fact that "SyntaxError" also 
de facto means "CompilationError")

Searching for "Python TargetScopeError" will also get folks to relevant 
information far more quickly than searching for "Python SyntaxError" will.

Pre-seeding Stack Overflow with an answer to "What does TargetScopeError mean 
in Python?" would probably be a good idea though (similar to what I did for 
https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python
 )

--

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



[issue35224] PEP 572: Assignment Expressions

2019-08-05 Thread Nick Coghlan


Nick Coghlan  added the comment:

Proposed PEP update is here: https://github.com/python/peps/pull/1140

The update also aims to clarify *why* we're doing the extra work in CPython's 
compiler to make these cases fail (i.e. we don't want to implicitly impose the 
current CPython runtime behaviour on other implementations)

--

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



[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-05 Thread Nick Coghlan


Nick Coghlan  added the comment:

Added a PEP update as well: https://github.com/python/peps/pull/1140

--

___
Python tracker 
<https://bugs.python.org/issue37757>
___
___
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   >