date:20200507



Raymond Hettinger  added the comment:

Thanks for producing the comparison panel.  In side-by-side views, 
python_bold.png looks best to me with asdl2.png as a close second.

--

___
Python tracker 

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

[issue40543] Tamil locale is using outdated encoding

2020-05-07 Thread Muthu A



New submission from Muthu A :

Tamil locale (TA_IN, TA_SL, TA_SG, TA_MY) is using outdated encoding of TSCII. 
Tamil community is widely using UTF-8 encoding.
Further, the 'locale' standard library package in Python3 should be updated 
with these strings.

Should the maintainers desire assistance on this task, as a native speaker of 
the language, I can propose a patch or recommed other native speakers for this 
task.

--
files: Screen Shot 2020-05-06 at 11.04.18 PM.png
messages: 368325
nosy: Muthu A
priority: normal
severity: normal
status: open
title: Tamil locale is using outdated encoding
Added file: https://bugs.python.org/file49137/Screen Shot 2020-05-06 at 
11.04.18 PM.png

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



New submission from Julien Danjou :

The function _PyErr_GetTopmostException() is not exported and is useful to get 
access to exceptions info from a PyThreadState.

--
components: C API
messages: 368327
nosy: jd
priority: normal
severity: normal
status: open
title: Expose _PyErr_GetTopmostException
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



Change by Julien Danjou :


--
keywords: +patch
pull_requests: +19292
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19977

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



Change by STINNER Victor :


--
nosy: +vstinner
nosy_count: 1.0 -> 2.0
pull_requests: +19293
pull_request: https://github.com/python/cpython/pull/19978

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



STINNER Victor  added the comment:

The function was added by:

commit ae3087c6382011c47db82fea4d05f8bbf514265d
Author: Mark Shannon 
Date:   Sun Oct 22 22:41:51 2017 +0100

Move exc state to generator. Fixes bpo-25612 (#1773)

Move exception state information from frame objects to coroutine 
(generator/thread) object where it belongs.

Python 3.9 is now built with -fvisibility=hidden, bpo-11410:

commit 0b60f64e4343913b4931dc27379d9808e5b78fe1
Author: Vinay Sajip 
Date:   Tue Oct 15 08:26:12 2019 +0100

bpo-11410: Standardize and use symbol visibility attributes across POSIX 
and Windows. (GH-16347)

It means that functions which are not explicitly exported are no longer 
exported.

So yeah, _PyErr_GetTopmostException() symbol is not properly exported.

But the function remains private. IMHO if someone wants to add a *public* 
function, it should return a *strong* reference to the 3 variables (exc type, 
exc value, exc tb).

See also bpo-39947: "[C API] Make the PyThreadState structure opaque (move it 
to the internal C API)". I added multiple public getters for PyThreadState 
structure in Python 3.9.

--

___
Python tracker 

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

[issue39573] [C API] Make PyObject an opaque structure in the limited C API

2020-05-07 Thread Zackery Spytz



Change by Zackery Spytz :


--
nosy: +ZackerySpytz
nosy_count: 8.0 -> 9.0
pull_requests: +19294
pull_request: https://github.com/python/cpython/pull/19975

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

2020-05-07 Thread Pablo Galindo Salgado



Pablo Galindo Salgado  added the comment:


New changeset 2f37c355ab0e9ec9c1753985d27c41fa0bd719b9 by Lysandros Nikolaou in 
branch 'master':
bpo-40334: Fix error location upon parsing an invalid string literal (GH-19962)
https://github.com/python/cpython/commit/2f37c355ab0e9ec9c1753985d27c41fa0bd719b9


--

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

2020-05-07 Thread Pablo Galindo Salgado



Pablo Galindo Salgado  added the comment:


New changeset 4638c6429575bd6de26b12b2af5df74d6568b553 by Lysandros Nikolaou in 
branch 'master':
bpo-40334: Error message for invalid default args in function call (GH-19973)
https://github.com/python/cpython/commit/4638c6429575bd6de26b12b2af5df74d6568b553


--

___
Python tracker 

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

[issue40517] Syntax highlighting for ASDL



Batuhan Taskaya  added the comment:

I've found a bold dark blue, which I guess suits both your and @terry.reedy 
recommendations. How does bold_dark_blue.png looks?

--
Added file: https://bugs.python.org/file49138/bold_dark_blue.png

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



Julien Danjou  added the comment:

I would definitely love to have a public API for this.

Would `PyErr_GetTopmostException` be a good candidate for this?

(I can open a different bug report if needed)

--

___
Python tracker 

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

[issue40541] Add optional weights parameter to random.sample()

2020-05-07 Thread Mark Dickinson



Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue40541] Add optional weights parameter to random.sample()

2020-05-07 Thread Mark Dickinson



Mark Dickinson  added the comment:

+1 for the functionality.

How about "counts" instead of "weights"?

I found the name "weights" misleading - my first thought was that this would be 
doing a weighted sampling without replacement (like NumPy's `random.choice(..., 
replace=False, p=weights)`).

Of course, now I've read the docs, I know better.

--

___
Python tracker 

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

[issue39562] Asynchronous comprehensions don't work in asyncio REPL



STINNER Victor  added the comment:

I reopen the bug to ensure that the fix will land into Python 3.8.3. The issue 
is marked as release blocker.

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue40542] path environment variable not created correctly

2020-05-07 Thread Steve Dower



Steve Dower  added the comment:

Yes, it is bad behaviour, but it is very upsetting for many people to not have 
the option. This is why it's disabled by default, and why I regularly 
discourage people from selecting the option (and quite often get abused for 
taking the trouble... oh well... that's apparently how open-source life works 
these days).

If you install just for the current user, it will only appear ahead of the 
user's own PATH entries, which are stored separately from the system ones and 
concatenated automatically (unless the whole thing exceeds a certain length, in 
which case you just lose PATH entries... another reason to avoid it).

Adding to the end of the PATH would leave people broken and confused as any 
other install of Python would still take precedence. So to minimize breakage, 
it goes to the front, but the per-user install is the default.

So thanks for the support, but unfortunately we don't have any viable way to 
move forward on it. Tell people not to add to PATH and to run py.exe instead - 
which we've been doing for years, but it doesn't really have much effect.

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

___
Python tracker 

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

[issue37339] os.path.ismount returns true on nested btrfs subvolumes

2020-05-07 Thread Eike Fokken



Eike Fokken  added the comment:

Ok,
this is my proposal for the documentation. I hope you like it.

Is this the correct place to post it or can I make a direct pull request?
old:
.. function:: ismount(path)

   Return ``True`` if pathname *path* is a :dfn:`mount point`: a point in a file
   system where a different file system has been mounted.  The function checks
   whether *path*'s parent, :file:`path/..`, is on a different device than 
*path*,
   or whether :file:`path/..` and *path* point to the same i-node on the same
   device --- this should detect mount points for all Unix and POSIX variants.


new:
.. function:: ismount(path)

   Return ``True`` if pathname *path* is a :dfn:`mount point`: a point in a file
   system where a different file system has been mounted.  The function checks
   whether *path*'s parent, :file:`path/..`, is on a different device than 
*path*,
   or whether :file:`path/..` and *path* point to the same i-node on the same
   device --- this should detect mount points for all Unix and POSIX variants.
   Note that in Linux not all mountpoints as recognized by the kernel are found 
this way.
   An example are bind-mounts.
   Also some directories return ``True`` although Linux doesn't recognize them 
as mount points.
   An example are nested subvolumes in the Btrfs filesystem

--

___
Python tracker 

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

[issue38787] PEP 573: Module State Access from C Extension Methods



STINNER Victor  added the comment:


New changeset e1becf46b4e3ba6d7d32ebf4bbd3e0804766a423 by Petr Viktorin in 
branch 'master':
bpo-38787: C API for module state access from extension methods (PEP 573) 
(GH-19936)
https://github.com/python/cpython/commit/e1becf46b4e3ba6d7d32ebf4bbd3e0804766a423


--

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



STINNER Victor  added the comment:


New changeset 8963a7f1f84a05412178b56629508b660d38861b by Victor Stinner in 
branch 'master':
bpo-40545: Export _PyErr_GetTopmostException() function (GH-19978)
https://github.com/python/cpython/commit/8963a7f1f84a05412178b56629508b660d38861b


--

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



STINNER Victor  added the comment:

> I would definitely love to have a public API for this.

I'm not sure if it's a good idea. It's kind of semi-internal.

Stephan Behnel and Mark Shannon: What do you think of exposing PyThreadState 
exception stack (exc_state)? Especially the "top" exception. If I recall 
correctly, Mark designed it and Stephan "reimplemented" it in Cython.

I also recall a minor issue in greenlet:
https://github.com/python-greenlet/greenlet/pull/132

--
nosy: +Mark.Shannon, scoder

___
Python tracker 

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

[issue31033] Add argument to .cancel() of Task and Future

2020-05-07 Thread Chris Jerdonek



Change by Chris Jerdonek :


--
pull_requests: +19295
pull_request: https://github.com/python/cpython/pull/19979

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



Mark Shannon  added the comment:

What's wrong with `PyErr_GetExcInfo()` for accessing the current exception?

Victor, would you revert https://github.com/python/cpython/pull/19978 until we 
decide what to do. Thanks.

--

___
Python tracker 

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

[issue40228] Make setting line number in frame more robust.



Change by Mark Shannon :


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

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



Julien Danjou  added the comment:

PyErr_GetExcInfo() does not allow to specify a PyThreadState as argument.

--

___
Python tracker 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API



Mark Shannon  added the comment:

"maybe a few setter functions as well"
Please don't add any setter functions, that would a major change to the VM and 
would need a PEP.

Also, could you remove PyFrame_GetLastInstr(PyFrameObject *frame)?
The only purpose of `f_lasti` is to get the line number and that can be done 
directly via `PyFrame_GetLineNumber(PyFrameObject *frame)`

Perhaps Stefan can tell us why Cython needs to access the internals of the 
frame object.

--
nosy: +Mark.Shannon, scoder

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



Mark Shannon  added the comment:

Why do you need to specify a `PyThreadState`?

--

___
Python tracker 

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

[issue40517] Syntax highlighting for ASDL

2020-05-07 Thread Zachary Ware



Zachary Ware  added the comment:

I say merge it :)

--
nosy: +zach.ware

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



STINNER Victor  added the comment:

> Why do you need to specify a `PyThreadState`?

>From past issues, I understood that Julien's use case is a profiler which 
>inspects memory without calling functions nor switching to other threads. It's 
>like "dump the state of all Python threads".

I'm fine with exposing _PyErr_GetTopmostException() as a *private* function.  
Moreover, the function was already exposed in 3.8. It was not exposed because 
of the visibility change which was made in 3.9.

--

___
Python tracker 

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

[issue18319] gettext() cannot find translations with plural forms

2020-05-07 Thread Gilles Bassière


Gilles Bassière  added the comment:

Hi there,

I worked on a patch for this issue (see attached pull request).

I would be happy to discuss it with people involved in gettext module 
maintenance but I'm not sure how to contact them. Is there a dedicated mailing 
list or an IRC channel or something? I've found i18n-sig but it has been 
inactive for 5 years...

Best regards
Gilles

--

___
Python tracker 

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

[issue40542] path environment variable not created correctly

2020-05-07 Thread Zachary Ware



Zachary Ware  added the comment:

Just a note to add my full support for what Steve said.  PATH is frequently 
abused on Windows, and we only have the option at all because people become 
unreasonably upset if it's not there.  I wouldn't be against adding a "you 
don't actually want this, use py.exe" note to the option, though :)

--

___
Python tracker 

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

[issue40545] Expose _PyErr_GetTopmostException



Julien Danjou  added the comment:

I confirm what Victor wrote. :)

--

___
Python tracker 

___
___
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 

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

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API



STINNER Victor  added the comment:

> Please don't add any setter functions, that would a major change to the VM 
> and would need a PEP.

There is no such "major change". PyFrameObject structure was fully exposed in 
the public C API since the earliest Python version.

I don't see how adding setter is a major change, since it's already possible to 
directly modify *any* field of PyFrameObject without any kind of protection.

My plan is to have two milestones:

A) Make the structure opaque, so it's not longer possible to directly access it.

B) Deprecate or remove a few getter or setter functions, or move them to the 
internal C API.


I don't think that moving directly to step (B) is a realistic migration plan. 
So far, nobody analyzed all C extensions on PyPI to see how PyFrameObject is 
accessed.

I prefer to move slowly, step by step.

Breaking C extensions which currently *modify* directly PyFrameObject on 
purpose doesn't seem like a reasonable option to me.

--

I'm trying to distinguish functions which should be "safe"/"portable" from the 
ones which may be too "CPython specific":

* I added Include/pyframe.h which is included by Include/Python.h for 
"safe"/"portable" functions:

  * PyFrame_GetLineNumber()
  * PyFrame_GetCode()

* All other functions are added to Include/cpython/frameobject.h which is 
excluded from the limited C API:

  * PyFrame_GetBack()

Note: Compared to accessing directly PyFrameObject.f_code, PyFrame_GetCode() 
also avoids the issue of borrowed references since it returns a strong 
reference.

PyFrame_GetBack() looks specific to the current implementation of CPython. 
Another implementation might decide to not chain frames. Or maybe don't provide 
an easy way to traverse the chain of frames. Or at least, it might be a 
different API than PyFrame_GetBack().

--

> Also, could you remove PyFrame_GetLastInstr(PyFrameObject *frame)?

I didn't add it :-) It's the pending PR 19764.

I didn't merge it since it's unclear to me if it's a good idea to directly 
expose it or not. Cython uses it, but Cython also abuses CPython internals in 
general, usually for best performances :-)

*Maybe* one compromise would be to add a private _PyFrame_GetLastInstr() to 
ease migration to step (A) (replace direct access to the structure with 
function calls).

--

___
Python tracker 

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

[issue38131] compile(mode='eval') uninformative error message



Batuhan Taskaya  added the comment:

I've updated PR 17715 in order to point out exact field that error happened. 
Also it now only shows type

>>> import ast
>>> expr_without_lineno_but_ok = 
>>> ast.Expression(body=ast.BinOp(left=ast.Num(n=2), right=ast.Num(n=2), 
>>> op=ast.Add()))
>>> expr_with_lineno_but_with_wrong_body = 
>>> ast.Expression(body=[ast.BinOp(left=ast.Num(n=2), right=ast.Num(n=2), 
>>> op=ast.Add())])
>>> ast.fix_missing_locations(expr_with_lineno_but_with_wrong_body)

>>> compile(expr_without_lineno_but_ok, "", "eval")
Traceback (most recent call last):
  File "", line 1, in 
TypeError: required field "lineno" missing from expr
>>> compile(expr_with_lineno_but_with_wrong_body, "", "eval")
Traceback (most recent call last):
  File "", line 1, in 
TypeError: For field 'body'; expected expr type node, got list

--

___
Python tracker 

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

[issue40517] Syntax highlighting for ASDL



Batuhan Taskaya  added the comment:

I've updated the PR with bold_dark_blue.png changes.

--

___
Python tracker 

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

[issue38787] PEP 573: Module State Access from C Extension Methods

2020-05-07 Thread hai shi



Change by hai shi :


--
pull_requests: +19296
pull_request: https://github.com/python/cpython/pull/19980

___
Python tracker 

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

[issue40546] Inconsistencies between pegen and traceback SyntaxErrors


New submission from Lysandros Nikolaou :

Since traceback is programmed to match the SyntaxErrors emitted by the old 
parser, there are some inconsistencies between how it formats SyntaxErrors and 
how the new parser does it. One example for such behaviour is the following:

New Parser:
╰─ ./python.exe
Python 3.9.0a6+ (heads/master:4638c64295, May  7 2020, 16:47:53)
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 1 | 2 |
  File "", line 1
x = 1 | 2 |
   ^
SyntaxError: invalid syntax

Old parser and traceback module:
╰─ ./python.exe -X oldparser
Python 3.9.0a6+ (heads/master:4638c64295, May  7 2020, 16:47:53)
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 1 | 2 |
  File "", line 1
x = 1 | 2 |
  ^
SyntaxError: invalid syntax

We actually think that the new parser does a better job here, since there is 
nothing wrong with the `|` itself, the error is that a newline follows it and 
that's where the caret should point to.

Tests that are testing this are currently skipped. I think we should change 
traceback to match the new parser, wherever we think the new parser does a 
better job, and "unskip" these tests.

--
components: Library (Lib)
messages: 368353
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Inconsistencies between pegen and traceback SyntaxErrors
type: behavior
versions: Python 3.9

___
Python tracker 

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

[issue40546] Inconsistencies between PEG parser and traceback SyntaxErrors



Change by Lysandros Nikolaou :


--
title: Inconsistencies between pegen and traceback SyntaxErrors -> 
Inconsistencies between PEG parser and traceback SyntaxErrors

___
Python tracker 

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

[issue40546] Inconsistencies between PEG parser and traceback SyntaxErrors



Change by Batuhan Taskaya :


--
nosy: +BTaskaya

___
Python tracker 

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

[issue37132] Add a module for integer related math functions

2020-05-07 Thread Mark Dickinson



Mark Dickinson  added the comment:

See also #40028

--

___
Python tracker 

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

[issue40547] 2to3 raise can silently remove code from old 2.4 string exceptions

2020-05-07 Thread Rémy Oudompheng


New submission from Rémy Oudompheng :

When running "2to3 -f raise" on the following code, which uses an old Python 
2.4 raise of a string:

def f():
raise ("message %s %s" % (1, 2))

try:
f()
finally:
pass

I obtain the following quite surprising result. I would have expected to get 
either an error or leave the original file unchanged, because "raise (s)" is 
syntactically valid although incorrect. 

$ 2to3 -f raise w.py
RefactoringTool: Refactored w.py
--- w.py(original)
+++ w.py(refactored)
@@ -1,5 +1,5 @@
 def f():
-raise ("message %s %s" % (1, 2))
+raise "message %s %s"
 
 try:
 f()

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 368355
nosy: Rémy Oudompheng
priority: normal
severity: normal
status: open
title: 2to3 raise can silently remove code from old 2.4 string exceptions
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue38787] PEP 573: Module State Access from C Extension Methods



STINNER Victor  added the comment:


New changeset c068b53a0ca6ebf740d98e422569d2f705e54f93 by Hai Shi in branch 
'master':
bpo-38787: Update structures.rst docs (PEP 573) (GH-19980)
https://github.com/python/cpython/commit/c068b53a0ca6ebf740d98e422569d2f705e54f93


--

___
Python tracker 

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

[issue40548] Always run GitHub action jobs, even on documentation-only jobs



New submission from STINNER Victor :

bpo-39837 made Azure Pipelines CI non-mandatory. Travis CI was made mandatory 
to have at least one mandatory job: 
https://github.com/python/core-workflow/issues/365

I would prefer to have at least one mandatory Windows CI running on Python pull 
requests. Before we had pre-commit checks, it was too common to break Windows. 
I would prefer to not regress on that aspect.

--

Currently, GitHub action jobs ignore "documentation-only" changes. Extract of 
.github/workflows/build.yml:

on:
  push:
branches:
- master
- 3.8
- 3.7
paths-ignore:
- 'Doc/**'
- 'Misc/**'
- '**/*.md'
- '**/*.rst'

If a job is marked as mandatory but the GitHub action is skipped because of 
paths-ignore, the PR cannot be merged :-( It seems to be a known GitHub 
limitation which is not going to be fixed soon:
https://discuss.python.org/t/make-one-windows-ci-job-mandatory/4047/6

To workaround is to always run GitHub action jobs, even on documentation-only 
jobs.

I propose to always run GitHub actions and then make the Windows (64 bit) job 
mandatory.

--

Sadly, it will waste resources for documentation-only jobs. To avoid that, the 
Windows job can be modified later to be skipped if it detects that the PR is a 
documentation-only change.

Steve Dower wrote:
"That workaround looks roughly like what is in the Azure Pipelines files. 
Someone just needs the time to go and migrate it."
https://discuss.python.org/t/make-one-windows-ci-job-mandatory/4047/6

Note: the Travis CI job (.travis.yml) uses the following check:

  # Pull requests are slightly complicated because $TRAVIS_COMMIT_RANGE
  # may include more changes than desired if the history is convoluted.
  # Instead, explicitly fetch the base branch and compare against the
  # merge-base commit.
  git fetch -q origin +refs/heads/$TRAVIS_BRANCH
  changes=$(git diff --name-only HEAD $(git merge-base HEAD FETCH_HEAD))
  echo "Files changed:"
  echo "$changes"
  if ! echo "$changes" | grep -qvE '(\.rst$)|(^Doc)|(^Misc)'
  then
echo "Only docs were updated, stopping build process."
exit
  fi

--

More background on these CI issues:

* https://bugs.python.org/issue39837
* https://github.com/python/core-workflow/issues/365
* https://discuss.python.org/t/make-one-windows-ci-job-mandatory/4047

--
components: Build
messages: 368357
nosy: vstinner
priority: normal
severity: normal
status: open
title: Always run GitHub action jobs, even on documentation-only jobs
versions: Python 3.9

___
Python tracker 

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

[issue40548] Always run GitHub action jobs, even on documentation-only jobs

[issue39837] Make Azure Pipelines optional on GitHub PRs



STINNER Victor  added the comment:

I created a follow-up issue to have again a mandatory Windows pre-commit CI: 
bpo-40548.

--

___
Python tracker 

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

[issue40548] Always run GitHub action jobs, even on documentation-only jobs


Filipe Laíns  added the comment:

The workaround presented at 
https://github.community/t5/GitHub-Actions/Feature-request-conditional-required-checks/m-p/51344/highlight/true#M8157
 seems pretty reasonable. And it seems like travis is alerady doing the same 
thing as it doesn't have native support to skip runs based on path changes.

I can open a PR if you want.

--
nosy: +FFY00

___
Python tracker 

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

[issue40546] Inconsistencies between PEG parser and traceback SyntaxErrors



Guido van Rossum  added the comment:

I don't understand why the traceback module is implicated. It just formats the 
information in the SyntaxError object, same as the builtin printing for syntax 
errors. The key difference is always in what line/column/text is put in the 
SyntaxError object by whichever parser is being used.

In the past there was some misunderstanding about whether column numbers are 
0-based (the leftmost column is numbered 0) or 1-based (the leftmost column is 
numbered 1), and at some point we discovered there was an inconsistency -- 
certain parts of the code put 0-based offsets in the SyntaxError object and 
other parts put 1-based offsets.

We then decided that the SyntaxError column offset should be 1-based and 
changed various bits of code to match. It's however possible that we forgot 
some. It's also still not clearly documented (e.g. the stdlib docs for 
SyntaxError don't mention it).

What complicates matters further is that the lowest-level C code in the 
tokenizer definitely uses 0-based offsets, which means that whenever we create 
a SyntaxError we have to add 1 to the offset. (You can see this happening if 
you look at various calls to PyErr_SyntaxLocationObject().)

--

___
Python tracker 

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

[issue40548] Always run GitHub action jobs, even on documentation-only jobs



STINNER Victor  added the comment:

> The workaround presented at 
> https://github.community/t5/GitHub-Actions/Feature-request-conditional-required-checks/m-p/51344/highlight/true#M8157
>  seems pretty reasonable. And it seems like travis is alerady doing the same 
> thing as it doesn't have native support to skip runs based on path changes.

I suppose that Steve Dower mentioned the following part of 
.azure-pipelines/prebuild-checks.yml:

- script: |
   if ! git diff --name-only $(diffTarget) | grep -qvE '(\.rst$|^Doc|^Misc)'
   then
 echo "Only docs were updated: tests.run=false"
 echo "##vso[task.setvariable variable=run;isOutput=true]false"
   else
 echo "Code was updated: tests.run=true"
 echo "##vso[task.setvariable variable=run;isOutput=true]true"
   fi
  displayName: Detect source changes
  name: tests


I understood that he proposed to port it inside the Windows job of GitHub 
actions (.github/workflows/build.yml).

I propose the following plan:

* Always run GitHub Action jobs
* Make Windows 64-bit job mandatory
* And only then try to skip documentation-only changes

--

___
Python tracker 

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

[issue40549] Convert posixmodule.c to multiphase initialization (PEP 489)



New submission from STINNER Victor :

Attached PR converts posixmodule.c to multiphase initialization (PEP 489).

It uses the new shiny PyType_FromModuleAndSpec() and PyType_GetModule() of the 
PEP 573 added by bpo-38787.

The PR removes the following macro :-)

#define _posixstate_global ((_posixstate 
*)PyModule_GetState(PyState_FindModule(&posixmodule)))

--
components: Interpreter Core
messages: 368362
nosy: vstinner
priority: normal
severity: normal
status: open
title: Convert posixmodule.c to multiphase initialization (PEP 489)
versions: Python 3.9

___
Python tracker 

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

[issue40546] Inconsistencies between PEG parser and traceback SyntaxErrors



Guido van Rossum  added the comment:

For example:

raise SyntaxError("message", ("", 1, 3, "text"))
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
text
  ^
SyntaxError: message
>>> 

(I can't find docs for the constructor of SyntaxError objects. We should update 
the docs.)

--

___
Python tracker 

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

[issue40549] Convert posixmodule.c to multiphase initialization (PEP 489)



Change by STINNER Victor :


--
keywords: +patch
pull_requests: +19298
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19982

___
Python tracker 

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

[issue40546] Inconsistencies between PEG parser and traceback SyntaxErrors


Lysandros Nikolaou  added the comment:

Guido:
> I don't understand why the traceback module is implicated.

The traceback module is implicated, because it currently does not allow the 
caret to point to a position after the error line.

In format_exception_only there is the following snippet of code:

if offset is not None:
caretspace = badline.rstrip('\n')
offset = min(len(caretspace), offset) - 1
caretspace = caretspace[:offset].lstrip()
# non-space whitespace (likes tabs) must be kept for alignment
caretspace = ((c.isspace() and c or ' ') for c in caretspace)
yield '{}^\n'.format(''.join(caretspace))

There are two things here, that put together contradict the way that pegen 
reports errors. `badline` gets rstripped and then the offset is changed to 
point to the end of the string, in case it is currently pointing after its end. 
That basically does not allow SyntaxErrors to be formatted the way they 
currently are, when using the new parser.

For example:
╰─ ./python.exe
Python 3.9.0a6+ (heads/master:4638c64295, May  7 2020, 16:47:53)
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 1 | 2 |
  File "", line 1
x = 1 | 2 |
   ^
SyntaxError: invalid syntax

But:
╰─ ./python.exe
Python 3.9.0a6+ (heads/master:4638c64295, May  7 2020, 16:47:53)
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import traceback
>>> try:
... exec('x = 1 | 2 |')
... except SyntaxError as se:
... exc = se
...
>>> traceback.print_exception(type(exc), exc, exc.__traceback__)
Traceback (most recent call last):
  File "", line 2, in 
  File "", line 1
x = 1 | 2 |
  ^
SyntaxError: invalid syntax

I might be missing something here, but I think that that's the traceback 
module's "fault".

--

___
Python tracker 

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

[issue40178] Convert the remaining os funtions to Argument Clinic

2020-05-07 Thread Serhiy Storchaka



Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue40548] Always run GitHub action jobs, even on documentation-only jobs


Change by Filipe Laíns :


--
pull_requests: +19299
pull_request: https://github.com/python/cpython/pull/19983

___
Python tracker 

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

[issue40528] Improve / Clear ASDL generator



Batuhan Taskaya  added the comment:

Next is using asdl_int_seq for all simple sum types, and not for only cmpop. 
Looks like it is hardcoded to use it, and I plan to refactor this in a way that 
might save some time in python implementation of classes (also it will solve 
this bug). For not conflicting, I'll wait GH 19968.

--

___
Python tracker 

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

[issue40548] Always run GitHub action jobs, even on documentation-only jobs


Filipe Laíns  added the comment:

> * And only then try to skip documentation-only changes

Done :)

--

___
Python tracker 

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

[issue40397] Refactor typing._GenericAlias

2020-05-07 Thread Serhiy Storchaka



Serhiy Storchaka  added the comment:

The next PR removes __args__ and __parameters__ from _SpecialGenericAlias.

* No existing test is failed. It is an evidence that these attributes are not 
intended, but a side effect of mixing two different kinds in one class.

* get_args() ignores __args__ and returns () for _SpecialGenericAlias (after 
resolving issue40398).

* Nested _SpecialGenericAlias is not considered a generic class containing type 
variables:

>>> from typing import *
>>> T = TypeVar('T')
>>> Dict[int, List[T]][str]
typing.Dict[int, typing.List[str]]
>>> Dict[int, List][str]
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython-release/Lib/typing.py", line 244, in inner
return func(*args, **kwds)
  File "/home/serhiy/py/cpython-release/Lib/typing.py", line 695, in __getitem__
_check_generic(self, params)
  File "/home/serhiy/py/cpython-release/Lib/typing.py", line 194, in 
_check_generic
raise TypeError(f"{cls} is not a generic class")
TypeError: typing.Dict[int, typing.List] is not a generic class

It also fixes the following error:

>>> from typing import *
>>> T = TypeVar('T')
>>> Dict[T, List][str]
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython-release/Lib/typing.py", line 241, in inner
return cached(*args, **kwds)
  File "/home/serhiy/py/cpython-release/Lib/typing.py", line 703, in __getitem__
subargs = tuple(subst[x] for x in arg.__parameters__)
  File "/home/serhiy/py/cpython-release/Lib/typing.py", line 703, in 
subargs = tuple(subst[x] for x in arg.__parameters__)
KeyError: ~T

and allows to simplify __eq__ and __hash__ for _SpecialGenericAlias. Currently 
it has a weird behavior in corner case:

>>> from typing import *
>>> from typing import T
>>> List == List[T]
True

--

___
Python tracker 

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

[issue40397] Refactor typing._GenericAlias

2020-05-07 Thread Serhiy Storchaka



Change by Serhiy Storchaka :


--
pull_requests: +19300
pull_request: https://github.com/python/cpython/pull/19984

___
Python tracker 

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

[issue40546] Inconsistencies between PEG parser and traceback SyntaxErrors



Guido van Rossum  added the comment:

Aha! So the traceback module does have a difference.

First, if the offset points inside the text, there's no difference:

>>> raise SyntaxError("message", ("", 1, 4, "text"))
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
text
   ^
SyntaxError: message
traceback.print_exception(SyntaxError, SyntaxError("message", ("", 1, 4, 
"text")), None)
  File "", line 1
text
   ^
SyntaxError: message
>>> 

But if the offset points past the text, there's a difference:

>>> raise SyntaxError("message", ("", 1, 5, "text"))
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
text
^
SyntaxError: message
>>> traceback.print_exception(SyntaxError, SyntaxError("message", ("", 1, 
>>> 5, "text")), None)
  File "", line 1
text
   ^
SyntaxError: message
>>> 

And even:

>>> raise SyntaxError("message", ("", 1, 10, "text"))
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
text
 ^
SyntaxError: message
>>> traceback.print_exception(SyntaxError, SyntaxError("message", ("", 1, 
>>> 10, "text")), None)
  File "", line 1
text
   ^
SyntaxError: message
>>> 

I wonder if we need to support the final case? It seems clear to me that if the 
col_offset points just past the text, we should display a caret just past the 
text. (I wonder if this might be an off-by-one issue caused by confusion about 
0-based vs. 1-based offsets.)

But if the col_offset points way past the text, what should happen? The 
clipping there seems reasonable.

--

___
Python tracker 

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

[issue39685] Python 3.8 regression Socket operation on non-socket

2020-05-07 Thread hillpd


hillpd  added the comment:

Blocking the use of stdin/stdout like this looks intentional. I have added 
dimaqq and asvetlov for comment.

The python docs [0] indicate that the file descriptor should be a socket:
"The file descriptor should refer to a socket, but this is not checked — 
subsequent operations on the object may fail if the file descriptor is invalid."

With bpo-35415, the fd is explicitly checked.

[0] https://docs.python.org/3/library/socket.html#socket.fromfd

--
nosy: +Dima.Tisnek, asvetlov, hillpd

___
Python tracker 

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

[issue40550] Popen.terminate fails with ProcessLookupError under certain conditions

2020-05-07 Thread Alexander Overvoorde



New submission from Alexander Overvoorde :

The following program frequently raises a ProcessLookupError exception when 
calling proc.terminate():

```
import threading
import subprocess
import multiprocessing

proc = subprocess.Popen(["sh", "-c", "exit 0"])

q = multiprocessing.Queue()

def communicate_thread(proc):
proc.communicate()

t = threading.Thread(target=communicate_thread, args=(proc,))
t.start()

proc.terminate()

t.join()
```

I'm reproducing this with Python 3.8.2 on Arch Linux by saving the script and 
rapidly executing it like this:

$ bash -e -c "while true; do python3 test.py; done

The (unused) multiprocessing.Queue seems to play a role here because the 
problem vanishes when removing that one line.

--
components: Library (Lib)
messages: 368370
nosy: Alexander Overvoorde
priority: normal
severity: normal
status: open
title: Popen.terminate fails with ProcessLookupError under certain conditions
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue40551] PRs should be rebased on top of master before running the build/tests


New submission from Filipe Laíns :

Let's imagine this scenario:

(master history)
abcd - some commit
hijk - change something

(pull request history)
abcd - some commit
defg - add feature


  master  pull request

abcd - some commit   ---  defg - add feature
hijk - change something


Currently in the CI we checkout defg and run the tests. If hijk introduces some 
change that breaks defg, we only know about it after defg is in master.

I propose pull requests to be automatically rebased on top of master, so that 
the resulting story becomes:

abcd - some commit
hijk - change something
defg - add feature

Now defg is properly tested :)

This may not be an issue in smaller projects, but in cpython where most things 
are a moving target, it should make a difference. Here I am referring to master 
but applies to all other maintained branches.

Github can't merge if the PR doesn't cleanly rebase to master, or rather, it 
will ask you to resolve conflicts, so I don't think there should be any problem.

Keep in mind that this only works at the time the pull request is created. To 
check against the latest master the build needs to be retriggered, which you 
should be able to do manually.
Even if we don't check against the latest master when the PR is merged, this is 
already an improvement. After this we could look into maybe automatically 
retriggering the CI on approvals, or better, managing merges with a bot.

--
components: Build
messages: 368371
nosy: FFY00
priority: normal
severity: normal
status: open
title: PRs should be rebased on top of master before running the build/tests
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue40548] Always run GitHub action jobs, even on documentation-only jobs



STINNER Victor  added the comment:


New changeset 4e363761fc02a89d53aba4382dc451293bd6f0ba by Victor Stinner in 
branch 'master':
bpo-40548: Always run GitHub action, even on doc PRs (GH-19981)
https://github.com/python/cpython/commit/4e363761fc02a89d53aba4382dc451293bd6f0ba


--

___
Python tracker 

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

[issue40552] Enhance for loop and copy example in tutorial

2020-05-07 Thread Julien Palard



New submission from Julien Palard :

During the past few weeks we got two reports of an example not working in the 
tutorial: [1], [2].


[1]: 
https://mail.python.org/archives/list/d...@python.org/message/ZJM3S2TE5UPFYIII5R4VQ4KY2WN4TKVO/
[2]: 
https://mail.python.org/archives/list/d...@python.org/thread/6FZ55HTMILK4P6EOYLAI7WXAY427NKQU/

Problem is: the example uses a `users` variable that is not defined.

users should be a dict, which is not straightforward for newcomers neither, so 
I propose to define it to:

users = {"Hans": "active", "Andrea": "inactive", "Nils": "active"}

in the example, to make it work.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 368373
nosy: docs@python, mdk
priority: low
severity: normal
status: open
title: Enhance for loop and copy example in tutorial
type: enhancement

___
Python tracker 

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

[issue40541] Add optional weights parameter to random.sample()



Raymond Hettinger  added the comment:

> How about "counts" instead of "weights"?

That makes sense.

--

___
Python tracker 

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

[issue40553] Python 3.8.2 Mac freezing/not responding when saving new programs

2020-05-07 Thread Zain Said



New submission from Zain Said :

What I'm currently using: 
Mid 2012 13'' MacBook Pro OS Catalina 10.15.4
Python 3.8.2

I'm having an issue with saving a new python program. When I go to "save as" a 
program python seems to freeze/not . The only way I've been able to get python 
working again is to "Force Quit" the existing process and reopen IDLE. Running 
and writing existing programs seems to be working fine.

--
messages: 368375
nosy: Zain
priority: normal
severity: normal
status: open
title: Python 3.8.2 Mac freezing/not responding when saving new programs
type: crash
versions: Python 3.8

___
Python tracker 

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

[issue40517] Syntax highlighting for ASDL



Raymond Hettinger  added the comment:


New changeset b7a78ca74ab539943ab11b5c4c9cfab7f5b7ff5a by Batuhan Taskaya in 
branch 'master':
bpo-40517: Implement syntax highlighting support for ASDL (GH-19967)
https://github.com/python/cpython/commit/b7a78ca74ab539943ab11b5c4c9cfab7f5b7ff5a


--

___
Python tracker 

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

[issue40517] Syntax highlighting for ASDL



Raymond Hettinger  added the comment:

Thanks for the contribution.  It looks much nicer than what we had before.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

___
Python tracker 

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

[issue40517] Syntax highlighting for ASDL



Batuhan Taskaya  added the comment:

Thank you all for your reviews for styling, also I have to thank 
https://github.com/CyberSaxosTiGER for his external reviews on the color scheme.

--

___
Python tracker 

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

[issue40553] Python 3.8.2 Mac freezing/not responding when saving new programs



Raymond Hettinger  added the comment:

I frequently have this issue as well.  My workaround is awful:  I go to the 
terminal prompt to create an empty file with the desired name, and then open it 
up in IDLE to edit and save.  This avoids the SaveAs dialog window that 
triggers the failure.

This doesn't happen to me with new, empty directories.  So, my best guess is 
that the document preview in the SaveAs window is triggering the failure.  

This problem may go away in the future with a O/S update or with a Tcl/Tk 
update. AFAICT, IDLE doesn't have any way to ask for a simplified FileDialog 
window.

--
assignee:  -> terry.reedy
components: +IDLE
nosy: +rhettinger, terry.reedy
priority: normal -> high

___
Python tracker 

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

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure



Batuhan Taskaya  added the comment:

Any news about this? Should we revert the commit for 3.9?

--

___
Python tracker 

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

[issue40553] Python 3.8.2 Mac freezing/not responding when saving new programs



Raymond Hettinger  added the comment:

Perhaps we could create an option in the general settings that offers a 
workaround:  open a regular text window to get the filename.  

This wouldn't be as pretty (won't display filenames, offer mouse support, won't 
show file previews), but it would be reliable.

--

___
Python tracker 

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

[issue40554] Add escape to the glossary?

2020-05-07 Thread Julien Palard



New submission from Julien Palard :

Geoff Cutter noticed via docs@ that escape is not defined in the glossary.

I concur with the idea of adding it, opening as an "easy" issue, even if 
finding a good definition might not be that easy.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 368382
nosy: docs@python, mdk
priority: low
severity: normal
status: open
title: Add escape to the glossary?

___
Python tracker 

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

[issue40228] Make setting line number in frame more robust.



STINNER Victor  added the comment:

Windows 64-bit emits a compiler warning on this line:

int len = PyBytes_GET_SIZE(f->f_code->co_code)/sizeof(_Py_CODEUNIT);

Warning:

D:\a\cpython\cpython\Objects\frameobject.c(400,1): warning C4267: 
'initializing': conversion from 'size_t' to 'int', possible loss of data 
[D:\a\cpython\cpython\PCbuild\pythoncore.vcxproj]

Either the code should be rewritten to to Py_ssize_t, or the result should be 
downcasted to int.

Technically, it seems possible to create a code object larger than INT_MAX 
instructors: PyCode_New() has no limit on the bytecode length.

--
nosy: +vstinner

___
Python tracker 

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

[issue40228] Make setting line number in frame more robust.



Change by STINNER Victor :


--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue39881] Multiple Interpreters in the Stdlib (PEP 554) - High-level Implementation

2020-05-07 Thread Joannah Nanjekye



Change by Joannah Nanjekye :


--
pull_requests: +19301
pull_request: https://github.com/python/cpython/pull/19985

___
Python tracker 

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

[issue40548] Always run GitHub action jobs, even on documentation-only jobs



STINNER Victor  added the comment:

> I propose the following plan:
>
> * Always run GitHub Action jobs

Done.

> * Make Windows 64-bit job mandatory

My request: https://github.com/python/core-workflow/issues/368

--

___
Python tracker 

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

[issue40553] Python 3.8.2 Mac freezing/not responding when saving new programs



Ned Deily  added the comment:

Zain and/or Raymond: can you please give the exact steps to reproduce this 
problem, including exactly how you invoke IDLE, the Python version info and 
build date info from the IDLE shell window, the details of exactly how you 
invoke Save As (i.e whether via clicking on the menu bar File menu or instead 
by using a keyboard shortcut like shift-cmd-S. And when the SaveAs window 
appears perhaps a screen shot or at least what options you have selected 
(icons, list, etc, expanded or compressed window) and what is the default 
folder it opens to. I am not able to reproduce a hang although I do see some 
delays. Also what happens if you just use Save for a new file rather than Save 
As? If it's a new file, that should also produce a Save file window and that's 
what I always use when smoke testing.  EIther should work, of course :(

--
nosy: +ned.deily

___
Python tracker 

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

[issue40553] Python 3.8.2 Mac freezing/not responding when saving new programs

2020-05-07 Thread Zain Said



Zain Said  added the comment:

Sure i'll supply a screenshot 
This problem doesn't effect saving in general after editing existing programs 
by the way.
My process of saving a program:
  - I'll open IDLE (Python 3.8.2)
  - write anything at all
  - I'll either hit command>s or click file>save as then ill be prompted to 
name my program and then save as (also if i want to rename an existing program 
the same issue occurs)
  - after typing in the name of the new program ill click save as then most of 
the window goes blank (you'll see in the screenshot)

--
Added file: https://bugs.python.org/file49139/Screen Shot 2020-05-07 at 3.46.02 
PM.png

___
Python tracker 

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

[issue40553] Python 3.8.2 Mac freezing/not responding when saving new programs

2020-05-07 Thread Zain Said



Zain Said  added the comment:

The screenshot link is at the top of the thread

--

___
Python tracker 

___
___
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



STINNER Victor  added the comment:

FYI the autopep8 project uses lib2to3.

--
nosy: +vstinner

___
Python tracker 

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

[issue40550] Popen.terminate fails with ProcessLookupError under certain conditions


Filipe Laíns  added the comment:

This is the backtrace I get:

Traceback (most recent call last):
  File "/home/anubis/test/multiprocessing-error.py", line 16, in 
proc.terminate()
  File "/home/anubis/git/cpython/Lib/subprocess.py", line 2069, in terminate
self.send_signal(signal.SIGTERM)
  File "/home/anubis/git/cpython/Lib/subprocess.py", line 2064, in send_signal
os.kill(self.pid, sig)
ProcessLookupError: [Errno 3] No such process

Is yours the same? This is expected, the process exited before proc.terminate().

You should wrap proc.terminate() in a try..except block:

try:
proc.terminate()
except ProcessLookupError:
pass

I am not sure we want to suppress this.

--
nosy: +FFY00

___
Python tracker 

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

[issue40535] While build python 3.8.2 in linux ctypes.so is using libffi.so.6 instead of libffi.so.7


Filipe Laíns  added the comment:

Which error are you getting? libffi is provided by your distribution.

--
nosy: +FFY00

___
Python tracker 

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

[issue40555] pegen (PEP 617): bug in error handling



New submission from STINNER Victor :

autopep8 test suite does crash on Python 3.9.0a6. The bug can be reproduced 
with:

Python 3.9.0a6+ (heads/master:b7a78ca74a, May  8 2020, 01:46:01) 
[GCC 10.0.1 20200430 (Red Hat 10.0.1-0.14)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> compile('"\\xhh" \\',  '', 'exec', dont_inherit=True)
python: Objects/typeobject.c:984: type_call: Assertion 
`!_PyErr_Occurred(tstate)' failed.
 Abandon (core dumped)

It seems like p->error_condition should be checked more often in 
Parser/pegen/parse.c.

--
components: Interpreter Core
messages: 368391
nosy: gvanrossum, lys.nikolaou, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: pegen (PEP 617): bug in error handling
versions: Python 3.9

___
Python tracker 

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

[issue40555] pegen (PEP 617): bug in error handling



STINNER Victor  added the comment:

Workaround: use python3.9 -X oldparser.

--

___
Python tracker 

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

[issue40546] Inconsistencies between PEG parser and traceback SyntaxErrors


Lysandros Nikolaou  added the comment:

> But if the col_offset points way past the text, what should happen? The 
> clipping there seems reasonable.

Note that if a file is being parsed and not a string the behaviour is this:
╰─ cat -e t.py
x = 1 | 2 |$
╰─ ./python.exe t.py
  File "/Users/lysnikolaou/repos/cpython/t.py", line 1
x = 1 | 2 |
  ^
SyntaxError: invalid syntax
╰─ ./python.exe -X oldparser t.py
  File "/Users/lysnikolaou/repos/cpython/t.py", line 1
x = 1 | 2 |
  ^
SyntaxError: invalid syntax

Would we want to also change this? If not, then I guess that we should as 
closely as possible match this behaviour with strings as well, which means not 
clipping.

--

___
Python tracker 

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

[issue40546] Inconsistencies between PEG parser and traceback SyntaxErrors



Guido van Rossum  added the comment:

Hm, but there the old parser seems at fault: it points to the last space rather 
than beyond it?

--

___
Python tracker 

___
___
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.



STINNER Victor  added the comment:

The commit a1d9e0accd33af1d8e90fc48b34c13d7b07dcf57 introduced reference leaks:

$ ./python -m test -R 3:3 test__xxsubinterpreters -m 
test.test__xxsubinterpreters.RunFailedTests.test_traceback_propagated
(...)
test__xxsubinterpreters leaked [1863, 1861, 1863] references, sum=5587
test__xxsubinterpreters leaked [559, 558, 559] memory blocks, sum=1676
(...)

--
nosy: +vstinner

___
Python tracker 

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

[issue40555] pegen (PEP 617): bug in error handling

2020-05-07 Thread Pablo Galindo Salgado



Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +19302
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19986

___
Python tracker 

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

[issue40555] pegen (PEP 617): bug in error handling



Lysandros Nikolaou  added the comment:

That's because we're not checking for errors after a loop is done. Pushing a 
fix.

--

___
Python tracker 

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

[issue39685] Python 3.8 regression Socket operation on non-socket

2020-05-07 Thread Dima Tisnek

Dima Tisnek added the comment:

The code in question is interesting... I don't claim to understand it.

A pair of file descriptors is passed wrapped in sockets, and the objects are
used here:

https://github.com/sshuttle/sshuttle/blob/966fd0c5231d56c4f464752865d96f97bd3c0aac/sshuttle/ssnet.py#L238-L240

* s.setblocking(False)
* os.read(s.fileno())
* select.select([s], [s], ...) elsewhere in the file
* s.shutdown() elsewhere in the file

server.py uses Mux() with a pair of os.stdin/stdout, realistically pty/pipe/file
client.py uses Mux() with [an anonymous domain] socket from socketpair()

So, on one hand, it is used like a socket, on the other, it's used as a holder
for a file-like file descriptor 🤷‍♂️

Back in the day, I too wrote (C) code that treated file/tty and socket file
descriptors alike. I've since come to realise that's not exactly correct. IIRC
doing so was elegant, UNIX-y, but implied platform specifics, i.e. was not
cross-platform.

I've also done similar tricks with serial.Serial before: instantiate but don't
open, set pty fd, use to test code that expects a serial port in memory.
Luckily that code was not open-source ☺️. It was a hack, but I don't know if
it's cpython's job to support hacks of this kind.

My 2c:
Personally, I'd rather see the this "fixed" in sshuttle than in cpython.
Perhaps someone with authority over the socket module can weight the balance
between "a regression because using socket.socket as a container for generic
file descriptors used to work before" vs. "least surprise for well-behaved and
future code".

___
Python tracker

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

[issue40546] Inconsistencies between PEG parser and traceback SyntaxErrors


Lysandros Nikolaou  added the comment:

> Hm, but there the old parser seems at fault: it points to the last space 
> rather than beyond it?

Both parsers seem to have the same behaviour, when parsing files. I just found 
out that even the new parser points to the `|` if there is not trailing 
whitespace:

╰─ cat -e t.py
x = 1 | 2 |$
╰─ ./python.exe t.py
  File "/Users/lysnikolaou/Repositories/cpython/t.py", line 1
x = 1 | 2 |
  ^
SyntaxError: invalid syntax
╰─ ./python.exe -X oldparser t.py
  File "/Users/lysnikolaou/Repositories/cpython/t.py", line 1
x = 1 | 2 |
  ^
SyntaxError: invalid syntax

I'll investigate more tomorrow.

--

___
Python tracker 

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

[issue14527] How to link with a non-system libffi?



Ned Deily  added the comment:

As of current Python 3 releases, like 3.8, the python build no longer vendors a 
copy of libffi for most Unix systems and for those systems the 
--with-system-ffi configure option is ignored, i.e. configure and setup.py will 
always try to find an external libffi.  On most systems, if you use are OK with 
using the system-supplied libffi, building and execution should usually "just 
work".  But if you want to use another version of libffi, for example, one that 
you build from source, it can be very non-intuitive of how to successfully do 
that *especially* if there is already a system libffi installed.  Depending on 
the system, you may need to set environment build variables like LDFLAGS, 
CFLAGS or PKG_CONFIG_PATH, and LD_LIBRARY_PATH for the Python build and/or you 
might need to override some of the libffi build variables to install in the 
proper locations for your system.  It seems like, as has been suggested in 
various places, setup.py should at least try to use pkg-config to find libff
 i library locations as it already does to find libffi include files. But that 
might not be enough to get a working setup, i.e. you still might need to set 
LD_LIBRARY_PATH or the equivalent to find libffi. At the very least, there 
should be some documentation on how to build with a non-system libffi.

--
components: +Build
nosy: +ned.deily
title: How to link with an external libffi? -> How to link with a non-system 
libffi?
versions: +Python 3.8, Python 3.9 -Python 2.7

___
Python tracker 

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

[issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS



Ned Deily  added the comment:

As of Python 3.7.0, we no longer "vendor" a copy of the libffi source for 
Unix-y platforms so I believe this issue of passing the right flag values into 
cpython's libffi build is no longer relevant.

--
nosy: +ned.deily
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue17848] can't compile with clang and build a shared lib due to libffi



Ned Deily  added the comment:

As of Python 3.7, Python source releases no longer "vendor" the source of 
libffi for Linux platforms; you need to use either a system-supplied libffi or, 
if really necessary, build and link with your own copy (not always easy to do). 
As the supplied patch modifies the now-defunct vendored libffi source, this 
issue is no longer relevant for current Pythons.

--
nosy: +ned.deily
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue40554] Add escape to the glossary?

2020-05-07 Thread Inada Naoki



Inada Naoki  added the comment:

There are many "escape"; JSON, HTML, SQL, Python string literal, ESC-key, 
escape sequence in the terminal, etc...

Is there a consistent meaning of "escape" in the context of Python?

--
nosy: +inada.naoki

___
Python tracker 

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

[issue40525] zipapps execute symlinks as if they are code


Filipe Laíns  added the comment:

I tracked this down to zipimporter. I have one untested patch, when I run 
python from my development tree for some reason the zipimport definition at 
Lib/zipimport.py is not used. I assume something weird is going on because of 
the frozen circular imports. I would appreaciate it if someone could explain 
how this works and how I get the correct zipimporter definition to be used.

--
keywords: +patch
nosy: +FFY00
Added file: https://bugs.python.org/file49140/zipimporter-symlink.patch

___
Python tracker 

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

[issue36944] Add support for ARM64 to libffi



Ned Deily  added the comment:

Paul, it looks like your changes were included upstream in libffi 3.3.0 which 
is now being used for python.org Windows builds.  If that is true, can we now 
close this issue?

--
nosy: +ned.deily
resolution:  -> out of date
stage:  -> resolved
status: open -> pending
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue31033] Add argument to .cancel() of Task and Future

2020-05-07 Thread Chris Jerdonek



Chris Jerdonek  added the comment:

I also posted a second PR (separate from the first) that adds a "msg" argument 
to Future.cancel() and Task.cancel(). That PR is also now ready for review:
https://github.com/python/cpython/pull/19979

The other PR is simpler and more essential though, so I think should be 
reviewed before this.

--

___
Python tracker 

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

[issue35061] Specify libffi.so soname for ctypes