[issue37831] bool(~True) == True

[Mark Dickinson]

Mark Dickinson  added the comment:

[Raymond]

> Given that & | and ^ are closed under bools [...]

So maybe the right fix is to change that fact? I'm not sure what the value of 
having True & True return True rather than 1 is, beyond misleading people into 
thinking that bitwise operators "just work" as logical operators on bools. 
Having True & True give 1 would send a clearer message that "yes, this works, 
but only because of the bool-is-an-int relationship, and it's not the right way 
to do logical operations".

Does anyone know what the rationale was for having & and | on bools return 
bools in the first place?

--

___
Python tracker 

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

[issue37849] IDLE: Completion window misplaced when shown above current line

[Terry J. Reedy]

Terry J. Reedy  added the comment:

What I reported is that it is too low on my Windows system, with my size and 
font, mostly covering the line.  Anyway, misplaced before, now perfectly placed.

Now that I see the patch, I seem to remember another place what an update call 
is needed before gathering window information.

Unless you say differently, I will add idlelib/NEWS.txt item tomorrow and merge.

--

___
Python tracker 

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

[issue37833] tkinter crashes macOS in the latest macOS update 10.14.6

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Interestingly enough both users in the py2app issue I mentioned use the 
python.org installer to install Python.  

One of them mentions this only happens when py2app is used, and that the script 
works fine outside of an app.

I'll look into this tonight (CEST).

--
status: pending -> open

___
Python tracker 

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

[issue5664] 2to3 wont convert Cookie.Cookie properly

[Aldwin Pollefeyt]

Change by Aldwin Pollefeyt :


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

___
Python tracker 

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

[issue5664] 2to3 wont convert Cookie.Cookie properly

[Aldwin Pollefeyt]

Change by Aldwin Pollefeyt :


--
nosy: +aldwinaldwin

___
Python tracker 

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

[issue37848] More fully implement Unicode's case mappings

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

The Unicode implementation is deliberately not locale specific and
this should not change.

If a locale specific mapping is requested, this should be done
explicitly by e.g. providing a parameter to str.lower() / upper() /
title().

--

___
Python tracker 

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

[issue37848] More fully implement Unicode's case mappings

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I believe that all locale specific things should be in the locale module, not 
in the str class.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue37831] bool(~True) == True

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> Does anyone know what the rationale was for having & and | on bools return 
> bools in the first place?

Besides the fact that they can be defined on bool in compatible way and these 
operators often are used for booleans?

It was in the initial version of PEP 285 and I have not found any questions or 
discussion about it.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue37849] IDLE: Completion window misplaced when shown above current line

[Tal Einat]

Tal Einat  added the comment:

> Unless you say differently, I will add idlelib/NEWS.txt item tomorrow and 
> merge.

I've added an idlelib/NEWS.txt entry to the PR.  Feel free to merge.

--

___
Python tracker 

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

[issue29535] datetime hash is deterministic in some cases

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue29535] datetime hash is deterministic in some cases

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue23885] urllib.quote horribly mishandles unicode as second parameter

[Michael Sander]

Michael Sander  added the comment:

Couldn't this be fixed in a backwards compatible way by clearing the cache when 
this type of error occurs? We can do this by wrapping the offending line with a 
try/except, then checking to see if the cache is corrupted. If it is, then we 
clear the cache and try again.

try:
  if not s.rstrip(safe):
return s
except UnicodeDecodeError:
  # Make sure the cache is okay, if not, try again.
  if any([not isinstance(s2, str) for q2, s2 in _safe_quoters.values()])
# Cache is corrupted, clear it and try again.
 _safe_quoters = {}
# Recursive call to try again
return quote(s, safe)
  raise

--
nosy: +Michael Sander

___
Python tracker 

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

[issue37681] warning: ‘no_sanitize_thread’

[miss-islington]

Change by miss-islington :


--
pull_requests: +14993
pull_request: https://github.com/python/cpython/pull/15271

___
Python tracker 

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

[issue37681] warning: ‘no_sanitize_thread’

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 7e479c82218450255572e3f5fa1549dc283901ea by Victor Stinner (Hai 
Shi) in branch 'master':
bpo-37681: no_sanitize_thread support from GCC 5.1 (GH-15096)
https://github.com/python/cpython/commit/7e479c82218450255572e3f5fa1549dc283901ea


--
nosy: +vstinner

___
Python tracker 

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

[issue37681] warning: ‘no_sanitize_thread’

[miss-islington]

Change by miss-islington :


--
pull_requests: +14992
pull_request: https://github.com/python/cpython/pull/15270

___
Python tracker 

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

[issue37583] Got a 113 error when running the test_socket

[STINNER Victor]

STINNER Victor  added the comment:


New changeset fbb0c032e89c42ab44f5372df40fffb34a91b575 by Victor Stinner (Hai 
Shi) in branch '3.7':
bpo-37583: Add err 113 to support.get_socket_conn_refused_errs() (GH-15259)
https://github.com/python/cpython/commit/fbb0c032e89c42ab44f5372df40fffb34a91b575


--

___
Python tracker 

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

[issue37583] Got a 113 error when running the test_socket

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Hai Shi for the bug report and the fix. It's now fixd in 3.7, 3.8 and 
master branches.

First I understood that you wanted to modify transient_internet() which is used 
in many places. Fixing support.get_socket_conn_refused_errs() is fine, it's 
only used in 2 test functions.

I don't think that it's worth it to fix Python 2.7 (which doesn't have 
get_socket_conn_refused_errs() function but build errno list directly in 
test_socket).

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue37681] warning: ‘no_sanitize_thread’

[miss-islington]

miss-islington  added the comment:


New changeset 364a1d3125af6c0ff0a4bd2c8afe70fd38f30456 by Miss Islington (bot) 
in branch '3.8':
bpo-37681: no_sanitize_thread support from GCC 5.1 (GH-15096)
https://github.com/python/cpython/commit/364a1d3125af6c0ff0a4bd2c8afe70fd38f30456


--
nosy: +miss-islington

___
Python tracker 

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

[issue37681] warning: ‘no_sanitize_thread’

[miss-islington]

miss-islington  added the comment:


New changeset 15b6d0a712c08557a605f49034f8ad392985144c by Miss Islington (bot) 
in branch '3.7':
bpo-37681: no_sanitize_thread support from GCC 5.1 (GH-15096)
https://github.com/python/cpython/commit/15b6d0a712c08557a605f49034f8ad392985144c


--

___
Python tracker 

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

[issue37848] More fully implement Unicode's case mappings

[STINNER Victor]

STINNER Victor  added the comment:

Handling locales correctly is a pain. Each platform uses different locale names 
(different Linux distributions, Windows, FreeBSD, macOS, etc.). For example, 
en_US.UTF-8 vs en_US.utf8. For example, there are tons of bugs related to 
locale.getdefaultlocale() which tries to be smart on parsing locales. I'm 
fixing locale encoding bugs for 10 years and I'm not done yet: there are still 
many open bugs.

I suggest you to first create a module on PyPI to experiment getting the locale 
and attempt to implement Unicode algorithms which depend on the locale.

Maintaining Python is already expensive, I would prefer to not complicate the 
codebase too much with locales. There are already enough bugs waiting for you 
to be fixed ;-)

--

___
Python tracker 

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

[issue32771] merge the underlying data stores of unicodedata and the str type

[STINNER Victor]

STINNER Victor  added the comment:

Note: On Debian and Ubuntu, the unicodedata is a built-in module. It's not 
built as a dynamic library. About the RSS memory, I'm not sure how Linux 
accounts the Unicode databases before they are accessed. Is it like read-only 
memory loaded on demand when accessed?

--

___
Python tracker 

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

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

[STINNER Victor]

STINNER Victor  added the comment:

> From my perspective, the main problem with using type annotations is that 
> there's nothing checking them in CI.

Even if unchecked, type annotations can serve as builtin documentation, as 
docstrings (even when docstrings are not checked ;-)).

Well, I don't have a strong opinion on type annotations in the Python stdlib. 
But here we are talking about a tool which is not installed, so I don't think 
that it matters much. It's not really part of the "stdlib".

--

___
Python tracker 

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

[issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information

[miss-islington]

Change by miss-islington :


--
pull_requests: +14994
pull_request: https://github.com/python/cpython/pull/15272

___
Python tracker 

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

[issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 077af8c2c93dd71086e2c5e5ff1e634b6da8f214 by Victor Stinner in 
branch 'master':
bpo-37738: Fix curses addch(str, color_pair) (GH-15071)
https://github.com/python/cpython/commit/077af8c2c93dd71086e2c5e5ff1e634b6da8f214


--

___
Python tracker 

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

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
keywords: +newcomer friendly

___
Python tracker 

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

[issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information

[STINNER Victor]

STINNER Victor  added the comment:

On my Fedora 30 with libncursesw, A_COLOR = 0xff00.

After my change, _curses uses:

static inline short
attr_to_color_pair(int attr)
{
return (short)((attr & A_COLOR) >> 8);
}

...
setcchar(&wcval, wstr, attr, attr_to_color_pair(attr), NULL);
...

If someone gets troubles with attr passed "directly" as the 3rd argument of 
setcchar(), we can try to pass (attr & ~A_COLOR) instead. On my Linux, it would 
mean: only pass the low 8 bits of attr.

But since it "just" works on my Linux, I prefer to only make minimum changes to 
fix this issue on Linux.

--

___
Python tracker 

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

[issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +14995
pull_request: https://github.com/python/cpython/pull/15273

___
Python tracker 

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

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +14996
pull_request: https://github.com/python/cpython/pull/15072

___
Python tracker 

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

[issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information

[miss-islington]

miss-islington  added the comment:


New changeset 984226962bc35254551d92771b5c8fb074507903 by Miss Islington (bot) 
in branch '3.8':
bpo-37738: Fix curses addch(str, color_pair) (GH-15071)
https://github.com/python/cpython/commit/984226962bc35254551d92771b5c8fb074507903


--
nosy: +miss-islington

___
Python tracker 

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

[issue37681] warning: ‘no_sanitize_thread’

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Hai Shi for the bug report and the fix.

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

[issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 7eef81ee766c8df23e522b4e46a930cc1d360ad7 by Victor Stinner in 
branch '3.7':
bpo-37738: Fix curses addch(str, color_pair) (GH-15071) (GH-15273)
https://github.com/python/cpython/commit/7eef81ee766c8df23e522b4e46a930cc1d360ad7


--

___
Python tracker 

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

[issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information

[STINNER Victor]

STINNER Victor  added the comment:

I fixed the bug in 3.7, 3.8 and master (future 3.9) branches. Thanks Marius 
Gedminas for the bug report. In the meanwhile, you have to pass bytes strings 
to addch() :-(

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

[issue37850] Console: holding right arrow key reproduces entire previous input

[Matthijs Blom]

New submission from Matthijs Blom :

To reproduce (on Windows):
On the console, enter some input:

>>> "Ozewiezewoze wiezewalla kristalla"
"Ozewiezewoze wiezewalla kristalla"

Next, hold the right arrow key, obtaining:

>>> "Ozewiezewoze wiezewalla kristalla"

One can subsequently delete sections of this line and again reproduce (last 
parts of) the previous input.

I have produced this result on 3.4, 3.8.0b3 and master (077af8c).
I did not observe this behaviour on WSL, which is why I think this is a bug.

--
components: Windows
messages: 349679
nosy: Matthijs Blom, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Console: holding right arrow key reproduces entire previous input
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

[issue36502] str.isspace() for U+00A0 and U+202F differs from document

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 6bccbe7dfb998af862a183f2c36f0d4603af2c29 by Victor Stinner (Greg 
Price) in branch 'master':
bpo-36502: Correct documentation of str.isspace() (GH-15019)
https://github.com/python/cpython/commit/6bccbe7dfb998af862a183f2c36f0d4603af2c29


--

___
Python tracker 

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

[issue37850] Console: holding right arrow key reproduces entire previous input

[Paul Moore]

Paul Moore  added the comment:

This is normal behaviour of the Windows console command line editing. Python 
simply inherits the standard console behaviour.

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

STINNER Victor  added the comment:

I dislike PR 13649 because it touch the thread module, only to fix a 
faulthandler unit test. The relationship between thread stack size and 
faulthandler is not obvious to me. Currently, faulthandler uses SIGSTKSZ, not 
the thread stack size. faulthandler usage of the stack should be quite low: it 
should need less than 1 MiB for example.

"When faulthandler.c uses sigaltstack(2), the stack size is set up with a 
buffer of size SIGSTKSZ. That is, sadly, only 8k."

"A chained signal handler that needs to invoke dynamic linking will therefore 
consume more than the default stack space allocated in faulthandler.c, just in 
machine-state saves alone. So, the failing test is failing because its 
scribbling on random memory before the allocated stack space."

Aha, that's interesting: SIGSTKSZ should be enough for 1 signal handler, but 
test_register_chain calls 2 signal handlers using the same stack. Can you 
please try the following patch?

diff --git a/Modules/faulthandler.c b/Modules/faulthandler.c
index 2331051f79..e7d13f2b2d 100644
--- a/Modules/faulthandler.c
+++ b/Modules/faulthandler.c
@@ -1325,7 +1325,7 @@ _PyFaulthandler_Init(int enable)
  * be able to allocate memory on the stack, even on a stack overflow. If it
  * fails, ignore the error. */
 stack.ss_flags = 0;
-stack.ss_size = SIGSTKSZ;
+stack.ss_size = SIGSTKSZ * 2;
 stack.ss_sp = PyMem_Malloc(stack.ss_size);
 if (stack.ss_sp != NULL) {
 err = sigaltstack(&stack, &old_stack);

--

___
Python tracker 

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

[issue34311] locale.format() and locale.format_string() cast Decimals to float

[Cédric Krier]

Change by Cédric Krier :


--
pull_requests: +14997
pull_request: https://github.com/python/cpython/pull/15275

___
Python tracker 

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

[issue34311] locale.format() and locale.format_string() cast Decimals to float

[Cédric Krier]

Cédric Krier  added the comment:

I think we can solve this issue like I solved issue13918 by providing a 
locale.localize() method which does the formatting as locale.format_string does 
but using the already formatted string.

I created PR-15275 which implements it and also use the new format in 
locale.currency as it is highly probable that currency will be used with 
Decimal.

--
nosy: +ced

___
Python tracker 

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

[issue33731] string formatting that produces floats with preset precision while respecting locale

[Cédric Krier]

Cédric Krier  added the comment:

I think PR-15275 will solves this issue also as you could use:

>>> locale.setlocale(locale.LC_ALL, 'fr_FR')
>>> locale.localize('{:.2f}'.format(1.891))
'1,89'

--
nosy: +ced

___
Python tracker 

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

[issue37774] Micro-optimize vectorcall using PY_LIKELY

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> My question is if it is safe to let developers "abuse" it. If these macros 
> are misused, they can lead to a performance regression.

I expect people using these macros and PR reviewers to use good judgement when 
to use these macros. There are many cases where the use of such macros should 
be uncontroversial, for example when checking for errors.

> For example, if you mark the error path as unlikely: this path will become 
> slower. If the error path is taken "frequently" enough, the slowdown can 
> become significant overall.

The speedup/slowdown that Py_LIKELY/Py_UNLIKELY gives is quite small, just a 
few clock cycles. This means that we shouldn't worry about performance 
regressions if the rest of the code takes much longer anyway. 

An example of this is raising exceptions, which typically involves 
PyErr_Format(). So I wouldn't worry too much about error paths getting slower.

> About the macros, I would prefer to make it private to not promote it.

I don't think it matters whether we call it Py_LIKELY or _Py_LIKELY. People 
that want to use it will use it anyway. And there is no issue with "provisional 
API" since this API is well-established in many existing projects.

--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

STINNER Victor  added the comment:

Attached altstack.c mimicks faulthandler unit test test_register_chain(), 
except that faulthandler_user() uses almost no stack memory. This test should 
check if SIGSTKSZ is big enough to call a second signal handler from a first 
signal handler.

Example of my Fedora 30 with "Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz" model 
name in /proc/cpuinfo and Linux kernel 5.1.18-300.fc30.x86_64:

$ gcc altstack.c -o altstack && ./altstack
SIGSTKSZ = 8192
our signal handler
User defined signal 1

Note: the follow gdb command didn't work for me:

> (gdb) p _rtld_local_ro._dl_x86_cpu_features.xsave_state_size
> $1 = 896

How can I get xsave_state_size for my glibc/kernel/CPU?

--
Added file: https://bugs.python.org/file48542/altstack.c

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

STINNER Victor  added the comment:

Ah, the cpuid command tells me "bytes required by XSAVE/XRSTOR area = 1088":

CPU 0:
   vendor_id = "GenuineIntel"
   version information (1/eax):
  processor type  = primary processor (0)
  family  = Intel Pentium Pro/II/III/Celeron/Core/Core 2/Atom, AMD 
Athlon/Duron, Cyrix M2, VIA C3 (6)
  model   = 0xe (14)
  stepping id = 0x3 (3)
  extended family = 0x0 (0)
  extended model  = 0x5 (5)
  (simple synth)  = Intel Core i3-6000 / i5-6000 / i7-6000 / Pentium G4000 
/ Celeron G3900 / Xeon E3-1200 (Skylake), 14nm
   ...
   feature information (1/edx):
  FXSAVE/FXRSTOR = true
  ...
   feature information (1/ecx):
  XSAVE/XSTOR states  = true
  OS-enabled XSAVE/XSTOR  = true
  ...
   XSAVE features (0xd/0):
  bytes required by XSAVE/XRSTOR area = 0x0440 (1088)
  ...
   XSAVE features (0xd/1):
  XSAVEOPT instruction= true
  XSAVEC instruction  = true
  XSAVES/XRSTORS instructions = true
  ...

/proc/cpuinfo also says:

flags   : ... xsave avx ... xsaveopt xsavec xgetbv1 xsaves ...

I recall that the Linux kernel was modified to only save AVX registers if a 
program uses AVX. So the process state size depends on the usage of AVX. But I 
cannot find the related LWN article.

--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

STINNER Victor  added the comment:

Ah, I found the recent change about XSAVE: it is a fix for CVE-2018-3665 
vulnerability.

"The software mitigation for this is to switch to an "eager" / immediate FPU 
state save and restore, in both kernels and hypervisors."

"On Intel and AMD x86 processors, operating systems and hypervisors often use 
what is referred to as a deferred saving and restoring method of the x86 FPU 
state, as part of performance optimization. This is done in a "lazy" on-demand 
fashion."

"It was found that due to the "lazy" approach, the x86 FPU states or FPU / XMM 
/ AVX512 register content, could leak across process, or even VM boundaries, 
giving attackers possibilities to read private data from other processes, when 
using speculative execution side channel gadgets."

https://www.suse.com/support/kb/doc/?id=7023076

See also: https://en.wikipedia.org/wiki/Lazy_FP_state_restore

--

___
Python tracker 

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

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS

[STINNER Victor]

STINNER Victor  added the comment:


New changeset b0c8369c603633f445ccbb5ca7a8742145ff9eec by Victor Stinner in 
branch 'master':
bpo-37531: Fix regrtest timeout for subprocesses (GH-15072)
https://github.com/python/cpython/commit/b0c8369c603633f445ccbb5ca7a8742145ff9eec


--

___
Python tracker 

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

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

[STINNER Victor]

STINNER Victor  added the comment:

Maybe repr(func) should be left unchanged, but str(func) can be enhanced?

--

___
Python tracker 

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

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> Maybe repr(func) should be left unchanged, but str(func) can be enhanced?

Yes, that is what I meant.

--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[Peter Edwards]

Peter Edwards  added the comment:

Hi Victor, thanks for the comments. Responses inline below.

On Wed, 14 Aug 2019 at 12:25, STINNER Victor  wrote:

>
> STINNER Victor  added the comment:
>
> I dislike PR 13649 because it touch the thread module, only to fix a
> faulthandler unit test.

My original patch (posted in the comments above) was purely in faulthandler
- I went at the threading code on your suggestion:

PyThread_start_new_thread() of thread_pthread.h already contains logic to
> get a "good" stack size. I would prefer to reuse this code."

I have no problem reformulating the code to avoid touching the threads
library - let me redo it as such.

> The relationship between thread stack size and faulthandler is not obvious
> to me. Currently, faulthandler uses SIGSTKSZ, not the thread stack size.
> faulthandler usage of the stack should be quite low: it should need less
> than 1 MiB for example.
>

The point of contention here is really he choice of stack size. SIGSTKSZ is
ridiculously small - it is the bare minimum amount of memory required to
actually handle the signal. The signal handling mechanism eats a huge chunk
of it, and the dynamic linker can also eat several K too. The intent was to
use the default thread stack size as a heuristic for what the platform
considers to be a reasonable size stack for applications. If the
pthread-aware OS is somehow constrained for address space, then I'd expect
it to reflect that in the default stack size. For 32-bit linux, the 8M of
address space is a bit of a chunk, but it's not a huge proportion of the
3-4G you have, and you're not consuming actual memory. On a 64-bit system,
consuming 8M of address space is a drop in the ocean.

>
> "When faulthandler.c uses sigaltstack(2), the stack size is set up with a
> buffer of size SIGSTKSZ. That is, sadly, only 8k."
>
> "A chained signal handler that needs to invoke dynamic linking will
> therefore consume more than the default stack space allocated in
> faulthandler.c, just in machine-state saves alone. So, the failing test is
> failing because its scribbling on random memory before the allocated stack
> space."
>
> Aha, that's interesting: SIGSTKSZ should be enough for 1 signal handler,
> but test_register_chain calls 2 signal handlers using the same stack. Can
> you please try the following patch?
>

It's more complex than that - in dynamically linked applications when you
call functions that still need to be resolved by the dynamic linker, the
resolving thunk in the PLT also ends up saving the register state via
xsavec, so with a chained call, there are up to 3 register states saved on
the stack, each over 2.5k on actual hardware we have now. I'm not convinced
there are not other ways stack space will be consumed during the signal
handler, and I'm not convinced that the amount of memory required per
handler will not go up as new CPUs come out, and I'm not convinced that
SIGSTKSZ will be bumped to reflect that (it certainly hasn't in the past),
so scaling SIGSTKSZ like this, while it'll likely fix the problem on any
machine I can test it on, doesn't seem like a stable solution

> diff --git a/Modules/faulthandler.c b/Modules/faulthandler.c
> index 2331051f79..e7d13f2b2d 100644
> --- a/Modules/faulthandler.c
> +++ b/Modules/faulthandler.c
> @@ -1325,7 +1325,7 @@ _PyFaulthandler_Init(int enable)
>   * be able to allocate memory on the stack, even on a stack overflow.
> If it
>   * fails, ignore the error. */
>  stack.ss_flags = 0;
> -stack.ss_size = SIGSTKSZ;
> +stack.ss_size = SIGSTKSZ * 2;
>  stack.ss_sp = PyMem_Malloc(stack.ss_size);
>  if (stack.ss_sp != NULL) {
>  err = sigaltstack(&stack, &old_stack);
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[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 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[Bennet Fauber]

Bennet Fauber  added the comment:

I just tested the proposed change in

Aha, that's interesting: SIGSTKSZ should be enough for 1 signal handler, but 
test_register_chain calls 2 signal handlers using the same stack. Can you 
please try the following patch?

```
diff --git a/Modules/faulthandler.c b/Modules/faulthandler.c
index 2331051f79..e7d13f2b2d 100644
--- a/Modules/faulthandler.c
+++ b/Modules/faulthandler.c
. . . .
-stack.ss_size = SIGSTKSZ;
+stack.ss_size = SIGSTKSZ * 2;
```

and the segfault no longer occurs at the faulthandler test.

Compiling and running the altstack.c using the system installed GCC 4.8.5 on 
CentOS 7.6.1810, kernel version 3.10.0-957.10.1.el7.x86_64 running on Dell R640 
Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz results in this output.

```
$ gcc -o altstack altstack.c 
$ ./altstack 
SIGSTKSZ = 8192
our signal handler
User defined signal 1
```

It does seem to me that relying on a statically set stack size when using 
dynamically loaded libraries is inviting similar problems in the future for the 
reasons that Peter enumerated:  There is no telling now what the requirements 
will be for some new chip family, and one cannot predict now what additional 
(if any) memory requirements might be needed by the linker in the future.

But, I think getting _some_ patch accepted and pushed to the main Python 
releases should have some priority, as the current state does seem undesirable.

--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[Peter Edwards]

Peter Edwards  added the comment:

The patch I originally proposed here (
https://bugs.python.org/file48353/sigaltstack-stacksize.patch ) is a pretty
minimal fix that uses the pthread stack size where available, with a
hard-coded lower bound of 1M. @Victor : if you want a minimal diff, I can
drop the existing PR, submit the above as a new one, and we can progress
from there?
Let me know how you'd like me to proceed.

On Wed, 14 Aug 2019 at 14:26, Bennet Fauber  wrote:

>
> Bennet Fauber  added the comment:
>
> I just tested the proposed change in
>
> Aha, that's interesting: SIGSTKSZ should be enough for 1 signal handler,
> but test_register_chain calls 2 signal handlers using the same stack. Can
> you please try the following patch?
>
> ```
> diff --git a/Modules/faulthandler.c b/Modules/faulthandler.c
> index 2331051f79..e7d13f2b2d 100644
> --- a/Modules/faulthandler.c
> +++ b/Modules/faulthandler.c
> . . . .
> -stack.ss_size = SIGSTKSZ;
> +stack.ss_size = SIGSTKSZ * 2;
> ```
>
> and the segfault no longer occurs at the faulthandler test.
>
> Compiling and running the altstack.c using the system installed GCC 4.8.5
> on CentOS 7.6.1810, kernel version 3.10.0-957.10.1.el7.x86_64 running on
> Dell R640 Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz results in this output.
>
> ```
> $ gcc -o altstack altstack.c
> $ ./altstack
> SIGSTKSZ = 8192
> our signal handler
> User defined signal 1
> ```
>
> It does seem to me that relying on a statically set stack size when using
> dynamically loaded libraries is inviting similar problems in the future for
> the reasons that Peter enumerated:  There is no telling now what the
> requirements will be for some new chip family, and one cannot predict now
> what additional (if any) memory requirements might be needed by the linker
> in the future.
>
> But, I think getting _some_ patch accepted and pushed to the main Python
> releases should have some priority, as the current state does seem
> undesirable.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start

[David K.]

David K.  added the comment:

Hi,

Judging by your comment, I think there is a an unfortnate misunderstanding.

If you'd be kind enough, please let me explain:

1. The issue I had was indeed on Python 3.7, using the highly used
"requests" library. Also my change was -not- applied on the deprecated
ssl.match_hostname()
but on _dnsname_match() which is a method of another inner class.
My point is that it's still releveant.

2. Although there is a thin line here, it is not a configuration issue by
its classic meaning. It's an outside condition in a production environment
that unpatches Python code cannot handle and thus implicating that Python
is less stable and mistake tolerant than C# and Java (those are the other
more used languages in the company which weren't effected by this problem
-- for some who wouldn't bother like me to patch python source code, this
could be a deal breaker to move to another language).

3. It's a very simple fix that only removes white spaces (empty chars) from
start and end of the DNS before applying all the other tests on it. In fact
by assuring the input of the DNS name, our code becomes -more- secure. In
current state, a missed type DNS name encoded in the certifications could
cause unknowingly Python deamons to stop transmiting data. Also as humans
tend to make such naive errors, a mallicious party could make an attack be
seemless and  be discarded as human error. And if that doesn't convince
you, we can say at the very least the service we provide with our App
becomes unusable and unavailable to clients and for some that could cost
time and money and Python may take the blame as unreliable as compared to
other languages.

4. The thrown exception can be misleading: The exception says that the
problem is a partial wildcard. However the problem is white spaces which
can be difficult to spot. White spaces cannot be part of DNS names thus it
makes no sense to ackonwledge them or refer to them or event test them as
any other legit legal char. Also this is unpredictible to the programmer as
he wouldn't think such a basic trim/strip of white spaces wouldn't happen
in the core of the SSL code what's worse, it can't be handled conventialy
with catching the exception. While a programmer can edit Python source code
to it's needs,  they really shouldn't mess with it for more than a short
term use. Declining the change dooms me for example to always add this
change to projects using SSL.

Thank you for your time.
I truely hope we can resolve this.
D.K

On Wed, Aug 14, 2019, 08:09 Christian Heimes  wrote:

>
> Christian Heimes  added the comment:
>
> This is not a bug in Python but a misconfiguration on your side. A
> workaround for a misconfiguration doesn't belong into upstream code. The
> certificate validation code is security-sensitive and I don't feel
> comfortable to add unnecessary string transformation to it. The code
> refuses bad wildcards because we have had more than one CVE related to
> wildcard matching.
>
> Besides the ssl.match_hostname() function is deprecated and no longer
> used. Starting with Python 3.7 the ssl module uses OpenSSL to verify host
> names.
>
> I suggest that you either ship this fix locally with your app. Or talk to
> IT again and have them replace the wrong certificate with a correct one
> that does not violate the standards.
>
> --
> resolution:  -> rejected
> stage: patch review -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +14999
pull_request: https://github.com/python/cpython/pull/15276

___
Python tracker 

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

[issue37256] urllib.request.Request documentation erroneously refers to the "final two"

[miss-islington]

Change by miss-islington :


--
pull_requests: +15001
pull_request: https://github.com/python/cpython/pull/15278

___
Python tracker 

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

[issue37256] urllib.request.Request documentation erroneously refers to the "final two"

[miss-islington]

Change by miss-islington :


--
pull_requests: +15000
pull_request: https://github.com/python/cpython/pull/15277

___
Python tracker 

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

[issue37851] faulthandler: only allocate the signal handler stack when faulthandler is used

[STINNER Victor]

New submission from STINNER Victor :

Currently at startup, Python always call _PyFaulthandler_Init() which allocates 
a stack of SIGSTKSZ bytes, even if faulthandler is never used. That's a waste 
of memory: the stack should be allocated the first time faulthandler is used.

bpo-21131 requires to enlarge this stack size.

--
components: Library (Lib)
messages: 349697
nosy: vstinner
priority: normal
severity: normal
status: open
title: faulthandler: only allocate the signal handler stack when faulthandler 
is used
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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[STINNER Victor]

STINNER Victor  added the comment:

"On a 64-bit system, consuming 8M of address space is a drop in the ocean."

Let me disagree here. Python always allocates faulthandler stack, even if 
faulthandler is not used. Even when faulthandler is used, I would prefer to not 
waste memory if 8 KiB is good enough.

By the way, I just created bpo-37851 to allocate this stack at the first 
faulthandler usage, instead of always allocating it, even when faulthandler is 
not used.

I wrote PR 15276 to use a stack of SIGSTKSZ*2 bytes. According to 
msg349694, it does fix the crash.

Can someone please double check that PR 15276 fix test_faulthandler on a 
platform where the test crash without this change?

--

___
Python tracker 

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

[issue37256] urllib.request.Request documentation erroneously refers to the "final two"

[miss-islington]

miss-islington  added the comment:


New changeset 3e1f135b26cf5fb3583d7e75d39b7b7a9edb472c by Miss Islington (bot) 
in branch '3.7':
bpo-37256: Wording in Request class docs (GH-14792)
https://github.com/python/cpython/commit/3e1f135b26cf5fb3583d7e75d39b7b7a9edb472c


--
nosy: +miss-islington

___
Python tracker 

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

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +15002
pull_request: https://github.com/python/cpython/pull/15279

___
Python tracker 

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

[issue36511] Add Windows ARM32 buildbot

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +15003
pull_request: https://github.com/python/cpython/pull/15279

___
Python tracker 

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

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +15004
pull_request: https://github.com/python/cpython/pull/15280

___
Python tracker 

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

[issue36030] add internal API function to create tuple without items array initialization

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 4fa10dde40356d7c71e5524233bafc221d9e2deb by Victor Stinner 
(Sergey Fedoseev) in branch 'master':
bpo-36030: Improve performance of some tuple operations (GH-12052)
https://github.com/python/cpython/commit/4fa10dde40356d7c71e5524233bafc221d9e2deb


--

___
Python tracker 

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

[issue36030] add internal API function to create tuple without items array initialization

[STINNER Victor]

STINNER Victor  added the comment:

Well done Sergey Fedoseev: I merged your last PR for this issue ;-) I'm not 
sure if it's worth it to document these tuple micro-optimizations in What's New 
in Python 3.8 / 3.9. In the meanwhile, I close the issue.

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

[issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start

[Christian Heimes]

Christian Heimes  added the comment:

On 14/08/2019 15.37, David K. wrote:
> 
> David K.  added the comment:
> 
> Hi,
> 
> Judging by your comment, I think there is a an unfortnate misunderstanding.
> 
> If you'd be kind enough, please let me explain:
> 
> 1. The issue I had was indeed on Python 3.7, using the highly used
> "requests" library. Also my change was -not- applied on the deprecated
> ssl.match_hostname()
> but on _dnsname_match() which is a method of another inner class.
> My point is that it's still releveant.

Except it's not revelant any more because that function is no longer
used by CPython's ssl module. Neither match_hostname nor any of its
helper functions are called by code in the ssl module. Since 3.7 all
hostname verification is now performed by OpenSSL code directly.
ssl.match_hostname will be removed in 3.9 or 3.10.

Latest urllib3 and requests don't use ssl.match_hostname() either. The
urllib3 package has an older copy of the hostname matching algorithm in
urllib3.packages.ssl_match_hostname. It should not be used with modern
Python.

> 2. Although there is a thin line here, it is not a configuration issue by
> its classic meaning. It's an outside condition in a production environment
> that unpatches Python code cannot handle and thus implicating that Python
> is less stable and mistake tolerant than C# and Java (those are the other
> more used languages in the company which weren't effected by this problem
> -- for some who wouldn't bother like me to patch python source code, this
> could be a deal breaker to move to another language).

Your setup has a misconfigured X.509 certificate with a SAN entry that
violates standards for certificates. You are asking me to introduce a
security into Python as a workaround for the misconfiguration.

The algorithm in match_hostname() and _dnsname_match() implements RFC
6125, section 6.4.3, in a strict way. Python not only refuses to match
invalid wildcard entries, it also fails hard on RFC 6125 violations.

> 3. It's a very simple fix that only removes white spaces (empty chars) from
> start and end of the DNS before applying all the other tests on it. In fact
> by assuring the input of the DNS name, our code becomes -more- secure. In
> current state, a missed type DNS name encoded in the certifications could
> cause unknowingly Python deamons to stop transmiting data. Also as humans
> tend to make such naive errors, a mallicious party could make an attack be
> seemless and  be discarded as human error. And if that doesn't convince
> you, we can say at the very least the service we provide with our App
> becomes unusable and unavailable to clients and for some that could cost
> time and money and Python may take the blame as unreliable as compared to
> other languages.

You view the fix as simple and harmless. I see it as a violation of
standards and a security bug. X.509 certs are complex and fragile
beasts. Python have had several CVEs in the hostname matching code
because we didn't implement it correctly. Certificates are also used in
legal contracts, e.g. to legally sign documents or establish mutual
trust. You cannot just modify the content of a certificate.

Since you are worried about the reliability of Python and started
talking about money, have you considered to donate money to the PSF?
Python is maintained by unpaid volunteers. Donations to the Python
Software Foundation help. (Disclaimer: No money in the world will change
my opinion about "dn.strip()".)

> 4. The thrown exception can be misleading: The exception says that the
> problem is a partial wildcard. However the problem is white spaces which
> can be difficult to spot. White spaces cannot be part of DNS names thus it
> makes no sense to ackonwledge them or refer to them or event test them as
> any other legit legal char. Also this is unpredictible to the programmer as
> he wouldn't think such a basic trim/strip of white spaces wouldn't happen
> in the core of the SSL code what's worse, it can't be handled conventialy
> with catching the exception. While a programmer can edit Python source code
> to it's needs,  they really shouldn't mess with it for more than a short
> term use. Declining the change dooms me for example to always add this
> change to projects using SSL.

The problem is not the code but the certificate. If you don't care about
valid certificate, then maybe disable hostname / certificate
verification. Or role your own verification. There is no need to modify
any source code for that.

--

___
Python tracker 

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

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 93bee6a8d878ff952e245614c567c7c6bb7a0398 by Victor Stinner in 
branch '3.7':
[3.7] bpo-37531: Fix regrtest timeout for subprocesses (GH-15072) (GH-15280)
https://github.com/python/cpython/commit/93bee6a8d878ff952e245614c567c7c6bb7a0398


--

___
Python tracker 

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

[issue36511] Add Windows ARM32 buildbot

[STINNER Victor]

STINNER Victor  added the comment:


New changeset d85c5670ff1611202a25c9e0967148e72c114de9 by Victor Stinner in 
branch '3.8':
[3.8] bpo-37531: Fix regrtest timeout for subprocesses (GH-15072) (GH-15279)
https://github.com/python/cpython/commit/d85c5670ff1611202a25c9e0967148e72c114de9


--
nosy: +vstinner

___
Python tracker 

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

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS

[STINNER Victor]

STINNER Victor  added the comment:


New changeset d85c5670ff1611202a25c9e0967148e72c114de9 by Victor Stinner in 
branch '3.8':
[3.8] bpo-37531: Fix regrtest timeout for subprocesses (GH-15072) (GH-15279)
https://github.com/python/cpython/commit/d85c5670ff1611202a25c9e0967148e72c114de9


--

___
Python tracker 

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

[issue37850] Console: holding right arrow key reproduces entire previous input

[Eryk Sun]

Eryk Sun  added the comment:

> I did not observe this behaviour on WSL, which is why I think 
> this is a bug.

WSL uses a low-level console interface in virtual-terminal mode. Python's 
console REPL in Windows is using the standard high-level console editing that's 
provided by the console host, conhost.exe, when the input mode contains 
ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT | ENABLE_PROCESSED_INPUT. This includes 
input history, aliases, and command-line editing that are based on the classic 
doskey utility from MS-DOS. The UI is documented for NT's doskey.exe command 
[1], which wraps the console interfaces for command-line history and aliases.

Python's built-in REPL could use a low-level console interface like PowerShell 
does, and implement a readline UI that's consistent with Unix, again like 
PowerShell has the option to do. Depending on whether we can integrate an 
existing readline library, that could be a monumental undertaking. pyreadline 
is a high-level ctypes wrapper that implements this. Last I checked it had some 
issues with Unicode and wasn't being vigorously maintained, but maybe that's 
changed.

[1] 
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/doskey

--
nosy: +eryksun

___
Python tracker 

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

[issue37831] bool(~True) == True

[Guido van Rossum]

Guido van Rossum  added the comment:

It never occurred to me that making b&b an b|b return bool would be considered 
a bad thing just because ~b is not a bool. That's like complaining that 1+1 
returns an int rather than a float for consistency with 1/2 returning a float.

Because bool is embedded in int, it's okay to return a bool value *that 
compares equal to the int from the corresponding int operation*. Code that 
accepts ints and is passed bools will continue to work. But if we were to make 
~b return `not b`, that makes bool not embedded in int (for the sake of numeric 
operations).

Take for example

def f(a: int) -> int:
return ~a

I don't think it's a good idea to make f(0) != f(False).

--

___
Python tracker 

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

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Joannah! That's a nice enhancement which should help to stabilize 
buildbots even more.

The next step is bpo-37711: "regrtest: re-run failed tests in subprocesses".

--

___
Python tracker 

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

[issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS

[STINNER Victor]

Change by STINNER Victor :


--
components: +Tests
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue37831] bool(~True) == True

[Mark Dickinson]

Mark Dickinson  added the comment:

> Because bool is embedded in int, it's okay to return a bool value *that 
> compares equal to the int from the corresponding int operation*.

Agreed that it's okay, but I'd like to understand why it's considered 
*desirable*. What use-cases benefit from having `x | y` give `True` or `False` 
rather than `1` or `0` when `x` and `y` are bools? Is the intent that `x & y` 
and `x | y` provide shorter ways to spell `x and y`, `x or y`, or (as I think 
Serhiy's suggesting) is this about catering to people coming from other 
languages and expecting `&` and `|` to be the right operations for doing logic 
with bools?

>From my integer-centric point of view, | and & are bitwise integer operations, 
>not logical operations; they only *happen* to apply to bool because a bool is 
>an int, but they're not natural boolean operations (in exactly the same way 
>that +, -, *, etc. aren't natural boolean operations). "and" and "or" seem the 
>"one obvious way to do it" for logical operations on bools; I don't think I 
>understand why anyone would want to use | and & on bools to get another bool, 
>instead of just using `or` and `and`.

--

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[Peter Edwards]

Peter Edwards  added the comment:

On Wed, 14 Aug 2019 at 14:46, STINNER Victor  wrote:

>
> STINNER Victor  added the comment:
>
> "On a 64-bit system, consuming 8M of address space is a drop in the ocean."
>
> Let me disagree here. Python always allocates faulthandler stack, even if
> faulthandler is not used. Even when faulthandler is used, I would prefer to
> not waste memory if 8 KiB is good enough.
>

I can understand the aversion to the waste when its never used - I can
address 37851 if you like - it seems pretty simple to fix. The pedant in me
must point out that it's 8M of address space, not memory. The cost on
64-bit (well, with a 47-bit user address space) is vanishingly small,
regardless of the physical memory on the system. On 32-bit, it's 0.2% of
your address space, which I think I'd trade for the safety, but that's your
call, and I appreciate that address space can be a constrained resource on
32-bit systems.

I do think SIGSTKSZ*2=16k is far too small considering the fault handler
could be running arbitrary python code, and we know that there's somewhat
less than half of that available for use by the interpreter.

>
> By the way, I just created bpo-37851 to allocate this stack at the first
> faulthandler usage, instead of always allocating it, even when faulthandler
> is not used.
>
> I wrote PR 15276 to use a stack of SIGSTKSZ*2 bytes. According to
> msg349694, it does fix the crash.
>
> Can someone please double check that PR 15276 fix test_faulthandler on a
> platform where the test crash without this change?
>

I can confirm that on the specific hardware I could reproduce this, that
PR14276 and setting the stacksize to SIGSTKSZ*2 passes the
test_faulthandler test.

>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue37823] Telnet documentation: fix the link to open()

[Michael Anckaert]

Change by Michael Anckaert :


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

___
Python tracker 

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

[issue37823] Telnet documentation: fix the link to open()

[Michael Anckaert]

Michael Anckaert  added the comment:

I created a PR for this issue (PR 15281). If any changes are required I'm more 
than happy to make them.

--
nosy: +michaelanckaert

___
Python tracker 

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

[issue19820] docs are missing info about module attributes

[Michael Anckaert]

Michael Anckaert  added the comment:

As far as I can tell there is at least some information missing from the 'Types 
and members' section. Not all attributes are listed in the table. 

For example the attribute __cached__ is missing from the module type but it is 
documented in the inspect module. 

I can update the docs but I would rely on the comments in Lib/inspect.py on 
what to include. Executing inspect.getmembers on a module returns a lot more 
attributes than documented in ismodule.

--
nosy: +michaelanckaert

___
Python tracker 

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

[issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start

[David K.]

David K.  added the comment:

OK,

I see your point :)

Modification of the original certificiation is legally problematic.

Much thanks for the patience and time to explain,
D.K

On Wed, Aug 14, 2019, 17:23 Christian Heimes  wrote:

>
> Christian Heimes  added the comment:
>
> On 14/08/2019 15.37, David K. wrote:
> >
> > David K.  added the comment:
> >
> > Hi,
> >
> > Judging by your comment, I think there is a an unfortnate
> misunderstanding.
> >
> > If you'd be kind enough, please let me explain:
> >
> > 1. The issue I had was indeed on Python 3.7, using the highly used
> > "requests" library. Also my change was -not- applied on the deprecated
> > ssl.match_hostname()
> > but on _dnsname_match() which is a method of another inner class.
> > My point is that it's still releveant.
>
> Except it's not revelant any more because that function is no longer
> used by CPython's ssl module. Neither match_hostname nor any of its
> helper functions are called by code in the ssl module. Since 3.7 all
> hostname verification is now performed by OpenSSL code directly.
> ssl.match_hostname will be removed in 3.9 or 3.10.
>
> Latest urllib3 and requests don't use ssl.match_hostname() either. The
> urllib3 package has an older copy of the hostname matching algorithm in
> urllib3.packages.ssl_match_hostname. It should not be used with modern
> Python.
>
> > 2. Although there is a thin line here, it is not a configuration issue by
> > its classic meaning. It's an outside condition in a production
> environment
> > that unpatches Python code cannot handle and thus implicating that Python
> > is less stable and mistake tolerant than C# and Java (those are the other
> > more used languages in the company which weren't effected by this problem
> > -- for some who wouldn't bother like me to patch python source code, this
> > could be a deal breaker to move to another language).
>
> Your setup has a misconfigured X.509 certificate with a SAN entry that
> violates standards for certificates. You are asking me to introduce a
> security into Python as a workaround for the misconfiguration.
>
> The algorithm in match_hostname() and _dnsname_match() implements RFC
> 6125, section 6.4.3, in a strict way. Python not only refuses to match
> invalid wildcard entries, it also fails hard on RFC 6125 violations.
>
> > 3. It's a very simple fix that only removes white spaces (empty chars)
> from
> > start and end of the DNS before applying all the other tests on it. In
> fact
> > by assuring the input of the DNS name, our code becomes -more- secure. In
> > current state, a missed type DNS name encoded in the certifications could
> > cause unknowingly Python deamons to stop transmiting data. Also as humans
> > tend to make such naive errors, a mallicious party could make an attack
> be
> > seemless and  be discarded as human error. And if that doesn't convince
> > you, we can say at the very least the service we provide with our App
> > becomes unusable and unavailable to clients and for some that could cost
> > time and money and Python may take the blame as unreliable as compared to
> > other languages.
>
> You view the fix as simple and harmless. I see it as a violation of
> standards and a security bug. X.509 certs are complex and fragile
> beasts. Python have had several CVEs in the hostname matching code
> because we didn't implement it correctly. Certificates are also used in
> legal contracts, e.g. to legally sign documents or establish mutual
> trust. You cannot just modify the content of a certificate.
>
> Since you are worried about the reliability of Python and started
> talking about money, have you considered to donate money to the PSF?
> Python is maintained by unpaid volunteers. Donations to the Python
> Software Foundation help. (Disclaimer: No money in the world will change
> my opinion about "dn.strip()".)
>
> > 4. The thrown exception can be misleading: The exception says that the
> > problem is a partial wildcard. However the problem is white spaces which
> > can be difficult to spot. White spaces cannot be part of DNS names thus
> it
> > makes no sense to ackonwledge them or refer to them or event test them as
> > any other legit legal char. Also this is unpredictible to the programmer
> as
> > he wouldn't think such a basic trim/strip of white spaces wouldn't happen
> > in the core of the SSL code what's worse, it can't be handled conventialy
> > with catching the exception. While a programmer can edit Python source
> code
> > to it's needs,  they really shouldn't mess with it for more than a short
> > term use. Declining the change dooms me for example to always add this
> > change to projects using SSL.
>
> The problem is not the code but the certificate. If you don't care about
> valid certificate, then maybe disable hostname / certificate
> verification. Or role your own verification. There is no need to modify
> any source code for that.
>
> --
>
> ___
> Python track

[issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart

[Michael Anckaert]

Michael Anckaert  added the comment:

This issue is still present on Python 3.7 and above. 

As David suggested set_charset could be turned into a no-op on MIMEMultipart. 

I traced set_charset back to inheritance from email.message.Message, would 
overriding set_charset (and possibly raising a deprecation warning) be an 
acceptable fix?

--
nosy: +michaelanckaert

___
Python tracker 

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

[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10

[Bennet Fauber]

Bennet Fauber  added the comment:

I updated the versions affected to include 3.6 and 3.7, both of which are 
affected.

I am a bit concerned that the conversation might get fragmented, so I will put 
in the full URL to the newly created PR at GitHub here.

https://github.com/python/cpython/pull/15276

just to make it easier for anyone else who finds this to see where things have 
gone.

I am now, also, uncertain what the current status of

https://github.com/python/cpython/pull/13649

is now.

It seems that we are now waiting on review from someone from the core 
developers?

--
versions: +Python 3.6, Python 3.7

___
Python tracker 

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

[issue37852] Pickling doesn't work for name-mangled private methods

[Josh Rosenberg]

New submission from Josh Rosenberg :

Inspired by this Stack Overflow question, where it prevented using 
multiprocessing.Pool.map with a private method: 
https://stackoverflow.com/q/57497370/364696

The __name__ of a private method remains the unmangled form, even though only 
the mangled form exists on the class dictionary for lookup. The __reduce__ for 
bound methods doesn't handle them private names specially, so it will serialize 
it such that on the other end, it does getattr(method.__self__, 
method.__func__.__name__). On deserializing, it tries to perform that lookup, 
but of course, only the mangled name exists, so it dies with an AttributeError.

Minimal repro:

import pickle

class Spam:
def __eggs(self):
pass
def eggs(self):
return pickle.dumps(self.__eggs)

spam = Spam()
pkl = spam.eggs()   # Succeeds via implicit mangling (but 
pickles unmangled name)
pickle.loads(pkl)   # Fails (tried to load __eggs

Explicitly mangling via pickle.dumps(spam._Spam__eggs) fails too, and in the 
same way.

A similar problem occurs (on the serializing end) when you do:

pkl = pickle.dumps(Spam._Spam__eggs)# Pickling function in Spam class, not 
bound method of Spam instance

though that failure occurs at serialization time, because pickle itself tries 
to look up .Spam.__eggs (which doesn't exist), instead of 
.Spam._Spam__eggs (which does).

1. It fails at serialization time (so it doesn't silently produce pickles that 
can never be unpickled)
2. It's an explicit PicklingError, with a message that explains what it tried 
to do, and why it failed ("Can't pickle : 
attribute lookup Spam.__eggs on __main__ failed")

In the use case on Stack Overflow, it was the implicit case; a public method of 
a class created a multiprocessing.Pool, and tried to call Pool.map with a 
private method on the same class as the mapper function. While normally 
pickling methods seems odd, for multiprocessing, it's pretty standard.

I think the correct fix here is to make method_reduce in classobject.c (the 
__reduce__ implementation for bound methods) perform the mangling itself 
(meth_reduce in methodobject.c has the same bug, but it's less critical, since 
only private methods of built-in/extension types would be affected, and most of 
the time, such private methods aren't exposed to Python at all, they're just 
static methods for direct calling in C).

This would handle all bound methods, but for "unbound methods" (read: functions 
defined in a class), it might also be good to update 
save_global/get_deep_attribute in _pickle.c to make it recognize the case where 
a component of a dotted name begins with two underscores (and doesn't end with 
them), and the prior component is a class, so that pickling the private unbound 
method (e.g. plain function which happened to be defined on a class) also 
works, instead of dying with a lookup error.

The fix is most important, and least costly, for bound methods, but I think 
doing it for plain functions is still worthwhile, since I could easily see 
Pool.map operations using an @staticmethod utility function defined privately 
in the class for encapsulation purposes, and it seems silly to force them to 
make it more public and/or remove it from the class.

--
components: Interpreter Core, Library (Lib)
messages: 349716
nosy: josh.r
priority: normal
severity: normal
status: open
title: Pickling doesn't work for name-mangled private methods
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

[issue37849] IDLE: Completion window misplaced when shown above current line

[miss-islington]

Change by miss-islington :


--
pull_requests: +15006
pull_request: https://github.com/python/cpython/pull/15282

___
Python tracker 

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

[issue37849] IDLE: Completion window misplaced when shown above current line

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 71662dc2f12a7e77e5e1dfe64ec87c1b459c3f59 by Terry Jan Reedy (Tal 
Einat) in branch 'master':
bpo-37849: IDLE: fix completion window positioning above line (GH-15267)
https://github.com/python/cpython/commit/71662dc2f12a7e77e5e1dfe64ec87c1b459c3f59


--

___
Python tracker 

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

[issue37849] IDLE: Completion window misplaced when shown above current line

[miss-islington]

Change by miss-islington :


--
pull_requests: +15007
pull_request: https://github.com/python/cpython/pull/15283

___
Python tracker 

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

[issue19820] docs are missing info about module attributes

[Eric Snow]

Eric Snow  added the comment:

The relevant module attributes are described in the importlib docs: 
https://docs.python.org/3/library/importlib.html#importlib.abc.Loader.load_module

--
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.3, Python 3.4

___
Python tracker 

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

[issue37849] IDLE: Completion window misplaced when shown above current line

[miss-islington]

miss-islington  added the comment:


New changeset 557802dc17498557e481f2ad3d4a83ece469e489 by Miss Islington (bot) 
in branch '3.8':
bpo-37849: IDLE: fix completion window positioning above line (GH-15267)
https://github.com/python/cpython/commit/557802dc17498557e481f2ad3d4a83ece469e489


--
nosy: +miss-islington

___
Python tracker 

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

[issue12178] csv writer doesn't escape escapechar

[Brad MacGregor]

Brad MacGregor  added the comment:

I needed this patch for a project, so I compiled python with the patch applied, 
and tested my specific use case, and it worked. Thanks for the patch!

--
nosy: +avatarofhope

___
Python tracker 

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

[issue37849] IDLE: Completion window misplaced when shown above current line

[miss-islington]

miss-islington  added the comment:


New changeset 88cce7b59fa503616295ca1a25bce6251f9cd317 by Miss Islington (bot) 
in branch '3.7':
bpo-37849: IDLE: fix completion window positioning above line (GH-15267)
https://github.com/python/cpython/commit/88cce7b59fa503616295ca1a25bce6251f9cd317


--

___
Python tracker 

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

[issue37853] [urllib.parse.urlparse] It does not correctly parse the URL with basic authentication.

[Fatih Sarhan]

New submission from Fatih Sarhan :

No problem for these:
  "http://localhost:9100";
  "http://user:password@localhost:9100";

But, these are problematic:
  "http://use#r:password@localhost:9100";
  "http://user:pass#word@localhost:9100";


```
from urllib.parse import urlparse

url = "http://us#er:123@localhost:9001/RPC2";
u = urlparse(url)
print(u)
# ParseResult(scheme='http', netloc='us', path='', params='', query='', 
fragment='er:123@localhost:9001/RPC2')
```

--
components: Library (Lib)
messages: 349721
nosy: f9n
priority: normal
severity: normal
status: open
title: [urllib.parse.urlparse] It does not correctly parse the URL with basic 
authentication.
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue37831] bool(~True) == True

[Guido van Rossum]

Guido van Rossum  added the comment:

> > Because bool is embedded in int, it's okay to return a bool value *that 
> > compares equal to the int from the corresponding int operation*.

> Agreed that it's okay, but I'd like to understand why it's considered 
> *desirable*. What use-cases benefit from having `x | y` give `True` or 
> `False` rather than `1` or `0` when `x` and `y` are bools? Is the intent that 
> `x & y` and `x | y` provide shorter ways to spell `x and y`, `x or y`, or (as 
> I think Serhiy's suggesting) is this about catering to people coming from 
> other languages and expecting `&` and `|` to be the right operations for 
> doing logic with bools?

> From my integer-centric point of view, | and & are bitwise integer 
> operations, not logical operations; they only *happen* to apply to bool 
> because a bool is an int, but they're not natural boolean operations (in 
> exactly the same way that +, -, *, etc. aren't natural boolean operations). 
> "and" and "or" seem the "one obvious way to do it" for logical operations on 
> bools; I don't think I understand why anyone would want to use | and & on 
> bools to get another bool, instead of just using `or` and `and`.

For one thing, you can override `&` and `|` but you can't override `and` and 
`or`.

Probably when we introduced book we should have thought harder about it, but I 
don't think we should change anything at this point, so I'm not sure why 
whether it's worth trying to uncover the original deep motivations (probably 
they weren't so deep).

--

___
Python tracker 

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

[issue37831] bool(~True) == True

[Guido van Rossum]

Guido van Rossum  added the comment:

s/book/bool/

--

___
Python tracker 

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

[issue37775] update doc of compileall

[Sanyam Khurana]

Sanyam Khurana  added the comment:

I've checked and approved this PR.

This needs a core-review now.

Thanks, Hai for your contribution.

--
nosy: +CuriousLearner, Mariatta

___
Python tracker 

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

[issue37854] [xmlrpc.client.ServerProxy] It does not correctly parse the URL with basic authentication.

[Fatih Sarhan]

New submission from Fatih Sarhan :

Same problem here. (https://bugs.python.org/issue37853)

--
components: Library (Lib)
messages: 349726
nosy: f9n
priority: normal
severity: normal
status: open
title: [xmlrpc.client.ServerProxy] It does not correctly parse the URL with 
basic authentication.
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue19820] docs are missing info about module attributes

[Emmanuel Arias]

Emmanuel Arias  added the comment:

> I can update the docs but I would rely on the comments in Lib/inspect.py on 
> what to include. Executing inspect.getmembers on a module returns a lot more 
> attributes than documented in ismodule.

I can help too.

--
nosy: +eamanu

___
Python tracker 

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

[issue37854] [xmlrpc.client.ServerProxy] It does not correctly parse the URL with basic authentication.

[Fatih Sarhan]

Fatih Sarhan  added the comment:

I just changed things and it works. But it's not right. It must be better 
way.(The 'urllib.parse.urlparse' function's bug should be fixed. )

https://github.com/f9n/cpython/tree/fix-issue-37854

--

___
Python tracker 

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

[issue37853] [urllib.parse.urlparse] It does not correctly parse the URL with basic authentication.

[Sanyam Khurana]

Sanyam Khurana  added the comment:

Duplicate of Issue 37854

Fatih,

Thank you for your report. I'm marking this one as a duplicate of another. 
Request you to not create multiple issues at once for the same thing.

Thank you!

--
nosy: +CuriousLearner
resolution:  -> duplicate
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

[issue37854] [xmlrpc.client.ServerProxy] It does not correctly parse the URL with basic authentication.

[Sanyam Khurana]

Sanyam Khurana  added the comment:

Closed Issue 37853 as a duplicate.

Adding Fatih's comment from there for urllib.parse.urlparse


-

No problem for these:
  "http://localhost:9100";
  "http://user:password@localhost:9100";

But, these are problematic:
  "http://use#r:password@localhost:9100";
  "http://user:pass#word@localhost:9100";


```
from urllib.parse import urlparse

url = "http://us#er:123@localhost:9001/RPC2";
u = urlparse(url)
print(u)
# ParseResult(scheme='http', netloc='us', path='', params='', query='', 
fragment='er:123@localhost:9001/RPC2')
```


--

--
nosy: +CuriousLearner
versions:  -Python 3.5, Python 3.6

___
Python tracker 

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

[issue29535] datetime hash is deterministic in some cases

[Ashwin Ramaswami]

Ashwin Ramaswami  added the comment:

Why is it ok for certain hashes (such as tuples) to be not non-deterministic, 
while other hashes (such as datetime) need to be non-deterministic?

--

___
Python tracker 

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

[issue37848] More fully implement Unicode's case mappings

[Greg Price]

Greg Price  added the comment:

> I believe that all locale specific things should be in the locale module, not 
> in the str class.

The locale module is all about doing things with the current process-global 
Unix locale. I don't think that'd be an appropriate interface for this -- if 
it's worth doing, it's worth doing in such a way that the same web server 
process can handle requests for Turkish-, Lithuanian-, and Spanish-speaking 
users without having to reset a global variable for each one.

> If a locale specific mapping is requested, this should be done
> explicitly by e.g. providing a parameter to str.lower() / upper() /
> title().

I like this design.

I said "locale" above, but that wasn't quite right, I think -- the file says 
e.g. `tr`, not `tr_TR` and `tr_CY`, and it describes the identifiers as 
"language IDs".  So perhaps

str.lower(*, lang=None)

?  And then

"I".lower(lang="tr") == "ı" == "\N{Latin small letter dotless I}"

--

___
Python tracker 

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

[issue37852] Pickling doesn't work for name-mangled private methods

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +pitrou

___
Python tracker 

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

[issue37848] More fully implement Unicode's case mappings

[Greg Price]

Greg Price  added the comment:

> Maintaining Python is already expensive [...] There are already enough bugs 
> waiting for you to be fixed ;-)

BTW I basically agree with this. I think this is not a high-priority issue, and 
I have my eye on some of those bugs. :-)

I think the fact that it's per-*language* (despite my inaccurate phrasing in 
the OP), not per-locale, simplifies it some -- for example the whole `.UTF-8` 
vs `.utf8` thing doesn't appear. And in particular I think if/when someone 
decides to sit down and make an implementation of this, then if they take the 
time to carefully read and absorb the relevant pages of the standard... this is 
a feature where it's pretty feasible for the implementation to be a 
self-contained and relatively stable and low-bugs piece of code.

And in general I think even if nobody implements it soon, it's useful to have 
an issue that can be pointed to for this feature, and especially so if the 
discussion clearly lays out what the feature involves and what different 
people's views are on the API. For example #18236 has been open for 6 years, 
but the discussion there was extremely helpful for me to understand it and work 
up a fix, after just being pointed to it by someone who'd searched the tracker 
on seeing me send in the doc fix GH-15019.

--

___
Python tracker 

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

[issue37855] Compiling Python 3.7.4 with Intel compilers 2019

[Zhiyong Zhang]

New submission from Zhiyong Zhang :

Compilation of Python 3.7.4 with Intel icc/2019 failed with the following 
errors: 

icpc -c -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -g -O0 -Wall -O3 
-fp-model strict -fp-model source -xHost -ipo -prec-div -prec-sqrt   -std=c++11 
-Wextra -Wno-unused-parameter -Wno-missing-field-initializers 
-Werror=implicit-function-declaration -fp-model strict -Wextra 
-Wno-unused-parameter -Wno-missing-field-initializers 
-Werror=implicit-function-declaration -fp-model strict  -IObjects -IInclude 
-IPython -I. -I../Include-DPy_BUILD_CORE -o Programs/python.o 
../Programs/python.c
In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(32): error: identifier "memory_order_relaxed" is undefined
  _Py_memory_order_relaxed = memory_order_relaxed,
 ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(33): error: identifier "memory_order_acquire" is undefined
  _Py_memory_order_acquire = memory_order_acquire,
 ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(34): error: identifier "memory_order_release" is undefined
  _Py_memory_order_release = memory_order_release,
 ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(35): error: identifier "memory_order_acq_rel" is undefined
  _Py_memory_order_acq_rel = memory_order_acq_rel,
 ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(36): error: identifier "memory_order_seq_cst" is undefined
  _Py_memory_order_seq_cst = memory_order_seq_cst
 ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(40): error: identifier "atomic_uintptr_t" is undefined
  atomic_uintptr_t _value;
  ^

In file included from ../Include/Python.h(75),
 from ../Programs/python.c(3):
../Include/pyatomic.h(44): error: identifier "atomic_int" is undefined
  atomic_int _value;
  ^

--
components: Installation
messages: 349734
nosy: zyzhang2006
priority: normal
severity: normal
status: open
title: Compiling Python 3.7.4 with Intel compilers 2019
type: compile error
versions: Python 3.7

___
Python tracker 

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