[issue32892] Remove specific constant AST types in favor of ast.Constant

[thautwarm]

thautwarm  added the comment:

I'm in favor of this idea for prospective extensions that could be implemented 
through this brand-new ast.Constant.  

Actually I used to expect a more general ast.Constant when I was manipulating 
ASTs half a year ago, at that time my job is to make staging functions that 
take some user-defined types as constants(in these scenes, these types are 
definitely immutable and permanent) to gain performance improvements and avoid 
redundant allocations, and what I exactly wanted is such an ast.Constant.

--
nosy: +thautwarm

___
Python tracker 

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

[issue29577] Enum: mixin classes don't mix well with already mixed Enums

[Ethan Furman]

Ethan Furman  added the comment:


New changeset 0c076caaa82a9c6596e1fe1dbe6384d53f30a1a3 by Ethan Furman in 
branch '3.7':
[3.7] bpo-29577: Enum: mixin classes don't mix well with already mixed Enums 
(GH-9328) (GH-9486)
https://github.com/python/cpython/commit/0c076caaa82a9c6596e1fe1dbe6384d53f30a1a3


--

___
Python tracker 

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

[issue32352] `inspect.getfullargspec` doesn't work fine for some builtin callable objects

[thautwarm]

thautwarm  added the comment:

Maybe a few adjustments to this one?

--

___
Python tracker 

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

[issue34759] Possible regression in ssl module in 3.7.1 and master

[miss-islington]

miss-islington  added the comment:


New changeset 7529754d26f5e744ae25bee56fdc1937bcf08c7e by Miss Islington (bot) 
(Christian Heimes) in branch '3.6':
[3.6] bpo-34759: Fix error handling in ssl 'unwrap()' (GH-9468) (GH-9492)
https://github.com/python/cpython/commit/7529754d26f5e744ae25bee56fdc1937bcf08c7e


--

___
Python tracker 

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

[issue34759] Possible regression in ssl module in 3.7.1 and master

[miss-islington]

miss-islington  added the comment:


New changeset c00f7037df3607c89323e68db3ab996b7df394de by Miss Islington (bot) 
in branch '3.7':
bpo-34759: Fix error handling in ssl 'unwrap()' (GH-9468)
https://github.com/python/cpython/commit/c00f7037df3607c89323e68db3ab996b7df394de


--

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[miss-islington]

miss-islington  added the comment:


New changeset 5c3d8b2efda1b99abe09ad925f366c5695bd66fb by Miss Islington (bot) 
in branch '3.7':
[3.7] bpo-34623: Mention CVE-2018-14647 in news entry (GH-9482) (GH-9488)
https://github.com/python/cpython/commit/5c3d8b2efda1b99abe09ad925f366c5695bd66fb


--

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[miss-islington]

miss-islington  added the comment:


New changeset 10be1d3f802b874914b2a13eb41407c7a582d9b3 by Miss Islington (bot) 
in branch '2.7':
[2.7] bpo-34623: Mention CVE-2018-14647 in news entry (GH-9482) (GH-9490)
https://github.com/python/cpython/commit/10be1d3f802b874914b2a13eb41407c7a582d9b3


--

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[miss-islington]

miss-islington  added the comment:


New changeset d1b336e530472f316b1d164d04626724c83b16d7 by Miss Islington (bot) 
in branch '3.6':
[3.6] bpo-34623: Mention CVE-2018-14647 in news entry (GH-9482) (GH-9489)
https://github.com/python/cpython/commit/d1b336e530472f316b1d164d04626724c83b16d7


--

___
Python tracker 

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

[issue34759] Possible regression in ssl module in 3.7.1 and master

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +8902

___
Python tracker 

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

[issue34759] Possible regression in ssl module in 3.7.1 and master

[miss-islington]

miss-islington  added the comment:


New changeset c0da582b227f311126e278b5553a7fa89c79b054 by Miss Islington (bot) 
(Nathaniel J. Smith) in branch 'master':
bpo-34759: Fix error handling in ssl 'unwrap()' (GH-9468)
https://github.com/python/cpython/commit/c0da582b227f311126e278b5553a7fa89c79b054


--
nosy: +miss-islington

___
Python tracker 

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

[issue34759] Possible regression in ssl module in 3.7.1 and master

[miss-islington]

Change by miss-islington :


--
pull_requests: +8901

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[miss-islington]

Change by miss-islington :


--
pull_requests: +8899

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[miss-islington]

Change by miss-islington :


--
pull_requests: +8900

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[miss-islington]

miss-islington  added the comment:


New changeset 026337a7101369297c8083047d2f3c6fc9dd1e2b by Miss Islington (bot) 
(Christian Heimes) in branch 'master':
bpo-34623: Mention CVE-2018-14647 in news entry (GH-9482)
https://github.com/python/cpython/commit/026337a7101369297c8083047d2f3c6fc9dd1e2b


--

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[miss-islington]

Change by miss-islington :


--
pull_requests: +8898

___
Python tracker 

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

[issue34686] Add `-r`, as opposed to `-R` to Python core interpreter

[Terry J. Reedy]

Change by Terry J. Reedy :


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

[issue34397] remove redundant overflow checks in tuple and list implementations

[Tim Peters]

Tim Peters  added the comment:

Because the behavior of signed integer overflow isn't defined in C.  Picture a 
3-bit integer type, where the maximum value of the signed integer type is 3.  
3+3 has no defined result.  Cast them to the unsigned flavor of the integer 
type, though, and the result is defined to be 6.

--

___
Python tracker 

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

[issue32117] Tuple unpacking in return and yield statements

[Jordan Chapman]

Change by Jordan Chapman :


--
pull_requests: +8897

___
Python tracker 

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

[issue34751] Hash collisions for tuples

[Tim Peters]

Tim Peters  added the comment:

>> Why do you claim the original was "too small"?  Too small for
>> what purpose?

> If the multiplier is too small, then the resulting hash values are
> small too. This causes collisions to appear for smaller numbers:

All right!  An actual reason ;-)  So there are two things so far I clearly 
agree with, but they're independent of "the problem" this report was opened 
about:

1. On a 64-bit box life would be better if we picked a bigger multiplier.  This 
should be done via preprocessor #if selection, though, not via the inscrutable 
rules C uses to cut back an integer literal out of range for the type of the 
variable it's assigned to.

2. A raw integer hash of -1 should be changed to something other than -2.  It 
was always a Poor Idea to pick an integer of small magnitude for the 
substitute.  Some newer types didn't repeat this mistake.  For example, 
frozensets replace a raw hash of -1 with 
590923713.  Alas, this is hard to change now, because hashable objects of any 
type that compare equal to -1 also need to return the same substitute value 
(e.g., hash(-1.0) == hash(decimal.Decimal("-100e-2")) == hash(-1+0j) == -2).  
So I'm afraid it's been hard-coded into user-defined numeric classes too :-(  
There would be no obvious problem in changing the _tuple_ hash to use a 
different substitute value, although it's not clear that would buy anything 
either.  hash(-1) == -2 was the original sin.


[about multipliers]
> Because it's really just random chance.
> ...
> Ideally, it should be just a random number.

How do you know this?  I'm not aware of any research papers about picking 
multipliers in this context, but would love to see one.

I am aware of much research about multipliers in the somewhat related contexts 
of linear congruential pseudo-random number generators, and of "multiplicative 
hashing", and "any random multiplier is fine" couldn't be further from the 
truth _in_ those contexts.

Guido picked a prime to begin with (actually, at first it was 3(!)), and 
comments in the current code sure say that whoever added this part was keen on 
primes too:

"""
/* The addend 82520, was selected from the range(0, 100) for
   generating the greatest number of prime multipliers for tuples
   up to length eight:
"""

I don't know that primes are important here, but neither do I know that they're 
_not_ important here.  Widely used production code isn't the place to conduct 
experiments, so the status quo is favored in the absence of truly compelling 
reasons.  Just repeating the raw assertion "random is fine" isn't compelling.  
If it were true, we could, e.g., multiply by a large power of 2 via shifting 
instead, and save a few cycles.

For my best guess at what "the problem" here actually is, in the

>>> cands = list(range(-10, -1)) + list(range(9))
>>> len(set(hash(t) for t in product(cands, repeat=4)))

example, which currently (on my 64-bit box) generates 35,380 distinct hash 
codes from the 104,976 inputs, ALL the collisions go away merely by changing 
the character "^" to "+" in the current code.

Which was your original suggestion.  Which you appear to be opposed to now?  
I'm unclear about why, if so.

That's a change I could probably live with, although I have no strong reason to 
believe it couldn't cause problems for applications that currently work fine.  
I don't have more time to think about that now, though.

--

___
Python tracker 

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

[issue34397] remove redundant overflow checks in tuple and list implementations

[Windson Yang]

Windson Yang  added the comment:

Hello, Tim Peters. I wonder why we need to add size_t here:

assert((size_t)Py_SIZE(a) + (size_t)Py_SIZE(b) <= (size_t)PY_SSIZE_T_MAX);

AFAIK, PY_SSIZE_T_MAX = ((Py_ssize_t)(((size_t)-1)>>1)) which is signed, either 
Py_SIZE(a) or Py_SIZE(b) is a positive number. Why we need to concast them to 
size_t, Thank you?

--
nosy: +Windson Yang

___
Python tracker 

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

[issue29577] Enum: mixin classes don't mix well with already mixed Enums

[Ethan Furman]

Change by Ethan Furman :


--
pull_requests: +8896

___
Python tracker 

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

[issue29577] Enum: mixin classes don't mix well with already mixed Enums

[Ethan Furman]

Ethan Furman  added the comment:


New changeset 5bdab641da0afd8aa581dfbde4f82d88d337c4b5 by Ethan Furman in 
branch 'master':
bpo-29577: Enum: mixin classes don't mix well with already mixed Enums (GH-9328)
https://github.com/python/cpython/commit/5bdab641da0afd8aa581dfbde4f82d88d337c4b5


--

___
Python tracker 

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

[issue32117] Tuple unpacking in return and yield statements

[Guido van Rossum]

Guido van Rossum  added the comment:

Fixed by https://github.com/python/cpython/pull/4509.

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

[issue32117] Tuple unpacking in return and yield statements

[Guido van Rossum]

Guido van Rossum  added the comment:


New changeset fd97d1f1af910a6222ea12aec42c456b64f9aee4 by Guido van Rossum 
(David Cuthbert) in branch 'master':
bpo-32117: Allow tuple unpacking in return and yield statements (gh-4509)
https://github.com/python/cpython/commit/fd97d1f1af910a6222ea12aec42c456b64f9aee4


--

___
Python tracker 

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

[issue34537] test_gdb fails with LC_ALL=C

[miss-islington]

miss-islington  added the comment:


New changeset e5fde1f992e94f166415ab96d874ed1d2e0c8004 by Miss Islington (bot) 
in branch '3.7':
bpo-34537: Fix test_gdb:test_strings with LC_ALL=C (GH-9483)
https://github.com/python/cpython/commit/e5fde1f992e94f166415ab96d874ed1d2e0c8004


--
nosy: +miss-islington

___
Python tracker 

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Guido van Rossum]

Guido van Rossum  added the comment:

I was pointed here after we found some erroneous behavior.

We have a script run by the system python that invokes a specific venv's 
python3 with a -m flag requesting a module that is installed (only) in that 
venv. A user complained that this failed, with the venv's python3 claiming the 
module was not installed (but it was, as proved by manually running it with the 
same -m flag).

Eventually someone realized that this was because the system python was a 
python3 installed by homebrew -- somehow this caused the system python (being 
python3) set __PYVENV_LAUNCHER__, and that made the venv's python3 ignore the 
venv's site-packages and instead look in the system python's site-packages.

This feels very wrong.

Maybe this is just a clearer description of https://bugs.python.org/issue31363? 
But that gained no traction while here there is at least some discussion.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue34537] test_gdb fails with LC_ALL=C

[STINNER Victor]

STINNER Victor  added the comment:

I don't think that it's worth it to backport the change to Python 3.6 and 
older, since "LC_ALL=C ./python -m test test_gdb" already pass on 2.7 and 3.6.

--

___
Python tracker 

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

[issue34537] test_gdb fails with LC_ALL=C

[miss-islington]

Change by miss-islington :


--
pull_requests: +8895

___
Python tracker 

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

[issue34537] test_gdb fails with LC_ALL=C

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 7279b5125e7c5d84a473d250b27d353cb7f6628e by Victor Stinner (Elvis 
Pranskevichus) in branch 'master':
bpo-34537: Fix test_gdb:test_strings with LC_ALL=C (GH-9483)
https://github.com/python/cpython/commit/7279b5125e7c5d84a473d250b27d353cb7f6628e


--

___
Python tracker 

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

[issue34576] [EASY doc] http.server, SimpleHTTPServer: warn users on security

[Benjamin Peterson]

Benjamin Peterson  added the comment:

There was some disagreement later on the list about adding this warning. We 
will fix security issues in SimpleHTTPServer.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue34768] Add documentation explaining __init__.py in packages

[Benito Kestelman]

Change by Benito Kestelman :


--
title: Add documentation for the purpose of __init__.py in packages -> Add 
documentation explaining __init__.py in packages

___
Python tracker 

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

[issue30350] devguide suggests to use VS 2008 to build Python 2.7, but VS 2008 is no more supported?

[STINNER Victor]

Change by STINNER Victor :


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

[issue31007] ERROR: test_pipe_handle (test.test_asyncio.test_windows_utils.PipeTests) expected ERROR_INVALID_HANDLE on x86 Windows7 3.x

[STINNER Victor]

Change by STINNER Victor :


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

[issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var

[Elvis Pranskevichus]

Elvis Pranskevichus  added the comment:

Perhaps SOURCE_DATE_EPOCH should only be consulted to determine the default 
behavior if invalidation_mode was not passed explicitly to py_compile.compile().

--

___
Python tracker 

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

[issue31511] test_normalization: test.support.open_urlresource() doesn't handle urllib.error.URLError timeout

[STINNER Victor]

Change by STINNER Victor :


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

[issue31986] [2.7] test_urllib2net.test_sites_no_connection_close() randomly fails on Python 2.7

[STINNER Victor]

Change by STINNER Victor :


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

[issue32706] test_check_hostname() of test_ftplib started to fail randomly

[STINNER Victor]

STINNER Victor  added the comment:

Christian: It seems like the test now pass on my Fedora 27. Is it time to 
enable the test again?

--

___
Python tracker 

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

[issue34763] Python lacks 0x4E17

[Benjamin Peterson]

Benjamin Peterson  added the comment:

As I said on the PR, this is because Unicode gives U+4E17 (and other CJK 
ideographs) a numeric value only in the UniHan database not the normal UCD. 
makeunicodedata.py only looks at UCD for numeric values.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I dislike that having SOURCE_DATE_EPOCH set magically changes command line 
tools behavior. In my view, this problem should be fixed by reverting 
ccbe5818af2.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var

[Elvis Pranskevichus]

Elvis Pranskevichus  added the comment:

> In particular, if a build system sets SOURCE_DATE_EPOCH without
specifying a pyc format for py_compile or compileall, Python 3.7 will
give you checked hashes by default

Actually, py_compile will _force_ the CHECKED_HASH mode if SOURCE_DATE_EPOCH is 
set, regardless of what you specified for py_compile or compileall.  I'm not 
sure if that's actually intended or a bug.

The fix for the tests is to actually be aware of py_compile behavior and 
control for SOURCE_DATE_EPOCH.  I submitted a PR with a fix.

--
nosy: +Elvis.Pranskevichus

___
Python tracker 

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

[issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var

[Elvis Pranskevichus]

Change by Elvis Pranskevichus :


--
keywords: +patch
pull_requests: +8894
stage:  -> patch review

___
Python tracker 

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

[issue32718] Install PowerShell activation scripts for venv for all platforms

[Brett Cannon]

Change by Brett Cannon :


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

[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads

[Yury Selivanov]

Yury Selivanov  added the comment:

> Yury, Andrew: Do you know if the executor doesn't wait on purpose? Would it 
> be possible to change that in Python 3.8?

Maybe.  At least we need to add a "timeout" argument to asyncio.run() to let it 
wait for executor jobs.

I'm also thinking about making OS threads cancellable/interruptable in Python 
3.8 (if they run pure Python code).

--

___
Python tracker 

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

[issue32718] Install PowerShell activation scripts for venv for all platforms

[miss-islington]

miss-islington  added the comment:


New changeset d64ee1a5ba2007ae5fe085dd3495013d940a51bb by Miss Islington (bot) 
(Brett Cannon) in branch 'master':
bpo-32718: Make Activate.ps1 for venv cross-platform and available on all 
platforms (GH-9321)
https://github.com/python/cpython/commit/d64ee1a5ba2007ae5fe085dd3495013d940a51bb


--
nosy: +miss-islington

___
Python tracker 

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

[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads

[STINNER Victor]

STINNER Victor  added the comment:

Yury, Andrew: Do you know if the executor doesn't wait on purpose? Would it be 
possible to change that in Python 3.8?

--

___
Python tracker 

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

[issue34576] [EASY doc] http.server, SimpleHTTPServer: warn users on security

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +easy
title: SimpleHTTPServer: warn users on security -> [EASY doc] http.server, 
SimpleHTTPServer: warn users on security

___
Python tracker 

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

[issue34575] Python 3.6 compilation fails on AppVeyor: libeay.lib was created with an older compiler

[STINNER Victor]

STINNER Victor  added the comment:

It seems like the bug has been fixed. Thanks Zachary Ware for the fix, and 
thanks everybody for helping to fix this cache 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

[issue34561] Replace list sorting merge_collapse()?

[Tim Peters]

Tim Peters  added the comment:

Thank you, Vincent!  I very much enjoyed - and appreciated - your paper I 
referenced at the start.  Way back when, I thought I had a proof of O(N log N), 
but never wrote it up because some details weren't convincing - even to me ;-) 
.  Then I had to move on to other things, and never got back to it.  I was 
probably mistaken.  So it was delightful to see your elegant proof of that, and 
even more.

I'm attaching a new runstack.py that includes code modeling your new adaptive 
Shivers strategy.  Like all these approximations, it has its own "bad cases" on 
smallish inputs.  Based on the specific cases this code runs, powersort remains 
in a category of its own, with timsort, twomerge, and shivers roughly tied on 
_average_ merge cost.

Part of the reason, I suspect:  powersort is the only strategy here that's 
always optimal for 3-run cases.  Which it buys at the cost of never merging the 
run just discovered (unless it's the last run in the array).  For example, in

31, 16, 1

twomerge and shivers merge 31 and 16 first, before seeing 1, which is "far 
from" optimal.  timsort and powersort merge 16 and 1 first, although that's by 
design in powersort and by luck in timsort.  In

16, 31, 1

only powersort does the best thing (note: runstack.py doesn't model peeksort; 
I'm sure it would merge 31 and 1 first on that too).

I care about small-number-of-runs because real-life Python lists aren't 
asymptotic in nature ;-)  People deliberately construct lists with a small 
number of runs now before sorting, because they know Python's sort can exploit 
that.  For many other cases, all runs are artificially forced to length 
`minrun`, and then any scheme at all that approximates balanced merging is 
about as good as any other.

What I can't know before we time things is whether order-of-merging makes a 
measurable difference in real life, and whether powersort's possible delay in 
merging the most recent run has bad cache effects that overwhelm its smaller 
"merge cost".

In any case, I'm keen to replace timsort's merge-order strategy with 
_something_ that's much easier to analyze.  The makes your Shivers variant and 
powersort the only two real contenders now.  It seems quite remarkable that the 
Shivers variant has such good asymptotics!  It's certainly the easiest to 
modify Python's C code to implement (straightforward edits in a single 
function).

--
Added file: https://bugs.python.org/file47818/runstack.py

___
Python tracker 

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

[issue34751] Hash collisions for tuples

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

I pushed a minor update to the PR, changing the MULTIPLIER and explaining the 
chosen constants.

--

___
Python tracker 

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

[issue34744] New %(flag)s format specifier for argparse.add_argument help string

[paul j3]

paul j3  added the comment:

In your proposed change:

params = dict(vars(action), prog=self._prog)
  +  if action.option_strings:
  +  params['flag'] = action.option_strings[0]

'params', as I noted earlier already includes the 'dest' and 'option_strings' 
list.  

'option_strings' is already being used in '_format_action_invocation()'.  So I 
don't see why this flag needs to appear again in the help line.  Though the 
user can certainly hard code it into the line when defining the 'add_argument'

e.g.

cmdline.add_argument('--complex-argument', help='format --complex-argument 
key1=value1,key2=value2')

What's special about the comma-separated key/value input?

A patch/pull-request needs needs documentation, and unittest.  It appears to be 
innocuous from a testing stand point, but good documentation could be problem - 
it could easily end up being confusing without adding much value. 

I propose closing this because I don't think it is needed.

--

___
Python tracker 

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

[issue34537] test_gdb fails with LC_ALL=C

[Elvis Pranskevichus]

Change by Elvis Pranskevichus :


--
keywords: +patch
pull_requests: +8893
stage:  -> patch review

___
Python tracker 

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

[issue34764] Improve documentation example for using iter() with sentinel value

[ChrisRands]

ChrisRands  added the comment:

Thank you Raymond, I like both your examples, although I think I prefer 1) for 
the simplicity

--

___
Python tracker 

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

[issue34750] locals().update doesn't work in Enum body, even though direct assignment to locals() does

[Dan Snider]

Dan Snider  added the comment:

It's working as intended. locals() and vars() simply returns the current 
frame's f_locals. In functions, modifying this usually accomplishes nothing 
useful because the code object has OPTIMIZED and NEWLOCALS flags set, meaning 
local variables are looked up or set via the LOAD_FAST and STORE_FAST opcodes 
(respectively) which doesn't even look in the f_locals mapping. In this case, 
vars() and locals() will build a new dict[*] and fill it with the frame's 
fastlocals and unpack any closure cells into it.

The code object used for class bodies however is special and actually *does* 
use the mapping in f_locals, which for for classes ultimately built by 
builtins.__build_class__ (aka classes built with a `class` statement) will be 
whatever the metaclass's __prepare__ returns, which in the case of enums is an 
enum._EnumDict instance. 

So that's why metaclasses are so powerful. You don't even need to use a 
dictionary subclass as the class namespace, since the STORE_NAME opcode will 
use PyObject_SetItem; however type.__new__ will make you cast it to a dict, and 
even the dict that is wrapped by a MappingProxy after the class has been 
created will be a copy anyway. 

So anyway, there's nothing actually wrong with the current behavior. 
dict.update never calls `self.__getitem__`, and since `_EnumDict.__setitem__` 
is where all of the magic happens regular dict.update won't trigger it. I agree 
though that adding an update method would be nice though and can be done in 
just a few lines of code.

import enum
import sys

def local_update(it=(), **kws):
self = sys._getframe(1).f_locals
d = dict(it, **kws)
for k, v in d.items():
self[k] = v

class MyEnum(enum.Enum):
local_update(a=1, b=2)

assert MyEnum.a.value == 1

[*] it doesn't actually build a new one every time but the only practical 
purpose with the NEWLOCALS code.co_code flag set is for introspection with 
vars(), locals(), and sys._getframe

--
nosy: +bup

___
Python tracker 

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

[issue32892] Remove specific constant AST types in favor of ast.Constant

[STINNER Victor]

STINNER Victor  added the comment:

> * If the user of NodeVisitor implemented visit_Num(), but not implemented 
> visit_Constant(), his handler will not be triggered. This can be easily fixed 
> by implementing visit_Constant(). Constant was introduced in 3.6.

IHMO that's an acceptable tradeoff. We should just make sure that it's properly 
documented in the Porting section of What's New in Python 3.8.

> * issubclass() check and exact type check. `issubclass(type(node), Num)` and 
> `type(node) is Num` will return False for node = Num(42). But seems 
> isinstance() is a more common way of checking the type of a node.

In the AST code that I read, isinstance() was the most popular way to check the 
type of a node. I don't recall any AST code using issubclass.

> isinstance() check for underinitialized node. `isinstance(Num(), Num)` will 
> return False.

I don't think that it's an issue. 

--

In term of optimization, I'm curious, do you know if your PR optimize more 
cases than previously? Or do you expect futher optimizations later thanks to 
this change?

--

___
Python tracker 

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

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

[Mario]

Mario  added the comment:

On 21/09/2018 21:44, Steve Dower wrote:
> 
> Steve Dower  added the comment:
> 
> I meant returning the full name of the process is intentional. But you're 
> right that overriding it should actually override it.
> 
> I found the prior bug at issue33180, but I'm closing it in favour of this 
> one. I don't have fully fleshed out semantics in my mind for all the cases to 
> handle here, but I hope that we soon reach a point of drastically simplifying 
> getpath and can align the platforms better at that point.
> 
> Meanwhile I'll leave this open in case anyone wants to work on a targeted fix.
> 

So you are saying that the Windows behaviour (+ ability to overwrite) is 
intentional.
This looks to me in contrast to what the doc says under 
https://docs.python.org/3/c-api/init.html#c.Py_GetProgramFullPath.

Moreover I am not sure what Py_SetProgramName() is meant to do then.

The problem in my opinion is that we are trying to fit 2 things in the same 
field: the real 
executable name and the root of the python installation (which could be a 
virtual environment as well).
In python.exe the 2 are the same (or linked), but for embedded applications 
they are not.

Remember that site.py uses the sys.executable as "root of the python 
installation" to derive the 
path and handle virtual environments.

I think that if these 2 concepts were separated, it would be much easier to 
explain the desired 
behaviour and find a valid implementation in Window and Linux.

Let's say sys.executable is the full name of the process and sys.python_root is 
the folder from 
which to derive all the paths.

It is probably too big of a change, but it might be useful to write down the 
ideal behaviour before 
thinking of a pragmatic solution.

Andrea

--

___
Python tracker 

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

[issue32892] Remove specific constant AST types in favor of ast.Constant

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> Can you describe what usages of the old API will continue to work, and what 
> part will break?

Very good question!

What will continue to work:

* Instantiating. Both `Num(42)` and `Num(n=42)` will continue to work, but they 
will return an instance of Constant: Constant(value=42).

* Attribute access. Constant will get attributes "n" and "s" as aliases to the 
attribute "value". So Num(42).n will continue to return 42. 

* isinstance() check. Although `isinstance(Num(42), Num)` will continue to 
return True, and `isinstance(Str('42'), Num)` will continue to return False. 
Also `isinstance(Constant(42), Num)` will return True and 
`isinstance(Constant('42'), Num)` will return False.

* Subclassing. Subclasses of these classes will continue to behave as normal 
classes. Instantiating them will return instances of that classes, not 
Constant, and the isinstance() check will not have any magic.

What will no longer work:

* issubclass() check and exact type check. `issubclass(type(node), Num)` and 
`type(node) is Num` will return False for node = Num(42). But seems 
isinstance() is a more common way of checking the type of a node.

* If the user of NodeVisitor implemented visit_Num(), but not implemented 
visit_Constant(), his handler will not be triggered. This can be easily fixed 
by implementing visit_Constant(). Constant was introduced in 3.6.

* isinstance() check for underinitialized node. `isinstance(Num(), Num)` will 
return False.

--

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +8892

___
Python tracker 

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

[issue34700] typing.get_type_hints doesn't know about typeshed

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

I think there is also a fourth option: add a flag to `get_type_hints()` that 
will guard evaluation of forward references, as proposed in 
https://github.com/python/typing/issues/508. If the evaluation of a "forward 
reference" raises an error, then we keep it unevaluated (i.e. a string).

--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

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

[issue21983] segfault in ctypes.cast

[Steve Dower]

Steve Dower  added the comment:

Still needs a backport to 2.7

--

___
Python tracker 

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

[issue33091] ssl.SSLError: Invalid error code (_ssl.c:2217)

[Steve Dower]

Change by Steve Dower :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> SSLSocket read/write thread-unsafety

___
Python tracker 

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

[issue32533] SSLSocket read/write thread-unsafety

[Steve Dower]

Steve Dower  added the comment:

Fixed, with a fix for the regression coming in issue34759

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

[issue32556] support bytes paths in nt _getdiskusage, _getvolumepathname, and _getfinalpathname

[Steve Dower]

Change by Steve Dower :


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

[issue33016] nt._getfinalpathname may use uninitialized memory

[Steve Dower]

Change by Steve Dower :


--
resolution:  -> fixed
stage: commit 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

[issue32282] When using a Windows XP compatible toolset, `socketmodule.c` fails to build

[Steve Dower]

Steve Dower  added the comment:

I'm going to just close this without fixing 3.5. If there's demand, we can 
consider it, but at this stage it's so easy for people to migrate to 3.6 or 
later that I'm sure that's already been done.

--
resolution:  -> fixed
stage: backport needed -> 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

[issue33180] Flag for unusable sys.executable

[Steve Dower]

Steve Dower  added the comment:

Closing in favour of issue34725

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

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

[Steve Dower]

Steve Dower  added the comment:

I meant returning the full name of the process is intentional. But you're right 
that overriding it should actually override it.

I found the prior bug at issue33180, but I'm closing it in favour of this one. 
I don't have fully fleshed out semantics in my mind for all the cases to handle 
here, but I hope that we soon reach a point of drastically simplifying getpath 
and can align the platforms better at that point.

Meanwhile I'll leave this open in case anyone wants to work on a targeted fix.

--

___
Python tracker 

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

[issue34763] Python lacks 0x4E17

[STINNER Victor]

STINNER Victor  added the comment:

$ ./python
Python 3.8.0a0 (heads/master-dirty:06e7608207, Sep 20 2018, 01:52:01) 
>>> import unicodedata
>>> unicodedata.unidata_version
'11.0.0'
>>> unicodedata.numeric('\u5345')
30.0
>>> unicodedata.numeric('\u4E17')
ValueError: not a numeric character

--

___
Python tracker 

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

[issue33649] asyncio docs overhaul

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset e45662c28bfc84aa3674463a2995e45da4d63793 by Yury Selivanov (Miss 
Islington (bot)) in branch '3.7':
bpo-33649: Fix gather() docs; fix title; few other nits. (GH-9475) (GH-9481)
https://github.com/python/cpython/commit/e45662c28bfc84aa3674463a2995e45da4d63793


--

___
Python tracker 

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

[issue33782] VSTS Windows-PR: internal error

[Steve Dower]

Change by Steve Dower :


--
resolution:  -> fixed
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

[issue34751] Hash collisions for tuples

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

Concerning the MULTIPLIER:

> Why do you claim the original was "too small"?  Too small for what purpose?

If the multiplier is too small, then the resulting hash values are small too. 
This causes collisions to appear for smaller numbers:

BEFORE:
>>> L = [(a,b) for a in range(2) for b in range(2**21)]
>>> len(L), len(set(hash(x) for x in L))
(4194304, 2097152)

AFTER:
>>> L = [(a,b) for a in range(2) for b in range(2**21)]
>>> len(L), len(set(hash(x) for x in L))
(4194304, 4194304)

Again, not a huge problem, but at least there is room for improvement.

> Why, when raising it to the third power apparently didn't work, did you pull 
> "2" out of a hat?  What was _the cause_ of the "sporadic failure" (whatever 
> that means)

With "sporadic failure", I mean a hash collision not due to the algorithm but 
due to two numbers which happen to be the same. This might not even affect 
actual usage, but it did cause the testsuite to fail on 32 bit machines (48 
collisions if I recall correctly while only 20 are allowed).

> and why did adding 2 fix it?

Because it's really just random chance. Some constants just happen to produce 
more collisions on the specific testsuite input. It should also be said that, 
due to the structure of that input, collisions are not independent. For 
example, if hash((a,b,c)) == hash((d,e,f)), then also hash((a,b,c,x)) == 
hash((d,e,f,x)) for example.

> Why isn't there a single word in _the code_ about where the mystery numbers 
> came from?

Ideally, it should be just a random number. I can fix that by using a "Nothing 
up my sleeve number".

--

___
Python tracker 

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

[issue33649] asyncio docs overhaul

[miss-islington]

Change by miss-islington :


--
pull_requests: +8891

___
Python tracker 

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

[issue34267] find_python.bat doesn't find installed Python 3.7

[Steve Dower]

Change by Steve Dower :


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

[issue33649] asyncio docs overhaul

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset db1a80e97aa7217c561fb3627f70be1882de9534 by Yury Selivanov in 
branch 'master':
bpo-33649: Fix gather() docs; fix title; few other nits. (GH-9475)
https://github.com/python/cpython/commit/db1a80e97aa7217c561fb3627f70be1882de9534


--

___
Python tracker 

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

[issue32892] Remove specific constant AST types in favor of ast.Constant

[STINNER Victor]

STINNER Victor  added the comment:

Hum, I'm not sure that I understood correctly: does "isinstance(node, ast.Num)" 
still work with the patch? If yes, I see no reason to not merge the change ;-)

--

___
Python tracker 

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

[issue34751] Hash collisions for tuples

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> FWIW, the current algorithm also has some advantages that we don't want to 
> lose. In particular, the combination of the int hash and tuple hash are good 
> at producing distinct values for non-negative numbers:

>>> from itertools import product
>>> len(set(map(hash, product(range(100), repeat=4
1

FWIW: the same is true for my new hash function

--

___
Python tracker 

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

[issue34762] Change contextvars C API to use PyObject

[Yury Selivanov]

Yury Selivanov  added the comment:

Fixed in master and 3.7.  Thanks!

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

___
Python tracker 

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

[issue34762] Change contextvars C API to use PyObject

[Yury Selivanov]

Yury Selivanov  added the comment:

PEP update: 
https://github.com/python/peps/commit/977a94d1a79b71336568119eb689b277d2ffec80

--

___
Python tracker 

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

[issue34751] Hash collisions for tuples

[Tim Peters]

Tim Peters  added the comment:

Oops!

"""
"j odd implies j^(-2) == -j, so that m*(j^(-2)) == -m"
"""

The tail end should say "m*(j^(-2)) == -m*j" instead.

--

___
Python tracker 

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

[issue34762] Change contextvars C API to use PyObject

[miss-islington]

miss-islington  added the comment:


New changeset 187f2dd256a917c20bf55954d019fd35fb46ab08 by Miss Islington (bot) 
in branch '3.7':
bpo-34762: Fix contextvars C API to use PyObject* pointer types. (GH-9473)
https://github.com/python/cpython/commit/187f2dd256a917c20bf55954d019fd35fb46ab08


--
nosy: +miss-islington

___
Python tracker 

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

[issue34751] Hash collisions for tuples

[Tim Peters]

Tim Peters  added the comment:

For me, it's largely because you make raw assertions with extreme confidence 
that the first thing you think of off the top of your head can't possibly make 
anything else worse.  When it turns out it does make some things worse, you're 
equally confident that the second thing you think of is (also) perfect.

So far we don't even have a real-world test case, let alone a coherent 
characterization of "the problem":

"""
all involving negative numbers) due to the same underlying mathematical reason.
"""

is a raw assertion, not a characterization.  The only "mathematical reason" you 
gave before is that "j odd implies j^(-2) == -j, so that m*(j^(-2)) == -m".  
Which is true, and a good observation, but doesn't generalize as-is beyond -2.

Stuff like this from the PR doesn't inspire confidence either:

"""
MULTIPLIER = (103)**3 + 2 = 1092729: the multiplier should be 
big enough and the original 20-bit number is too small for a 64-bit hash. So I 
took the third power. Unfortunately, this caused a sporadic failure of the 
testsuite on 32-bit systems. So I added 2 which solved that problem.
"""

Why do you claim the original was "too small"?  Too small for what purpose?  As 
before, we don't care whether Python hashes "act random".  Why, when raising it 
to the third power apparently didn't work, did you pull "2" out of a hat?  What 
was _the cause_ of the "sporadic failure" (whatever that means), and why did 
adding 2 fix it?  Why isn't there a single word in _the code_ about where the 
mystery numbers came from?:

You're creating at least as many mysteries as you're claiming to solve.

We're not going to change such heavily used code on a whim.

That said, you could have easily enough _demonstrated_ that there's potentially 
a real problem with a mix of small integers of both signs:

>>> from itertools import product
>>> cands = list(range(-10, -1)) + list(range(9))
>>> len(cands)
18
>>> _ ** 4
104976
>>> len(set(hash(t) for t in product(cands, repeat=4)))
35380

And that this isn't limited to -2 being in the mix (and noting that -1 wasn't 
in the mix to begin with):

>>> cands.remove(-2)
>>> len(cands) ** 4
83521
>>> len(set(hash(t) for t in product(cands, repeat=4)))
33323

If that's "the problem", then - sure - it _may_ be worth addressing.  Which we 
would normally do by looking for a minimal change to code that's been working 
well for over a decade, not by replacing the whole thing "just because".

BTW, continuing the last example:

>>> c1 = Counter(hash(t) for t in product(cands, repeat=4))
>>> Counter(c1.values())
Counter({1: 11539, 2: 10964, 4: 5332, 3: 2370, 8: 1576, 6: 1298, 5: 244})

So despite that there were many collisions, the max number of times any single 
hash code appeared was 8.  That's unfortunate, but not catastrophic.

Still, if a small change could repair that, fine by me.

--

___
Python tracker 

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

[issue34751] Hash collisions for tuples

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> Further, that example specifically exploits that "hash(-1) == hash(-2)"

No, it does not. There is no hashing of -1 involved in the example 
hash((1,0,0)) == hash((1,-2,-2)).

--

___
Python tracker 

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

[issue34762] Change contextvars C API to use PyObject

[miss-islington]

Change by miss-islington :


--
pull_requests: +8890

___
Python tracker 

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

[issue34762] Change contextvars C API to use PyObject

[Yury Selivanov]

Yury Selivanov  added the comment:


New changeset 2ec872b31e25cee1f983fe07991fb53f3fd1cbac by Yury Selivanov in 
branch 'master':
bpo-34762: Fix contextvars C API to use PyObject* pointer types. (GH-9473)
https://github.com/python/cpython/commit/2ec872b31e25cee1f983fe07991fb53f3fd1cbac


--

___
Python tracker 

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

[issue34768] Add documentation for the purpose of __init__.py in packages

[Benito Kestelman]

New submission from Benito Kestelman :

I just learned how to make my own package in python and upload it to pypi. I 
mainly used the documentation here: 
https://packaging.python.org/tutorials/packaging-projects/

Other than the toy example, there is no explanation of __init__.py, its 
purpose, or what I should put in it to get my code to work. 

It took me a lot of time and guessing to figure it out, and I had to look at 
several projects on Github to see how others did it. I found a couple that 
looked correct because they were concise, but others looked horrendous - one 
was several thousand lines long. 

A clear explanation of how to use __init__.py when making a package would be 
extremely helpful.

--
assignee: docs@python
components: Documentation
messages: 326020
nosy: bkestelman, docs@python
priority: normal
severity: normal
status: open
title: Add documentation for the purpose of __init__.py in packages

___
Python tracker 

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

[issue34751] Hash collisions for tuples

[Raymond Hettinger]

Raymond Hettinger  added the comment:

ISTM the collision of "hash((1,0,0)) == hash((1,-2,-2))" also stems from 
integers hashing to themselves and that twos-complement arithmetic relation, -x 
== ~x+1.  Further, that example specifically exploits that "hash(-1) == 
hash(-2)" due to how error codes.  In a way, tuple hashing is incidental.

Occasional collisions aren't really a big deal -- it is normal for dicts to 
have some collisions and to resolve them.  I would be more concerned is 
non-contrived datasets had many elements that gave exactly the same hash value 
resulting in a pile-up in one place.

FWIW, the current algorithm also has some advantages that we don't want to 
lose. In particular, the combination of the int hash and tuple hash are good at 
producing distinct values for non-negative numbers:

>>> from itertools import product
>>> len(set(map(hash, product(range(100), repeat=4
1

The current hash is in the pretty-darned-good category and so we should be 
disinclined to change battle-tested code that is known to work well across a 
broad range of use cases.

--

___
Python tracker 

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

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

[Christian Heimes]

Christian Heimes  added the comment:

CVE-2018-14647 was assigned to this issue.

--

___
Python tracker 

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

[issue34751] Hash collisions for tuples

[Eric V. Smith]

Eric V. Smith  added the comment:

I'm not one to judge the effectiveness of a new hash algorithm. But my personal 
concern here is making something else worse: an unintended consequence. IMO the 
bar for changing this would be very high, and at the least it would need to be 
addressing a known, not theoretical, problem.

That said, I'll let the experts debate your proposed change.

--

___
Python tracker 

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

[issue34764] Improve documentation example for using iter() with sentinel value

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I concur that the readline() example is problematic.  While it succeeds in 
showing how iter() works, the example itself is not the best way to solve that 
particular problem.

Here are two possible substitute examples.

1) Simple example that focuses primarily on the behavior of iter() and required 
little extra knowledge:


>>> from random import randint
>>> def roll_dice():
return randint(1, 6) + randint(1, 6)

>>> # roll until a seven is seen
>>> list(iter(roll_dice, 7))
>>> list(iter(roll_dice, 7))
[10, 6, 5, 6, 8]

2) Practical application reading binary files in fixed-width blocks for 
processing with the structure module.  This also teaches how to partial() to 
produce an arity-zero callable suitable for use with iter().

>>> Read fixed-width blocks from a database binary file
>>> from functools import partial
>>> with open('mydata.db', 'rb') as f:
for block in iter(partial(f.read, 64)):
print(parse_struct(block))

--
nosy: +rhettinger

___
Python tracker 

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

[issue34751] Hash collisions for tuples

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

I should also make it clear that the collision hash((1,0,0)) == hash((1,-2,-2)) 
that I reported is due to the algorithm, it's not due to some bad luck that 2 
numbers happen to be the same. There are also many more similar hash collisions 
for tuples (all involving negative numbers) due to the same underlying 
mathematical reason.

I still don't understand why you don't consider it a problem. It may be a tiny 
problem, not really affecting the correct functioning of CPython. But, if we 
can fix this tiny problem, why shouldn't we?

--

___
Python tracker 

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

[issue34763] Python lacks 0x4E17

[Matthew Barnett]

Change by Matthew Barnett :


--
Removed message: https://bugs.python.org/msg326012

___
Python tracker 

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

[issue34763] Python lacks 0x4E17

[Matthew Barnett]

Change by Matthew Barnett :


--
Removed message: https://bugs.python.org/msg326014

___
Python tracker 

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

[issue34763] Python lacks 0x4E17

[Matthew Barnett]

Change by Matthew Barnett :


--
Removed message: https://bugs.python.org/msg326013

___
Python tracker 

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

[issue34763] Python lacks 0x4E17

[Matthew Barnett]

Change by Matthew Barnett :


--
Removed message: https://bugs.python.org/msg326015

___
Python tracker 

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

[issue34763] Python lacks 0x4E17

[Matthew Barnett]

Matthew Barnett  added the comment:

Unicode 11.0.0 has 卅 (U+5345) as being numeric and having the value 30.

What's the difference between that and U+4E17?

I notice that they look at lot alike. Are they different variants, perhaps 
traditional vs simplified?

--

___
Python tracker 

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

[issue34763] Python lacks 0x4E17

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

We use the Unicode database for these methods. Could you please check whether 
the database marks the character as numeric ?

If yes, we may need to check the database generation.

Otherwise, there isn't much we can do, since we use the Unicode database as 
reference.

Thanks
-- 
Marc-Andre Lemburg

Sent from my phone. 
See http://www.egenix.com/company/ for contact information
and impressum.

On 21 September 2018 18:38:05 GMT+02:00, Serhiy Storchaka 
 wrote:
> 
> Change by Serhiy Storchaka :
> 
> 
> --
> nosy: +lemburg
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue34762] Change contextvars C API to use PyObject

[Ned Deily]

Ned Deily  added the comment:

Since we've already delayed 3.7.1rc cutoff for a few days, let's get it into 
3.7.1 if you have the time, Yury.

--

___
Python tracker 

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

[issue34761] str(super()) != super().__str__()

[Eric Snow]

Eric Snow  added the comment:

As Serhiy said, this is the correct behavior.  Nearly all builtin operations 
are made using the appropriate "dunder" method from the object's type (not 
looked up on the object itself).  So the following (based on your example) are 
equivalent:

  s = super(Child, self)
  print(type(s).__str__(s))
  print(str(s))

In contrast, explicitly calling __str__() on the instance involves lookup 
there, so the following are equivalent:

  s = super(Child, self)
  print(s.__str__())
  print(type(s).__getattribute__(s, '__str__')())

You can read more about "dunder" (AKA "special") methods and how they are 
looked up in the docs. [1][2][3]

I'm going to close this issue, but if you think there's anything further we can 
do in the documentation to avoid confusion then please let us know.


[1] https://docs.python.org/3/reference/datamodel.html#special-lookup
[2] https://docs.python.org/3/reference/datamodel.html#special-method-names
[3] 
https://docs.python.org/3/library/inspect.html#fetching-attributes-statically

--
nosy: +eric.snow
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

[issue34766] BaseProxy cache should be cleaned when Manager client is reconnected

[Yongnan Wu]

Change by Yongnan Wu :


--
keywords: +patch
pull_requests: +8889
stage:  -> patch review

___
Python tracker 

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

[issue34762] Change contextvars C API to use PyObject

[Stefan Behnel]

Stefan Behnel  added the comment:

> because Py_buffer isn't a PyObject at all :)

It owns a PyObject reference to the buffer owner, though.

--
nosy: +scoder

___
Python tracker 

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

[issue32892] Remove specific constant AST types in favor of ast.Constant

[Neil Schemenauer]

Neil Schemenauer  added the comment:

As someone who does AST manipulation (Quixote PTL template support), I'm 
interested in this patch. I think what is proposed sounds like a good change.  
I.e. having the extra node types is not useful and makes the compiler harder to 
understand.  Providing subclasses for backwards compatibility would be nice.  I 
will test my Quixote package with Serhiy's patch.

--
nosy: +nascheme

___
Python tracker 

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