[issue38547] test_pty fails when using setsid()

[David Bolen]

Change by David Bolen :


--
nosy: +db3l

___
Python tracker 

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

[issue38483] [venv] Add ~/.venvrc to change module defaults

[Cooper Lees]

Cooper Lees  added the comment:

Good point. Happy to match the virtualenv module and use `.ini` if others agree.

--

___
Python tracker 

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

[issue38483] [venv] Add ~/.venvrc to change module defaults

[Laurie Opperman]

Laurie Opperman  added the comment:

".xrc" usually means a file to be run (by a shell) at shell start, and 
therefore is a script of command to run ("rc" seems to come from "runcom", ie 
run commands).

INI files usually have a ".ini" or ".cfg" suffix. `virtualenv`, for example, 
used an INI file similar to your proposal: 
https://virtualenv.pypa.io/en/stable/reference/#configuration-file.

--
nosy: +Epic_Wink

___
Python tracker 

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

[issue38554] A fatal error in test_descr

[Zackery Spytz]

Change by Zackery Spytz :


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

___
Python tracker 

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

[issue38554] A fatal error in test_descr

[Zackery Spytz]

New submission from Zackery Spytz :

When running test_descr, I encountered a fatal error!


./python -m test test_descr
0:00:00 load avg: 0.46 Run tests sequentially
0:00:00 load avg: 0.46 [1/1] test_descr
python: Objects/typeobject.c:7318: update_one_slot: Assertion 
`!PyErr_Occurred()' failed.
Fatal Python error: Aborted

Current thread 0x7ff22eb72140 (most recent call first):
  File "/home/lubuntu2/cpython/Lib/test/test_descr.py", line 3923 in 
test_mutable_bases
  File "/home/lubuntu2/cpython/Lib/unittest/case.py", line 617 in 
_callTestMethod
  File "/home/lubuntu2/cpython/Lib/unittest/case.py", line 663 in run
  File "/home/lubuntu2/cpython/Lib/unittest/case.py", line 725 in __call__
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/lubuntu2/cpython/Lib/test/support/testresult.py", line 162 in run
  File "/home/lubuntu2/cpython/Lib/test/support/__init__.py", line 2032 in 
_run_suite
  File "/home/lubuntu2/cpython/Lib/test/support/__init__.py", line 2128 in 
run_unittest
  File "/home/lubuntu2/cpython/Lib/test/test_descr.py", line 5643 in test_main
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 234 in 
_runtest_inner2
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 270 in 
_runtest_inner
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 153 in 
_runtest
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 193 in 
runtest
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 417 in 
run_tests_sequential
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 515 in 
run_tests
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 687 in _main
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 634 in main
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 712 in main
  File "/home/lubuntu2/cpython/Lib/test/__main__.py", line 2 in 
  File "/home/lubuntu2/cpython/Lib/runpy.py", line 85 in _run_code
  File "/home/lubuntu2/cpython/Lib/runpy.py", line 192 in _run_module_as_main
Aborted (core dumped)

This is because update_all_slots() is called immediately after 
add_all_subclasses() in type_set_bases(). If an exception occurs in 
add_all_subclasses() (for example, MemoryError), update_all_slots() will be 
called with a live exception.

--
components: Interpreter Core
messages: 355113
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A fatal error in test_descr
versions: 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

[issue38553] Document functools.cached_property supports value updating and clearing

[Laurie Opperman]

Laurie Opperman  added the comment:

@hongweipeng What can be solved? Do you mean `functools.cached_property` should 
inherit `property`? First, this would break existing code dependant on the 
functionality of `functools.cached_property` (admittedly, Python 3.8 was 
release less than two weeks ago). Second, that seems like arbitrary 
restriction: I'd prefer just to update the documentation

--

___
Python tracker 

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

[issue38553] Document functools.cached_property supports value updating and clearing

[hongweipeng]

hongweipeng  added the comment:

It can be solved by extending propery. `class cached_property(property):` . How 
about this idea?

--
nosy: +hongweipeng

___
Python tracker 

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

[issue38539] Update demo files

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Let's just do the rename for ss1.py.

--

___
Python tracker 

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

[issue38328] Speed up the creation time of constant list literals.

[Brandt Bucher]

Change by Brandt Bucher :


--
pull_requests: +16423
pull_request: https://github.com/python/cpython/pull/16878

___
Python tracker 

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

[issue38553] Document functools.cached_property supports value updating and clearing

[Laurie Opperman]

New submission from Laurie Opperman :

As I discovered during working on bpo-38545, `functools.cached_property` 
natively supports cached value setting/updating and clearing (via attribute 
assignment and deletion, respectively) through mechanisms defined in the 
language for non-data descriptors:

class A:
j = 0

@functools.cached_property
def b(self):
self.j += 1
return self.j

a = A()
print(a.b)  # 1
print(a.b)  # 1
del a.b
print(a.b)  # 2
print(a.b)  # 2
a.b = 42
print(a.b)  # 42
print(a.b)  # 42
del a.b
print(a.b)  # 3
print(a.b)  # 3

I propose that this functionality be documented, for two reasons:
1. To notify developers that this functionality is available, and how to access 
it
2. To notify developers that this functionality needs to be explicitly 
disabled. This is important as the built-in `property` is the reverse: property 
setting and deletion needs to be explicitly implemented

Disabling the value can be achieved by subclassing `functools.cached_property` 
and overriding/implementing `__set__` and `__delete__` to raise:

class immutable_cached_property(functools.cached_property):
def __set__(self, instance, value):
raise AttributeError("can't set attribute")

def __delete__(self, instance):
raise AttributeError("can't delete attribute")

Further reading:
- Defining descriptors: 
https://docs.python.org/3/reference/datamodel.html#implementing-descriptors
- Descriptor how-to: https://docs.python.org/3/howto/descriptor.html
- Class construction: 
https://docs.python.org/3/reference/datamodel.html#creating-the-class-object

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 355110
nosy: Epic_Wink, docs@python
priority: normal
severity: normal
status: open
title: Document functools.cached_property supports value updating and clearing
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue38551] lib2to3 Grammar.txt doesn't have Python 3.8 grammar changes

[Peter Ludemann]

Peter Ludemann  added the comment:

Should I just close this? (I didn't find https://bugs.python.org/issue36541 
when I searched, possibly because I used "2to3" instead of "lib2to3" in my 
search.)

--

___
Python tracker 

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

[issue36541] Make lib2to3 grammar more closely match Python

[Peter Ludemann]

Peter Ludemann  added the comment:

Re: breakage due to changes in structure 
(https://bugs.python.org/issue36541#msg339669) ... this has already happened in 
the past (e.g., type annotations and async). 

It's probably a good idea to add some documentation that structure changes can 
be expected with each release of Python.

--
nosy: +Peter Ludemann

___
Python tracker 

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

[issue38546] test_concurrent_futures: test_interpreter_shutdown() warning "reap_children() reaped child process" on AMD64 RHEL7 3.x

[STINNER Victor]

STINNER Victor  added the comment:

The system load was at 10.02 when the bug occurred:

> https://buildbot.python.org/all/#/builders/254/builds/162

...
0:04:11 load avg: 10.02 [230/419] test_pkgutil passed -- running: test_io (2 
min 46 sec), test_capi (1 min 12 sec), test_concurrent_futures (2 min 43 sec), 
test_mailbox (2 min 40 sec), test_tokenize (30.6 sec)
0:04:12 load avg: 10.02 [231/419] test_getpass passed -- running: test_io (2 
min 47 sec), test_capi (1 min 13 sec), test_concurrent_futures (2 min 43 sec), 
test_mailbox (2 min 41 sec), test_tokenize (31.1 sec)
0:04:12 load avg: 10.02 [232/419] test_sys passed -- running: test_io (2 min 47 
sec), test_capi (1 min 13 sec), test_concurrent_futures (2 min 43 sec), 
test_mailbox (2 min 41 sec), test_tokenize (31.3 sec)
0:04:12 load avg: 10.02 [233/419] test_winconsoleio skipped -- running: test_io 
(2 min 48 sec), test_capi (1 min 13 sec), test_concurrent_futures (2 min 44 
sec), test_mailbox (2 min 41 sec), test_tokenize (31.7 sec)
test_winconsoleio skipped -- test only relevant on win32
0:04:13 load avg: 10.02 [234/419/1] test_concurrent_futures failed (env 
changed) (2 min 44 sec) -- running: test_io (2 min 48 sec), test_capi (1 min 14 
sec), test_mailbox (2 min 42 sec), test_tokenize (32.0 sec)
...
test_crash (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) 
... 4.22s ok
test_shutdown_deadlock 
(test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) ... 1.03s ok
test_initializer 
(test.test_concurrent_futures.ProcessPoolSpawnFailingInitializerTest) ... 0.51s 
ok
test_initializer (test.test_concurrent_futures.ProcessPoolSpawnInitializerTest) 
... 0.54s ok
test_free_reference 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.67s ok
test_killed_child 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.49s ok
test_map (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) 
... 0.56s ok
test_map_chunksize 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.46s ok
test_map_exception 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.46s ok
test_map_timeout 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
6.48s ok
test_max_workers_negative 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.57s ok
test_max_workers_too_large 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
skipped 'Windows-only process limit'
test_no_stale_references 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.56s ok
test_ressources_gced_in_workers 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
1.90s ok
test_shutdown_race_issue12456 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.54s ok
test_submit 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.52s ok
test_submit_keyword 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.57s ok
test_traceback 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.48s ok
test_context_manager_shutdown 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 
0.03s ok
test_del_shutdown 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 
0.02s ok
test_hang_issue12364 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 
1.45s ok
test_interpreter_shutdown 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 
1.62s 
Warning -- reap_children() reaped child process 28936
ok
test_processes_terminate 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 
0.47s ok
test_run_after_shutdown 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 
0.00s ok

--

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

Michel Desmoulin: "The relevance of the use case isn't the problem. Even if 
people had been using it wrong for all this time, the update is still going to 
break their code if they did use it this way. And if it was possible, of course 
many people did."

You have to understand that the change has be done to fix some use cases and 
that Python 3.8.0 has been related with the change.

If we change again the behavior, we will get Python < 3.8.0, Python 3.8.0 and 
Python > 3.8.0 behaving differently. I would prefer to fully understand all use 
cases before starting to discuss changing the behavior again.


> 3.7 already broke a few packages by choosing to not do the True/False dance 
> again and make async/await keywords. I took a lot of people by surprise, not 
> because of the issue itself, but because of the change of philosophy compared 
> of what Python had been in the past.

You have to understand that it was known since the start and it was a 
deliberate choice after balancing advantages and disadvantages.

https://www.python.org/dev/peps/pep-0492/#transition-plan

I'm only aware of a single function in a single project, Twisted. Are you aware 
of more projects broken by this change? Did it take long to fix them? Balance 
it with the ability to use async and await in cases which were not possible in 
Python 3.6 because they were not real keywords. The Python 3.6 grammar was 
fully of hack to emulate keywords.


> Do we really want to make a habit of breaking a few things at every minor 
> release ?

Usually, incompatible changes are discussed to balance if it's worth it or not.

There is no plan to break all user code just for your pleasure.

For the specific case of argv[0], the discussion occurred here on associated 
pull requests, and nobody mentioned any risk of backward compatibility.

FYI I'm working on this topic and I just proposed a the PEP 606 "Python 
Compatibility Version" to propose one possible solution to make incompatible 
changes less painful to users.


> It's fair to expect, as a user, that any 3.x will be aiming to be forward 
> compatible. This was the case for Python 2.X and was part of the popularity 
> of the language: a reliable tech.

My PEP 606 tries to explain incompatible changes are needed:
https://www.python.org/dev/peps/pep-0606/#the-need-to-evolve-frequently


> Not to mention that after a decade of healing from the P2/3 transition, the 
> community needs a rest.

I understand that but such comment doesn't help the discussion. See my previous 
comments and please try to help to fill the missing information to help us to 
take better decisions.

Since Python 3.8.0 has been release, a revert can make things even worse that 
the current state.

--

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

I understand that the discussion is about my commit 
3939c321c90283b49eddde762656e4b1940e7150 which changed multiple things:
---
  Python now gets the absolute path of the script filename specified on
  the command line (ex: ``python3 script.py``): the ``__file__`` attribute of
  the ``__main__`` module, ``sys.argv[0]`` and ``sys.path[0]`` become an
  absolute path, rather than a relative path.
---

I understand that the complain is not about sys.modules['__main__'].__file__ 
nor sys.path[0], but only sys.argv[0].

The sys.argv documentation says:

"The list of command line arguments passed to a Python script. argv[0] is the 
script name (it is operating system dependent whether this is a full pathname 
or not)."

https://docs.python.org/dev/library/sys.html#sys.argv

I understand that before my change, sys.argv[0] was sometimes relative, and 
sometimes absolute. With my change, sys.argv[0] should now always be asolute.

There are cases where an absolute path is preferred. There are cases where a 
relative path is preferred. I'm trying to understand the scope of the issue.

> https://github.com/google/python-gflags/blob/4f06c3d0d6cbe9b1fb90ee9fb1c082b3bf9285f6/gflags/flagvalues.py#L868-L869

I don't know this code. It seems like sys.argv[0] is used to lookup in a dict, 
and that dict keys are supposed to be "module names". I don't understand in 
which cases sys.argv[0] could be a module *name*, since sys.argv[0] seems like 
a relative or absolute path.

> https://github.com/HcashOrg/hcOmniEngine/blob/f1acc2ba3640a8e1c651ddc90a86d569d00704fe/msc-cli.py#L12

The code starts by sys.argv.pop(0): remove sys.argv[0].

> https://github.com/vmtk/vmtk/blob/64675f598e31bc6be3d4fba903fb59bf1394f492/PypeS/pyperun.py#L35

if sys.argv[0].startswith('pyperun'): ...

I understand that my change broke such test. Did this test work before my 
change when specifying the absolute path to run the script? Like 
path/to/pyperun.py rather than pyperun.py? Such code looks fragile: using 
os.path.basename() would be safer here.

> https://github.com/apache/lucene-solr/blob/cfa49401671b5f9958d46c04120df8c7e3f358be/dev-tools/scripts/svnBranchToGit.py#L783

  home = os.path.expanduser("~")
  svnWorkingCopiesPath = os.path.join(home, "svnwork")
  gitReposPath = os.path.join(home, "gitrepos")
  if sys.argv[0].startswith(svnWorkingCopiesPath) 
 or sys.argv[0].startswith(gitReposPath): ...

On my Linux, os.path.expanduser("~") is an absolute path and so 
svnWorkingCopiesPath and gitReposPath should be absolute paths, no?

My change made this code more reliable, rather than breaking it, no?

--

___
Python tracker 

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

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

[STINNER Victor]

STINNER Victor  added the comment:

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

Even before this cases, there were different cases where Python does modify 
sys.argv:

* "python3 -c code ..." command: Python removes code from sys.argv
* runpy.run_module() and runpy.run_path() replace sys.argv[0] with a filename

At the C level, the Py_GetArgcArgv() function provides the "original" argc and 
argv: before they are modified.

See open issues:

* bpo-14208 (closed): No way to recover original argv with python -m
* bpo-29857: Provide `sys.executable_argv` for host application's command line 
arguments
* bpo-26388: Disabling changing sys.argv[0] with 
runpy.run_module(...alter_sys=True)

--

___
Python tracker 

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

[issue38540] Possible leaks in PyArg_Parse for "es#" and "et#"

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue38537] 2.7 on Windows: all-users installation does not clear previous just-for-me installation

[Zachary Ware]

Change by Zachary Ware :


--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed
title: Python 2.7.17 reports itself as 2.7.16 -> 2.7 on Windows: all-users 
installation does not clear previous just-for-me installation

___
Python tracker 

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

[issue38550] hashlib missing algorithms

[Mike Gilbert]

Mike Gilbert  added the comment:

Ok, so this appears to be working correctly on master. Just the 3.7 branch is 
broken.

I think this is because we use OBJ_NAME_do_all instead of EVP_MD_do_all in 3.7.

I think backporting https://github.com/python/cpython/pull/16083 to 3.7 would 
resolve this.

--

___
Python tracker 

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

[issue38537] Python 2.7.17 reports itself as 2.7.16

[PEW's Corner]

PEW's Corner  added the comment:

Yes, the dll now seems to have ended up in c:\windows\syswow64. I have no idea 
whether I chose "just for me" or "all users" last time (this is a general 
irritant when having to manually update software on Windows), but I did choose 
"all users" this time, so your hypothesis is probably correct.

Considering that the user has no easy way to make the correct choice, nor to 
anticipate the consequences of a wrong choice, the term "user error" doesn't 
feel right. :-) But I completely understand why you wouldn't want to put much 
effort into fixing something that is almost dead, and at least *I* now know how 
to fix the problem when it happens again.

--

___
Python tracker 

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

[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)

[Eryk Sun]

Eryk Sun  added the comment:

> At least one package in 3.8 still contained a dependency on the C++ 
> runtime

FWIW, the very first thing that I checked was the dependencies of pythonw.exe, 
in case maybe I had a dependent DLL that's not distributed with Windows. 
There's nothing out of the ordinary:

C:\Program Files\Python37>sigcheck -nobanner pythonw.exe
C:\Program Files\Python37\pythonw.exe:
Verified:   Signed
Signing date:   7:12 PM 10/14/2019
Publisher:  Python Software Foundation
Company:Python Software Foundation
Description:Python
Product:Python
Prod version:   3.7.5
File version:   3.7.5
MachineType:64-bit

C:\Program Files\Python37>dumpbin /nologo /dependents pythonw.exe

Dump of file pythonw.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

python37.dll
VCRUNTIME140.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
KERNEL32.dll

  Summary

1000 .data
1000 .pdata
1000 .rdata
1000 .reloc
   14000 .rsrc
2000 .text

--

___
Python tracker 

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

[issue37930] make fails when compiling Python 2.6 from source (posixmodule.c)

[Gilles Bardoux]

Gilles Bardoux  added the comment:

Hi Oguz,
You just need to change one line in Include/objimpl.h: replace "long double 
dummy" by "double dummy". Enjoy!

--- a/Include/objimpl.h
+++ b/Include/objimpl.h
@@ -248,7 +248,7 @@ typedef union _gc_head {
 union _gc_head *gc_prev;
 Py_ssize_t gc_refs;
 } gc;
-long double dummy;  /* force worst-case alignment */
+double dummy;  /* force worst-case alignment */
 } PyGC_Head;
 
 extern PyGC_Head *_PyGC_generation0;

--
nosy: +gilles.bardoux

___
Python tracker 

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

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

[Yury Selivanov]

Change by Yury Selivanov :


--
nosy:  -yselivanov

___
Python tracker 

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

[issue38540] Possible leaks in PyArg_Parse for "es#" and "et#"

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 928c68eee620cc6b624a195375143c2aa55644a4 by Serhiy Storchaka in 
branch '3.7':
bpo-38540: Revert a warning if PY_SSIZE_T_CLEAN is not defined. (GH-16876)
https://github.com/python/cpython/commit/928c68eee620cc6b624a195375143c2aa55644a4


--

___
Python tracker 

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

[issue38540] Possible leaks in PyArg_Parse for "es#" and "et#"

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset ccdfeb7e969bf3aafd43dbe6581c30f66f2b0890 by Serhiy Storchaka in 
branch '2.7':
[2.7] bpo-38540: Fix possible leak in PyArg_Parse for "es#" and "et#". 
(GH-16869). (GH-16877)
https://github.com/python/cpython/commit/ccdfeb7e969bf3aafd43dbe6581c30f66f2b0890


--

___
Python tracker 

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

[issue38552] Colored Prompt broken in REPL in Windows in 3.8

[William Minchin]

New submission from William Minchin :

I have a Python startup file that colorizes my prompt. This worked on Python 
3.7, but breaks on Python 3.8. I'm on Windows using Powershell 6.2.3, but `cmd` 
does the same.

Maybe related, but the colorization also failed on Python 3.7 if a virtual 
environment was active.

I am using `colorama` to provide the ANSI color codes.

The startup files:

```
import sys
import colorama

colorama.init()

_GREEN = colorama.Fore.GREEN
_YELLOW = colorama.Fore.YELLOW
_RESET = colorama.Style.RESET_ALL

print("setting prompt, {}, {}, {}.".format(_GREEN, _YELLOW, _RESET))
sys.ps1 = "{}>>> {}".format(_GREEN, _RESET)
sys.ps2 = "{}... {}".format(_YELLOW, _RESET)
print()
```

--
components: Windows
files: python_colored_prompt.png
messages: 355097
nosy: MinchinWeb, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Colored Prompt broken in REPL in Windows in 3.8
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48673/python_colored_prompt.png

___
Python tracker 

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

[issue31202] Windows pathlib.Path.glob(pattern) fixed part of the pattern changed to lowercase whereas it should be unchanged.

[miss-islington]

miss-islington  added the comment:


New changeset 2f8d4f08e2fa62cd5c3f6f824be3e7513ff87e07 by Miss Skeleton (bot) 
in branch '3.8':
bpo-31202: Preserve case of literal parts in Path.glob() on Windows. (GH-16860)
https://github.com/python/cpython/commit/2f8d4f08e2fa62cd5c3f6f824be3e7513ff87e07


--

___
Python tracker 

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

[issue38551] lib2to3 Grammar.txt doesn't have Python 3.8 grammar changes

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

See also https://bugs.python.org/issue36541 which has an open PR to support the 
walrus operator.

--
nosy: +xtreak

___
Python tracker 

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

[issue38539] Update demo files

[Julin]

Julin  added the comment:

Okay. While I'm at it, can I make a few minor change as well? Like

 - Use fstrings
 - change range(0, val) to range(val) as range()'s first argument has default 
value 0.
 - Change `for i in range(len(groups)):` to enumerated (redemo.py)
 - rename ss1.py to spreadsheet.py (to make its purpose clearer)

--

___
Python tracker 

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

[issue31202] Windows pathlib.Path.glob(pattern) fixed part of the pattern changed to lowercase whereas it should be unchanged.

[miss-islington]

miss-islington  added the comment:


New changeset 175abccbbfccb2f6489dc5c73f4630c1b25ce504 by Miss Skeleton (bot) 
in branch '3.7':
bpo-31202: Preserve case of literal parts in Path.glob() on Windows. (GH-16860)
https://github.com/python/cpython/commit/175abccbbfccb2f6489dc5c73f4630c1b25ce504


--
nosy: +miss-islington

___
Python tracker 

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

[issue38551] lib2to3 Grammar.txt doesn't have Python 3.8 grammar changes

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +pablogsal

___
Python tracker 

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

[issue38550] hashlib missing algorithms

[Mike Gilbert]

Mike Gilbert  added the comment:

I see that generate_hash_name_list() calls EVP_MD_do_all() which calls  
OPENSSL_init_crypto(OPENSSL_INIT_ADD_ALL_DIGESTS, NULL);

I'm not sure why that doesn't do the job here.

--

___
Python tracker 

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

[issue38551] lib2to3 Grammar.txt doesn't have Python 3.8 grammar changes

[Peter Ludemann]

New submission from Peter Ludemann :

As far as I can tell, the lib2to3/Grammar.txt file in the Python 3.8 release is 
the same as that of the Python 3.7 release, which means it doesn't have the 
"walrus" operator and the "/" parameter syntax.

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 355092
nosy: Peter Ludemann
priority: normal
severity: normal
status: open
title: lib2to3 Grammar.txt doesn't have Python 3.8 grammar changes
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue38540] Possible leaks in PyArg_Parse for "es#" and "et#"

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +16422
pull_request: https://github.com/python/cpython/pull/16877

___
Python tracker 

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

[issue38540] Possible leaks in PyArg_Parse for "es#" and "et#"

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +16421
pull_request: https://github.com/python/cpython/pull/16876

___
Python tracker 

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

[issue31202] Windows pathlib.Path.glob(pattern) fixed part of the pattern changed to lowercase whereas it should be unchanged.

[miss-islington]

Change by miss-islington :


--
pull_requests: +16420
pull_request: https://github.com/python/cpython/pull/16875

___
Python tracker 

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

[issue38550] hashlib missing algorithms

[Mike Gilbert]

Mike Gilbert  added the comment:

Then the OpenSSL documentation is wrong, or Python is subsequently doing 
something to disable some algorithms.

--

___
Python tracker 

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

[issue38550] hashlib missing algorithms

[Christian Heimes]

Christian Heimes  added the comment:

According to OpenSSL documentation it is not necessary to call any init 
function. All ciphers and all digests are default options.

As of version 1.1.0 OpenSSL will automatically allocate all resources that it 
needs so no explicit initialisation is required. Similarly it will also 
automatically deinitialise as required.

OPENSSL_INIT_ADD_ALL_CIPHERS
With this option the library will automatically load and make available all 
libcrypto ciphers. This option is a default option.

OPENSSL_INIT_ADD_ALL_DIGESTS
With this option the library will automatically load and make available all 
libcrypto digests. This option is a default option.

https://www.openssl.org/docs/man1.1.0/man3/OPENSSL_init_crypto.html

--
nosy: +christian.heimes, gregory.p.smith

___
Python tracker 

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

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

[Ammar Askar]

Ammar Askar  added the comment:

I did a quick search to see what code would break from sys.argv[0] going 
relative

  intext:"sys.argv[0]" ext:py site:github.com
  
https://www.google.com/search?q=intext:"sys.argv%5B0%5D"+ext:py+site:github.com

and while most uses of it are to print usage messages. There is potentially 
code relying on it being a relative path that will break from this change:

* 
https://github.com/google/python-gflags/blob/4f06c3d0d6cbe9b1fb90ee9fb1c082b3bf9285f6/gflags/flagvalues.py#L868-L869
* 
https://github.com/HcashOrg/hcOmniEngine/blob/f1acc2ba3640a8e1c651ddc90a86d569d00704fe/msc-cli.py#L12
* 
https://github.com/vmtk/vmtk/blob/64675f598e31bc6be3d4fba903fb59bf1394f492/PypeS/pyperun.py#L35
* 
https://github.com/apache/lucene-solr/blob/cfa49401671b5f9958d46c04120df8c7e3f358be/dev-tools/scripts/svnBranchToGit.py#L783

I think Michel and Nick are correct here and the status-quo should be 
maintained for sys.argv[0]. Michel should not have to enumerate the use cases 
for a relative sys.argv[0].

--
nosy: +ammar2

___
Python tracker 

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

[issue31202] Windows pathlib.Path.glob(pattern) fixed part of the pattern changed to lowercase whereas it should be unchanged.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 10ecbadb799ddf3393d1fc80119a3db14724d381 by Serhiy Storchaka in 
branch 'master':
bpo-31202: Preserve case of literal parts in Path.glob() on Windows. (GH-16860)
https://github.com/python/cpython/commit/10ecbadb799ddf3393d1fc80119a3db14724d381


--

___
Python tracker 

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

[issue31202] Windows pathlib.Path.glob(pattern) fixed part of the pattern changed to lowercase whereas it should be unchanged.

[miss-islington]

Change by miss-islington :


--
pull_requests: +16419
pull_request: https://github.com/python/cpython/pull/16874

___
Python tracker 

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

[issue38486] Dead links in mailbox doc

[Mariatta]

Mariatta  added the comment:

Seems like we meant to reference to the maildir specification, which used to be 
hosted in qmail.com

Since qmail is gone, how about we refer to maildir info here? 
https://wiki2.dovecot.org/MailboxFormat/Maildir

--
nosy: +Mariatta

___
Python tracker 

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

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

[Michel Desmoulin]

Michel Desmoulin  added the comment:

The relevance of the use case isn't the problem. Even if people had been using 
it wrong for all this time, the update is still going to break their code if 
they did use it this way. And if it was possible, of course many people did.

3.7 already broke a few packages by choosing to not do the True/False dance 
again and make async/await keywords. I took a lot of people by surprise, not 
because of the issue itself, but because of the change of philosophy compared 
of what Python had been in the past.

Do we really want to make a habit of breaking a few things at every minor 
release ?

It's fair to expect, as a user, that any 3.x will be aiming to be forward 
compatible. This was the case for Python 2.X and was part of the popularity of 
the language: a reliable tech.

I'm advocating that any breaking change,, even the tiniest, should be behind a 
__future__ import or a flag, with warnings, and then switched on for good on 
Python 4.0.

Python is a language, not a simple library. Stability is key. Like Linus 
Torvald use to say: "do not break user space"

The fact this change is easy to fix and migrate is not a proper reason to 
ignore this important software rule, IMO. So many people and so much code rely 
on Python that the tinest glitch may have massive impact down the line.

Not to mention that after a decade of healing from the P2/3 transition, the 
community needs a rest.

Le 21/10/2019 à 13:26, STINNER Victor a écrit :
>
> STINNER Victor  added the comment:
>
> What is the use case for having a relative sys.argv[0]?
>
> > Isn't that change breaking compat ?
>
> Right. It has been made on purpose. The rationale can be found in the first 
> message of this issue.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)

[Jon]

Jon  added the comment:

When I have some time.  Maybe this weekend.  3.7.4 is working ok right now for 
production level.  So I didn't bother with anything else yet.

Might help someone else in the meantime though.  Glad to see that someone is 
taking the complaint seriously :)

--

___
Python tracker 

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

[issue38537] Python 2.7.17 reports itself as 2.7.16

[Steve Dower]

Steve Dower  added the comment:

Exactly where were the DLLs installed?

If you had previously done "just for me" and then this time did "all users", 
the python27.dll for 2.7.17 will be in C:\Windows\SysWow64, which has lower 
priority than the one in the same directory.

I won't be fixing or even reviewing any issues in the 2.7 installer at this 
point. If someone else identifies an easy fix, they're welcome to merge it, but 
if the problem was changing the mode of install then I'd rather leave this as 
user error (and be thankful that we've reduced the likelihood of that error 
since 3.5).

--

___
Python tracker 

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

[issue38534] Version 3.8.0 has released with a wrong MS KB number reference

[Steve Dower]

Change by Steve Dower :


--
keywords: +easy, newcomer friendly

___
Python tracker 

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

[issue38534] Version 3.8.0 has released with a wrong MS KB number reference

[Steve Dower]

Steve Dower  added the comment:

> in what's new and the installer, you've referenced KB2533625 instead of 
> KB2533623. Do we have to open a new issue for this minor search and replace 
> fix?

The new issue is opened now, so we can attach a PR to this one.

Contributions welcome - this isn't difficult.

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

[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)

[Steve Dower]

Steve Dower  added the comment:

Can you try installing https://aka.ms/vs/16/release/VC_redist.x64.exe and then 
see if it makes a difference?

At least one package in 3.8 still contained a dependency on the C++ runtime, 
which we do not include, and it's possible that 3.7.5 had the same issue. Both 
will be fixed in the next updates, but the workaround is to install the file 
above.

--

___
Python tracker 

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

[issue38550] hashlib missing algorithms

[Mike Gilbert]

Change by Mike Gilbert :


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

___
Python tracker 

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

[issue38550] hashlib missing algorithms

[Mike Gilbert]

New submission from Mike Gilbert :

After upgrading to Python 3.7.5, several algorithms are unavailable in the 
hashlib module.

This seems to have been caused by the "fix" for 
https://bugs.python.org/issue33936. I will submit a PR with a more appropriate 
change shortly.

Python 3.7.4:
>>> hashlib.algorithms_available
{'ripemd160', 'blake2s256', 'sha512', 'sha3-224', 'sha3_224', 'blake2s', 
'shake_128', 'sha3-384', 'sha3_384', 'whirlpool', 'md4', 'md5', 'sha512-224', 
'sha3-512', 'sha1', 'blake2b', 'sha384', 'md5-sha1', 'sha3-256', 'shake_256', 
'mdc2', 'sha224', 'blake2b512', 'shake128', 'sm3', 'sha256', 'shake256', 
'sha3_512', 'sha512-256', 'sha3_256'}

Python 3.7.5:
>>> hashlib.algorithms_available
{'sha224', 'sha256', 'sha3_224', 'blake2s', 'md5', 'sha3_256', 'sha384', 
'sha3_512', 'sha3_384', 'shake_256', 'blake2b', 'sha512', 'shake_128', 'sha1'}

--
components: Extension Modules
messages: 355080
nosy: floppymaster
priority: normal
severity: normal
status: open
title: hashlib missing algorithms
type: behavior
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

[issue38546] test_concurrent_futures: test_interpreter_shutdown() warning "reap_children() reaped child process" on AMD64 RHEL7 3.x

[STINNER Victor]

STINNER Victor  added the comment:

I ran "./python -m test --fail-env-changed -w -j50 -F test_concurrent_futures" 
on my laptop for 5 minutes: system load of 220,57 with a peak of 403 
processes... but I failed to reproduce the issue :-(

--

___
Python tracker 

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

[issue38542] [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h

[egaudry]

egaudry  added the comment:

I originally submitted an issue asking for having the symbol exported.

But, as Victor mentioned, this part of the code was changed between 2.7 and 3.x.

I then asked if the part of the code defining the symbol (and not used anymore) 
in 3.7 could be removed/cleaned. This is why it was tagged back to 3.7.

As it was already removed in newer version (3.8?) and because the policy is not 
to clean dead-code, this issue is now closed.

--

___
Python tracker 

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

[issue38542] [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h

[Guido van Rossum]

Guido van Rossum  added the comment:

If it's specific to 2.7, why does the Version metadata say 3.7?

--
nosy: +gvanrossum

___
Python tracker 

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

[issue38549] Compiler build paths and related environment variables are ignored for native builds

[STINNER Victor]

STINNER Victor  added the comment:

> However in native builds (not cross-compiling) these variables/directories 
> are ignored which leads to failure of e.g. building the BZip2 extension 
> (among others).

Python does not explicitly ignore these environment variable, so I'm not sure 
how setup.py prevent that.

For example, the _bz2 module is built by setup.py by default in the master 
branch of Python.

--

___
Python tracker 

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

[issue38549] Compiler build paths and related environment variables are ignored for native builds

[STINNER Victor]

STINNER Victor  added the comment:

> This did work ages ago, but was broken when it was decided that compiler 
> paths (output of `gcc -E -v`) is no longer used for native builds and that 
> function was later even renamed: 
> https://github.com/python/cpython/commit/32f5fdd7f4213743fe2f6eedd0fe2108f3157021#diff-2eeaed663bd0d25b7e608891384b7298R514

Can you please elaborate?

setup.py of Python 2.7:

if cross_compiling:
self.add_gcc_paths()

setup.py of Python 3.5:

# only change this for cross builds for 3.3, issues on Mageia
if cross_compiling:
self.add_gcc_paths()

In the 2.7, this code was changed in 2013 to fix bpo-17990:

"For Issue17086, 8ee6d96a1019 backported some cross-build patches to the 2.7 
branch.  The changes to setup.py detect_modules differ in the backport from 
those in default. In particular, in default, changes to the library and include 
directory lists used to build extensions modules are only made conditionally 
when cross-compiling.  But the 2.7 backport makes these changes 
unconditionally."

commit 6166709eec557f52075417b19676dccc9f405fda
Author: Ned Deily 
Date:   Wed May 15 18:00:45 2013 -0700

Issue #17990: Only modify include and library search paths when 
cross-compiling.

--
nosy: +vstinner

___
Python tracker 

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

[issue38472] GCC detection in setup.py is broken

[STINNER Victor]

STINNER Victor  added the comment:

What are you trying to do? Compile Python? Cross-compile Python?

> `setup.py` runs ` -E -v - /dev/null` to figure out include 
> and library paths from the compiler in the function `add_gcc_paths`.

Are you talking about the add_cross_compiling_paths() function which is only 
called when _PYTHON_HOST_PLATFORM environment variable is set?

So GCC says "gcc-Version 9.1.0 (GCC) " with your locale, but does it write "gcc 
version 9.1.0 ..." with LC_ALL=C?

--
nosy: +vstinner

___
Python tracker 

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

[issue38549] Compiler build paths and related environment variables are ignored for native builds

[Alex Grund]

New submission from Alex Grund :

In e.g. Linux users can set CPATH and LIBRARY_PATH to a list of paths 
considered by e.g. GCC, Clang, ... as if they were passed to `-I`, `-L`

These paths show up in the verbose compiler output too.

However in native builds (not cross-compiling) these variables/directories are 
ignored which leads to failure of e.g. building the BZip2 extension (among 
others).

Use case: On HPC modules are used, which means e.g. BZip2 is not installed into 
a system directory but into some other folder and CPATH, LIBRARY_PATH, 
LD_LIBRARY_PATH, ... are modified so it can be found by compiler and runtime. 
However the Python build script does not find it as it ignores those "compiler 
paths".

This did work ages ago, but was broken when it was decided that compiler paths 
(output of `gcc -E -v`) is no longer used for native builds and that function 
was later even renamed: 
https://github.com/python/cpython/commit/32f5fdd7f4213743fe2f6eedd0fe2108f3157021#diff-2eeaed663bd0d25b7e608891384b7298R514

I propose to rename the function back to its original name and use it always.

--
components: Build
messages: 355073
nosy: Alex Grund
priority: normal
severity: normal
status: open
title: Compiler build paths and related environment variables are ignored for 
native builds
type: compile error
versions: Python 2.7, 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

[issue38472] GCC detection in setup.py is broken

[Alex Grund]

Alex Grund  added the comment:

This seems to be a locale issue. So a solution would be to use `LC_ALL=C` 
before invoking the compiler (or the cross-platform equivalent)

--

___
Python tracker 

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

[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +eric.snow

___
Python tracker 

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

[issue38466] [Easy doc] threading.excepthook doc talks about "object"

[STINNER Victor]

STINNER Victor  added the comment:

> https://docs.python.org/3.8/library/threading.html#threading.excepthook

"Storing *object* using a custom hook can resurrect it"
should be
"Storing *thread* using a custom hook can resurrect it"
in Doc/library/threading.rst

--

___
Python tracker 

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

[issue38543] [2.7] Expose Py_TabcheckFlag as other PyAPI_DATA flag

[STINNER Victor]

STINNER Victor  added the comment:

Python 2.7 doesn't accept new features anymore. The issue has been closed.

--
resolution:  -> wont fix

___
Python tracker 

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

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

[Jeremy Kloth]

Jeremy Kloth  added the comment:

That covers the logging in _force_run(), but the warning.warn() line is also 
not output, suggesting that the RuntimeWarning is being suppressed somewhere.

--

___
Python tracker 

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

[issue38542] [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h

[STINNER Victor]

STINNER Victor  added the comment:

The master branch of Python doesn't contain _PyGC_generation0 anymore.

> Yes, the only thing that remains to be done is cleaning objimpl.h.

We don't do cleanup changes in stable branches. Only in the development branch: 
master. In this case, it's already fixed. So I close the issue.

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

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

[STINNER Victor]

STINNER Victor  added the comment:

> ... is not showing up when the test is re-run in verbose mode.

_force_run() logs require verbose >= 2. The test suite is run using:

'Tools\\buildbot\\test.bat' '-x64' '-j2' '-j4' '--timeout' '900'

which runs:

C:\buildbot.python.org\3.x.kloth-win64\build>"C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\amd64\python_d.exe"
  -u -Wd -E -bb -m test  -uall -rwW --slowest --timeout 1200 --fail-env-changed 
-j1 -j2 -j4 --timeout 900 

Using this command, I get: support.verbose=1 in the main regrtest process and 
in regrtest worker processes.

Maybe _force_run() should always log, or log "if verbose:" (remove ">= 2" 
restriction).

--

___
Python tracker 

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

[issue38510] build python with --enable-shared with static linked python against libpython*.a

[Charalampos Stratakis]

Change by Charalampos Stratakis :


--
nosy: +cstratak

___
Python tracker 

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

[issue38542] [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h

[egaudry]

egaudry  added the comment:

Yes, the only thing that remains to be done is cleaning objimpl.h.

--
title: [2.7] Expose _PyGC_generation0 for allowing internal use directly from a 
CPython extension -> [3.7] clean extern PyGC_Head *_PyGC_generation0; in 
Include/objimpl.h
versions: +Python 3.7 -Python 2.7

___
Python tracker 

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

[issue38542] [2.7] Expose _PyGC_generation0 for allowing internal use directly from a CPython extension

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I think it is too late to add this feature in 2.7. See 
https://www.python.org/dev/peps/pep-0373/#release-schedule, the feature freeze 
was 9.5 years ago.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

[STINNER Victor]

STINNER Victor  added the comment:

I marked bpo-38548 as duplicate of this issue. Copy of msg355062:

Consider the following program:

f = open("out.txt", "w")
f.write("abc\n")
exit(0)

Please note the absence of f.close().
The documentation 
https://docs.python.org/3/tutorial/inputoutput.html#reading-and-writing-files
says that you should use f.close() or with f = open(), but is not clear whether 
the program above without f.close() is guaranteed to write. The tutorial says:
"If you don’t explicitly close a file, Python’s garbage collector will 
eventually destroy the object and close the open file for you, but the file may 
stay open for a while. Another risk is that different Python implementations 
will do this clean-up at different times."
For me this sounds like even without f.close() the file is guaranteed to be 
written. If it is not guaranteed to be written, you should fix the 
documentation, if it is guaranteed to be written, then I will open another 
issue because the following program does not write into out.txt on my machine:

from sympy.core import AtomicExpr
class MyWeirdClass(AtomicExpr):
def __init__(self):
pass
f = open("out.txt", "w")
f.write("abc\n")
exit(0)

Note: sys.version is: "3.7.3 (default, Oct  7 2019, 12:56:13) \n[GCC 8.3.0]"

--

___
Python tracker 

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

[issue38548] open() and file.write() without file.close()

[STINNER Victor]

STINNER Victor  added the comment:

The issue is a duplicate of bpo-17852.

--
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Built-in module _io can lose data from buffered files in 
reference cycles

___
Python tracker 

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

[issue38548] open() and file.write() without file.close()

[kryptomatrix]

New submission from kryptomatrix :

Consider the following program:

f = open("out.txt", "w")
f.write("abc\n")
exit(0)

Please note the absence of f.close().
The documentation 
https://docs.python.org/3/tutorial/inputoutput.html#reading-and-writing-files
says that you should use f.close() or with f = open(), but is not clear whether 
the program above without f.close() is guaranteed to write. The tutorial says:
"If you don’t explicitly close a file, Python’s garbage collector will 
eventually destroy the object and close the open file for you, but the file may 
stay open for a while. Another risk is that different Python implementations 
will do this clean-up at different times."
For me this sounds like even without f.close() the file is guaranteed to be 
written. If it is not guaranteed to be written, you should fix the 
documentation, if it is guaranteed to be written, then I will open another 
issue because the following program does not write into out.txt on my machine:

from sympy.core import AtomicExpr
class MyWeirdClass(AtomicExpr):
def __init__(self):
pass
f = open("out.txt", "w")
f.write("abc\n")
exit(0)

Note: sys.version is: "3.7.3 (default, Oct  7 2019, 12:56:13) \n[GCC 8.3.0]"

--
assignee: docs@python
components: Documentation
messages: 355062
nosy: docs@python, kryptomatrix
priority: normal
severity: normal
status: open
title: open() and file.write() without file.close()
type: enhancement
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

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

[Jeremy Kloth]

Jeremy Kloth  added the comment:

While not getting into the error itself, there seems to be another issue in 
that the logging that should be happening when the deletion routines from 
test.support fail:

https://github.com/python/cpython/blob/5bc6a7c06eda20ba131ecba6752be0506d310181/Lib/test/support/__init__.py#L339
https://github.com/python/cpython/blob/5bc6a7c06eda20ba131ecba6752be0506d310181/Lib/test/support/__init__.py#L375

is not showing up when the test is re-run in verbose mode.

--

___
Python tracker 

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

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

[Jeremy Kloth]

Change by Jeremy Kloth :


--
nosy: +jkloth

___
Python tracker 

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

[issue36732] Windows: test_asyncio: test_huge_content_recvinto() fails randomly with ProactorEventLoop

[Jeremy Kloth]

Change by Jeremy Kloth :


--
nosy: +jkloth

___
Python tracker 

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

[issue38502] regrtest: use process groups

[STINNER Victor]

STINNER Victor  added the comment:

> I don't know for sure that this is the cause but both 3.x builds following 
> this commit on my bolen-ubuntu worker (Ubuntu 18.04.3) have had test_pty 
> crash in the first attempt, with the retry succeeding.  For example 
> https://buildbot.python.org/all/#/builders/141/builds/2679

I created bpo-38547: "test_pty fails when using setsid()".

--

___
Python tracker 

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

[issue38547] test_pty fails when using setsid()

[STINNER Victor]

New submission from STINNER Victor :

regrtest has been modified in bpo-38502 to use setsid() when using 
multiprocessing mode (-jN command line option).

Problem: David Bolen identified that test_pty started to fail on his 
bolen-ubuntu worker (Ubuntu 18.04.3) since my commit 
ecb035cd14c11521276343397151929a94018a22.

https://buildbot.python.org/all/#/builders/141/builds/2679

0:19:05 load avg: 1.81 [234/419/1] test_pty crashed (Exit code -1) -- running: 
test_unicodedata (55.5 sec)

I can reproduce the issue locally:

---
$ ./python -m test -j2 test_pty -v
== CPython 3.9.0a0 (heads/urlparse_ipv6:cc733a8cb6, Oct 21 2019, 11:34:36) [GCC 
9.2.1 20190827 (Red Hat 9.2.1-1)]
== Linux-5.2.18-200.fc30.x86_64-x86_64-with-glibc2.29 little-endian
== cwd: /home/vstinner/python/master/build/test_python_20242
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 0.70 Run tests in parallel using 2 child processes
0:00:00 load avg: 0.70 [1/1/1] test_pty crashed (Exit code -1)
test_basic (test.test_pty.PtyTest) ...

== Tests result: FAILURE ==

1 test failed:
test_pty

Total duration: 383 ms
Tests result: FAILURE
---

It's surprising that there is no output!

I would prefer to keep process groups in regrtest, it's really helpful to be 
able to kill all processes spawned by a test worker process.

I'm not sure how/why PTY depends is incompatible with setsid().

--
components: Tests
messages: 355059
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_pty fails when using setsid()
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

[issue38542] [2.7] Expose _PyGC_generation0 for allowing internal use directly from a CPython extension

[egaudry]

egaudry  added the comment:

Victor,

extern PyGC_Head *_PyGC_generation0; 
is located at line 374 of Include/objimpl.h (ifndef Py_LIMITED_API).

I used it from a CPython extension we are developing as an handle to the 
collection of objects being garbage collected.

>From what you explained, I should use the _PyRuntime exported symbol to get 
>the handle this PyGC_Head. I'll do this.

I guess that cleaning the Include/objimpl.h is the only remaining action to do 
then.

Thanks for your feedback.

--

___
Python tracker 

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

[issue36752] test multiprocessing: test_rapid_restart() crash on AIX when using XLC compiler

[STINNER Victor]

STINNER Victor  added the comment:

According to Michael Felt, the bug is specific to XLC compiler, but the POWER6 
AIX buildbot worker switch to GCC.

Michael Felt: Maybe Python documentation or build system should somewhere 
discourage the usage of the XLC on AIX because of this bug. But that's a 
different issue.

Since it seems like nobody is available to debug the XLC specific issue and 
that the buildbot worker worked around the issue, I close the issue.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
title: test multiprocessing: test_rapid_restart() crash on AIX -> test 
multiprocessing: test_rapid_restart() crash on AIX when using XLC compiler

___
Python tracker 

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

[issue38545] Implement setter and deleter on functools.cached_property

[Laurie Opperman]

Laurie Opperman  added the comment:

Turns out, that as a non-data descriptor, a cached property already has 
setting/updating and clearing through the normal mechanisms in Python. This 
feature request is therefore redundant: perhaps a new issue to document this 
inherent behaviour?

Unless you explicitly want to make cached property updating not allowed, but 
that's easily implemented in application code by sub-classing 
`functools.cached_property` and defining `__set__` and `__delete__` to raise:

class unupdatable_cached_property(functools.cached_property):
def __set__(self, instance, value):
raise AttributeError("can't set attribute")

def __delete__(self, instance):
raise AttributeError("can't delete attribute")

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

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

[STINNER Victor]

STINNER Victor  added the comment:

What is the use case for having a relative sys.argv[0]?

> Isn't that change breaking compat ?

Right. It has been made on purpose. The rationale can be found in the first 
message of this issue.

--

___
Python tracker 

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

[issue38543] [2.7] Expose Py_TabcheckFlag as other PyAPI_DATA flag

[STINNER Victor]

STINNER Victor  added the comment:

Right, Python 2.7 support is ending at the end of the year. Python 2.7 got 18 
releases without Py_TabcheckFlag, you're the first to request it.

You should consider to upgrade to Python 3 and have a look at my PEP 587 
"Python Initialization Configuration" ;-)

--

___
Python tracker 

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

[issue38546] test_concurrent_futures: test_interpreter_shutdown() warning "reap_children() reaped child process" on AMD64 RHEL7 3.x

[STINNER Victor]

STINNER Victor  added the comment:

It looks similar to bpo-38448: "test_concurrent_futures: reap_children() reaped 
child process 26487 on AMD64 RHEL8 Refleaks 3.x"

--

___
Python tracker 

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

[issue38543] [2.7] Expose Py_TabcheckFlag as other PyAPI_DATA flag

[egaudry]

egaudry  added the comment:

closing as this no real point in making something available in an EOL branch.

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

[issue38546] test_concurrent_futures: test_interpreter_shutdown() warning "reap_children() reaped child process" on AMD64 RHEL7 3.x

[STINNER Victor]

New submission from STINNER Victor :

https://buildbot.python.org/all/#/builders/254/builds/162

test_no_stale_references 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.56s ok
test_ressources_gced_in_workers 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
1.90s ok
test_shutdown_race_issue12456 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.54s ok
test_submit 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.52s ok
test_submit_keyword 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.57s ok
test_traceback 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
0.48s ok
test_context_manager_shutdown 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 
0.03s ok
test_del_shutdown 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 
0.02s ok
test_hang_issue12364 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 
1.45s ok
test_interpreter_shutdown 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 
1.62s Warning -- reap_children() reaped child process 28936
ok

--
components: Tests
messages: 355051
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_concurrent_futures: test_interpreter_shutdown() warning 
"reap_children() reaped child process" on AMD64 RHEL7 3.x
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

[issue38545] Implement setter and deleter on functools.cached_property

[Laurie Opperman]

Change by Laurie Opperman :


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

___
Python tracker 

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

[issue38543] [2.7] Expose Py_TabcheckFlag as other PyAPI_DATA flag

[STINNER Victor]

STINNER Victor  added the comment:

Py_TabcheckFlag has been removed from Python 3. This issue is specific to 
Python 2.7.

--
components: +Build
nosy: +vstinner
title: Expose Py_TabcheckFlag as other PyAPI_DATA flag -> [2.7] Expose 
Py_TabcheckFlag as other PyAPI_DATA flag
versions: +Python 2.7 -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

[issue36990] [AIX] test_asyncio.test_create_connection_ipv6_scope fails(in mock test?)

[STINNER Victor]

Change by STINNER Victor :


--
title: test_asyncio.test_create_connection_ipv6_scope fails(in mock test?) -> 
[AIX] test_asyncio.test_create_connection_ipv6_scope fails(in mock test?)

___
Python tracker 

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

[issue37516] test_asyncio logs: Unknown child process

[STINNER Victor]

Change by STINNER Victor :


--
title: buid error - test_asyncio fails during make -> test_asyncio logs: 
Unknown child process

___
Python tracker 

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

[issue37897] test_asyncio hangs on an IPv6-only host

[STINNER Victor]

STINNER Victor  added the comment:

I guess that either test_drain_raises should be skipped or modified to listen 
to ::1 (IPv6 loopback).

--
nosy: +vstinner

___
Python tracker 

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

[issue37516] buid error - test_asyncio fails during make

[STINNER Victor]

STINNER Victor  added the comment:

The issue title says "test_asyncio fails", but "Unknown child process pid 
30234, will report returncode 255" looks more like a warning. Does test_asyncio 
fail or not?

Please run test_asyncio in verbose mode to identify which test emits the 
warning.

Without further information, I suggest to just close the issue, since it 
doesn't sound like a bug, just a warning.

--
nosy: +vstinner

___
Python tracker 

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

[issue34316] test_socket and test_asyncio timeouts in AMD64 Windows10 3.x buildbots

[STINNER Victor]

STINNER Victor  added the comment:

I didn't see these failures recently, so I simply close the issue as out of 
date.

--
nosy: +vstinner
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

[issue36790] [Windows] test_asyncio fails with application verifier! _cancel_overlapped() fails with "The handle is invalid"

[STINNER Victor]

STINNER Victor  added the comment:

> when running the testsuite under Application Verifier

test_asyncio is quite big. Can you run test_asyncio in verbose mode, and attach 
the output as a file to the issue? Or try to identify a few examples of tests 
which fail with "The handle is invalid" errors"?

It seems like "The handle is invalid" errors" error occurs while calling 
_cancel_overlapped().

--
nosy: +vstinner
title: test_asyncio fails with application verifier! -> [Windows] test_asyncio 
fails with application verifier! _cancel_overlapped() fails with "The handle is 
invalid"
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue38545] Implement setter and deleter on functools.cached_property

[Laurie Opperman]

New submission from Laurie Opperman :

Support setting/updating and clearing the cached value of a cached-property 
(getter implemented by bpo-21145). Pretty straight-forward to implement

The question is whether cached-property updating should be:
a) always allowed
b) enabled with a cached-property instance attribute
c) enabled with the decorated method's class attribute
d) enabled with the decorated method's instance attribute
e) enabled in a separate decorator (eg functools.updatable_cached_property)

Note: options a, b, c, and d will make functools.cached_property a data 
descriptor.

I prefer option b or c, as the decision to make the property updatable becomes 
the property's definer's.

Also, should a warning be raised if a cached value is being overwritten? Should 
a warning be raised if no cached value is to be deleted?

--
components: Library (Lib)
messages: 355045
nosy: Epic_Wink
priority: normal
severity: normal
status: open
title: Implement setter and deleter on functools.cached_property
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue23819] test_asyncio fails when run under -O

[STINNER Victor]

STINNER Victor  added the comment:

This issue is still relevant 4 years later: many test_asyncio tests fail with 
python3 -O :-(

--

___
Python tracker 

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

[issue28562] test_asyncio fails on Android upon calling getaddrinfo()

[STINNER Victor]

STINNER Victor  added the comment:

Is the test still failing on the master branch of Python? Is the patch still 
needed?

--
nosy: +vstinner

___
Python tracker 

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

[issue30735] Python 3.6.1 test_asyncio fails on Solaris 11

[STINNER Victor]

STINNER Victor  added the comment:

Solaris is not really supported in Python:
https://pythondev.readthedocs.io/platforms.html#best-effort-and-unofficial-platforms

There is no more Solaris buildbot worker for example.

Morevoer, this issue has no activity for 2 years. I close it.

--
nosy: +vstinner
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

[issue36732] Windows: test_asyncio: test_huge_content_recvinto() fails randomly with ProactorEventLoop

[STINNER Victor]

Change by STINNER Victor :


--
title: test_asyncio: test_huge_content_recvinto() fails randomly -> Windows: 
test_asyncio: test_huge_content_recvinto() fails randomly with ProactorEventLoop
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

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

[STINNER Victor]

STINNER Victor  added the comment:

Similar error on the same build when the test was re-run in verbose mode:

0:10:55 load avg: 1.82 Re-running test_venv in verbose mode
test_deactivate_with_strict_bash_opts (test.test_venv.BasicTest) ... skipped 
'not relevant on Windows'
test_defaults (test.test_venv.BasicTest) ... ok
test_executable (test.test_venv.BasicTest) ... ok
test_executable_symlinks (test.test_venv.BasicTest) ... skipped 'Needs symlinks'
test_isolation (test.test_venv.BasicTest) ... ok
test_multiprocessing (test.test_venv.BasicTest) ... ok
test_overwrite_existing (test.test_venv.BasicTest) ... ERROR
ERROR
test_prefixes (test.test_venv.BasicTest) ... ok
test_prompt (test.test_venv.BasicTest) ... ok
test_symlinking (test.test_venv.BasicTest) ... skipped 'Needs symlinks'
test_unicode_in_batch_file (test.test_venv.BasicTest) ... ok
test_unoverwritable_fails (test.test_venv.BasicTest) ... ok
test_upgrade (test.test_venv.BasicTest) ... ok
test_upgrade_dependencies (test.test_venv.BasicTest) ... ok
test_devnull (test.test_venv.EnsurePipTest) ... ok
test_explicit_no_pip (test.test_venv.EnsurePipTest) ... ok
test_no_pip_by_default (test.test_venv.EnsurePipTest) ... ok
test_with_pip (test.test_venv.EnsurePipTest) ... ok

==
ERROR: test_overwrite_existing (test.test_venv.BasicTest)
--
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", 
line 223, in test_overwrite_existing
builder.create(self.env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", 
line 65, in create
context = self.ensure_directories(env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", 
line 108, in ensure_directories
self.clear_directory(env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", 
line 91, in clear_directory
shutil.rmtree(fn)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 730, 
in rmtree
return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 612, 
in _rmtree_unsafe
onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 610, 
in _rmtree_unsafe
os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 
'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmpvw7zok8k\\Scripts'

==
ERROR: test_overwrite_existing (test.test_venv.BasicTest)
--
Traceback (most recent call last):
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", 
line 336, in _force_run
return func(*args)
PermissionError: [WinError 5] Access is denied: 
'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmpvw7zok8k\\Scripts\\activate.bat'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", 
line 71, in tearDown
rmtree(self.env_dir)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", 
line 458, in rmtree
_rmtree(path)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", 
line 399, in _rmtree
_waitfor(_rmtree_inner, path, waitall=True)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", 
line 347, in _waitfor
func(pathname)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", 
line 395, in _rmtree_inner
_waitfor(_rmtree_inner, fullname, waitall=True)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", 
line 347, in _waitfor
func(pathname)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", 
line 398, in _rmtree_inner
_force_run(fullname, os.unlink, fullname)
  File 
"C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", 
line 341, in _force_run
os.chmod(path, stat.S_IRWXU)
PermissionError: [WinError 5] Access is denied: 
'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmpvw7zok8k\\Scripts\\activate.bat'

--

Ran 18 tests in 45.669s

FAILED (errors=2, skipped=3)

--

___
Python tracker 

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

[issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

[STINNER Victor]

New submission from STINNER Victor :

https://buildbot.python.org/all/#/builders/40/builds/3317

test_executable (test.test_venv.BasicTest) ... ok
test_executable_symlinks (test.test_venv.BasicTest) ... skipped 'Needs symlinks'
test_isolation (test.test_venv.BasicTest) ... ERROR
ERROR
test_multiprocessing (test.test_venv.BasicTest) ... ok
test_overwrite_existing (test.test_venv.BasicTest) ... ok

==
ERROR: test_isolation (test.test_venv.BasicTest)
--
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", 
line 272, in test_isolation
builder.create(self.env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", 
line 65, in create
context = self.ensure_directories(env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", 
line 108, in ensure_directories
self.clear_directory(env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", 
line 91, in clear_directory
shutil.rmtree(fn)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 730, 
in rmtree
return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 612, 
in _rmtree_unsafe
onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 610, 
in _rmtree_unsafe
os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 
'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmp2y7z3288\\Scripts'

--
components: Tests
messages: 355040
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory 
not empty: Scripts\
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

[issue35473] Intel compiler (icc) does not fully support C11 Features, including atomics

[STINNER Victor]

STINNER Victor  added the comment:

I mark this issue as a duplicate of bpo-37415.

--
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Error build Python with Intel compiler:  doesn't 
provide atomic_uintptr_t

___
Python tracker 

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

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[STINNER Victor]

STINNER Victor  added the comment:

I marked bpo-35473 as duplicate of this issue.

--

___
Python tracker 

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