[issue33182] Python 3.7.0b3 fails to build with clang 6.0

[miss-islington]

Change by miss-islington :


--
pull_requests: +6029

___
Python tracker 

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

[issue33182] Python 3.7.0b3 fails to build with clang 6.0

[Nick Coghlan]

Nick Coghlan  added the comment:


New changeset 69f5c73311a61b05485b19626935bf240ad31c5b by Nick Coghlan in 
branch 'master':
bpo-33182: Fix pointer types in _testembed (GH-6310)
https://github.com/python/cpython/commit/69f5c73311a61b05485b19626935bf240ad31c5b


--

___
Python tracker 

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

[issue33169] importlib.invalidate_caches() doesn't clear all caches

[Nick Coghlan]

Nick Coghlan  added the comment:

I agree that we can't change 3.6 at this late stage, but the change is 
borderline enough on the "new feature"/"bug fix" scale that I think it's worth 
asking Ned if he's comfortable with us changing it for 3.7.0b4.

Ned: the change we'd like to make is to update PathFinder.invalidate_caches to 
delete all entries in sys.path_importer_cache that have a value of None.

--
nosy: +ned.deily

___
Python tracker 

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

[issue33182] Python 3.7.0b3 fails to build with clang 6.0

[Nick Coghlan]

Change by Nick Coghlan :


--
pull_requests: +6028
stage:  -> patch review

___
Python tracker 

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

[issue33182] Python 3.7.0b3 fails to build with clang 6.0

[Nick Coghlan]

Nick Coghlan  added the comment:

Huh, I thought we had a clang builder in the pre-merge CI. Is that running an 
older version of clang, perhaps?

--
assignee:  -> ncoghlan

___
Python tracker 

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

[issue33184] Update OpenSSL to 1.1.0h / 1.0.2o

[Ned Deily]

New submission from Ned Deily :

https://www.openssl.org/source/

--
messages: 314675
nosy: christian.heimes, ned.deily, steve.dower, zach.ware
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Update OpenSSL to 1.1.0h / 1.0.2o
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue33074] dbm corrupts index on macOS (_dbm module)

[Ned Deily]

Change by Ned Deily :


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

___
Python tracker 

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

[issue33074] dbm corrupts index on macOS (_dbm module)

[Ned Deily]

Ned Deily  added the comment:

Addressing your point (5):

> (5) dbm.gnu is not a default, and I can't even work out how to get it enabled 
> with the stock Python installation (i.e. without building my own Python 
> against e.g. Macports gdbm)

If you are using MacPorts, the easiest way is to use a Python from MacPorts. 
For example,
  port install py36-gdbm
would install everything you would need to use gdbm with their python3.6.
  
> Is it a problem to ship dbm.gnu as part of the default install, so that it is 
> more feasible to assume its existence?

The main problem is that gdbm is GPL3 licensed.  Python source distributions do 
not include any GPL3-licensed software to avoid tainting Python itself.  We 
therefore avoid shipping GPL3 software with python.org binary releases, like 
our macOS installers.

--

___
Python tracker 

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

[issue33074] dbm corrupts index on macOS (_dbm module)

[Ned Deily]

Ned Deily  added the comment:

Addressing your point (5):

> (5) dbm.gnu is not a default, and I can't even work out how to get it enabled 
> with the stock Python installation (i.e. without building my own Python 
> against e.g. Macports gdbm)

If you are using MacPorts, the easiest way is to use a Python from MacPorts. 
For example,
  ports install py36-gdbm
would install everything you would need to use gdbm with their python3.6.
  
> Is it a problem to ship dbm.gnu as part of the default install, so that it is 
> more feasible to assume its existence?

The main problem is that gdbm is GPL3 licensed.  Python source distributions do 
not include any GPL3-licensed software to avoid tainting Python itself.  We 
therefore avoid shipping GPL3 software with python.org binary releases, like 
our macOS installers.

--

___
Python tracker 

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

[issue33169] importlib.invalidate_caches() doesn't clear all caches

[Brett Cannon]

Brett Cannon  added the comment:

Correct because as documented it calls invalidate_caches() on meta-path finders 
and the one that handles sys.path calls invalidate_caches() on the finders 
found in sys.path_importer_cache() (as documented by 
https://docs.python.org/3/library/importlib.html#importlib.machinery.PathFinder.invalidate_caches).
 Since None isn't a finder it doesn't do anything there as there is no method 
to call. So the "full of lies" comment by the OP on the mypy repo is 
over-the-top/incorrect.

Now tweaking 
https://github.com/python/cpython/blob/521995205a2cb6b504fe0e39af22a81f785350a3/Lib/importlib/_bootstrap_external.py#L1180-L1186
 to delete entries in sys.path_importer_cache() that are set to None is 
straight-forward, but I don't think we can backport since it would be going 
against what the documentation says it does.

--
versions: +Python 3.8 -Python 3.6

___
Python tracker 

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

[issue33183] Refactoring: replacing some assertTrue by assertIn

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This is a duplicate of issue16510.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Using appropriate checks in tests

___
Python tracker 

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

[issue33169] importlib.invalidate_caches() doesn't clear all caches

[Brett Cannon]

Change by Brett Cannon :


--
nosy: +brett.cannon, eric.snow, ncoghlan

___
Python tracker 

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

[issue33183] Refactoring: replacing some assertTrue by assertIn

[Stéphane Blondon]

New submission from Stéphane Blondon :

In several cases, tests use ```self.assertTrue(a in b)```. Using 
```self.assertIn(a, b)``` seems to be better.
For examples:
./Lib/test/test_inspect.py:
   self.assertTrue('(po, pk' in repr(sig))
./Lib/test/test_configparser.py:
   self.assertTrue('that_value' in cf['Spacey Bar'])
./Lib/test/test_collections.py:
   self.assertTrue(elem in c)

There are some cases where ```self.assertTrue(a not in b)``` could be replaced 
by  ```self.assertNotIn(a, b)```

./Lib/tkinter/test/test_ttk/test_widgets.py:
   self.assertTrue('.' not in value)
./Lib/test/mapping_tests.py:
   self.assertTrue(not ('a' in d))
   self.assertTrue('a' not in d)


$ find . -name "*.py" | xargs grep -r "assertTrue.* in "
finds 131 occurences but there are some false positives inside the output.

I can write a patch if you are interested.

--
components: Tests
messages: 314670
nosy: sblondon
priority: normal
severity: normal
status: open
title: Refactoring: replacing some assertTrue by assertIn
type: enhancement

___
Python tracker 

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

[issue5315] signal handler never gets called

[Patrick Fink]

Patrick Fink  added the comment:

A workaround to handle signals reliably that I successfully tested now is to 
execute everything within a subthread and let the main thread just join this 
subthread. Like:

signal.signal(MY_SIGNAL, signal_handler)
threading.Thread(target = my_main_function)
thread.start()
thread.join()

Doing it like this, the main thread should always listen to signals 
disregarding whether the subthread is stuck.

--
nosy: +Patrick Fink

___
Python tracker 

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

[issue25433] whitespace in strip()/lstrip()/rstrip()

[Joel Johnson]

Joel Johnson  added the comment:

I have started working on this and will have a pull request submitted by the 
end of the week. 

The term "whitespace" appears in several contextual situations throughout the 
documentation. While all situations would benefit from the definition of 
"whitespace" contained in the str.isspace() documentation, not all of the 
situations would benefit from a link to str.isspace() whose primary goal is to 
document the str.isspace() function and not to provide a global definition of 
what a whitespace character is.

Therefore I suggest the documentation of Python 3 create a new glossary 
definition of "whitespace" (which contains the definition currently in the 
str.isspace() documentation) and is pointed to wherever the term "whitespace" 
is used in any documentation related to strings - including this specific case 
of strip()/lstrip()/rstrip().

--
nosy: +joel.johnson

___
Python tracker 

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

[issue33074] dbm corrupts index on macOS (_dbm module)

[Robert Xiao]

Robert Xiao  added the comment:

So we have some other problems then:

(1) It should be documented in dbm, and ideally in shelve, that keys/values 
over a certain limit might not work. Presently there is no hint that such a 
limit exists, and until you mentioned it I was unaware that POSIX only required 
1023-byte keys and values.
(2) dbm.ndbm should refuse to perform operations that might corrupt the 
database, or it should be deprecated entirely if this is impossible. A built-in 
data storage system for Python should not have an easy corruption route, as it 
is very surprising for users.
(3) It might be worth considering "dbm.sqlite" or somesuch, adapting a SQLite 
database as a key-value store. The key-value store approach is much simpler 
than sqlite and appropriate for certain applications, while SQLite itself would 
provide robustness and correctness. I can volunteer to build such a thing on 
top of the existing Python SQLite support.
(4) The approach of shelve is incompatible with limited-length values, because 
shelve's pickles are of an unpredictable length. This suggests that shelve 
should internally prioritize dumbdbm over ndbm if ndbm cannot guarantee support 
for arbitrary-length keys/values.
(5) dbm.gnu is not a default, and I can't even work out how to get it enabled 
with the stock Python installation (i.e. without building my own Python against 
e.g. Macports gdbm). Is it a problem to ship dbm.gnu as part of the default 
install, so that it is more feasible to assume its existence? 

Thoughts?

--

___
Python tracker 

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

[issue33182] Python 3.7.0b3 fails to build with clang 6.0

[Ned Deily]

Change by Ned Deily :


--
nosy: +ncoghlan, ned.deily
priority: normal -> critical

___
Python tracker 

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

[issue33182] Python 3.7.0b3 fails to build with clang 6.0

[Bernhard Rosenkraenzer]

New submission from Bernhard Rosenkraenzer :

Python 3.7.0b3 fails to build with clang 6.0 (implicit cast from void* to a 
different pointer type is an error now):

/usr/bin/clang++ -c -Wno-unused-result -Wsign-compare -Wunreachable-code 
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -Os -gdwarf-4 -Wstrict-aliasing=2 
-pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-fstack-protector-strong --param=ssp-buffer-size=4  -fPIC -flto -O3 -g -Os 
-gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security 
-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4  -fPIC 
-flto -O3 -D_GNU_SOURCE -fPIC -fwrapv -I/usr/include/ncursesw -flto -Os 
-gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security 
-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4  -fPIC 
-flto -O3 -D_GNU_SOURCE -fPIC -fwrapv -I/usr/include/ncursesw  -Wextra 
-Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers 
-Werror=implicit-function-declaration -Os -gdwarf-4 -Wstrict-aliasing=2 -pipe 
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong 
--param=ssp-buffer-size=4  -fPIC -flto -O3 -D_GNU_
 SOURCE -fPIC -fwrapv -I/usr/include/ncursesw -fprofile-instr-generate  -I. 
-I./Include -Os -gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong 
--param=ssp-buffer-size=4  -fPIC -flto -O3 -D_GNU_SOURCE -fPIC -fwrapv 
-I/usr/include/ncursesw -Os -gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong 
--param=ssp-buffer-size=4  -fPIC -flto -O3 -D_GNU_SOURCE -fPIC -fwrapv 
-I/usr/include/ncursesw -fPIC -DPy_BUILD_CORE -o Programs/_testembed.o 
./Programs/_testembed.c
clang-6.0: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
is deprecated [-Wdeprecated]
./Programs/_testembed.c:173:34: warning: ISO C++11 does not allow conversion 
from string literal to 'wchar_t *' [-Wwritable-strings]
wchar_t *static_warnoption = L"once";
 ^
./Programs/_testembed.c:174:31: warning: ISO C++11 does not allow conversion 
from string literal to 'wchar_t *' [-Wwritable-strings]
wchar_t *static_xoption = L"also_not_an_option=2";
  ^
./Programs/_testembed.c:177:14: error: cannot initialize a variable of type 
'wchar_t *' with an rvalue of type 'void *'
wchar_t *dynamic_once_warnoption = calloc(warnoption_len+1, 
sizeof(wchar_t));
 ^ ~
./Programs/_testembed.c:178:14: error: cannot initialize a variable of type 
'wchar_t *' with an rvalue of type 'void *'
wchar_t *dynamic_xoption = calloc(xoption_len+1, sizeof(wchar_t));
 ^ ~~
2 warnings and 2 errors generated.
make[3]: *** [Makefile:777: Programs/_testembed.o] Error 1

--
components: Tests
files: python-3.7.0b3-clang-6.0.patch
keywords: patch
messages: 314666
nosy: bero
priority: normal
severity: normal
status: open
title: Python 3.7.0b3 fails to build with clang 6.0
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file47505/python-3.7.0b3-clang-6.0.patch

___
Python tracker 

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

[issue33074] dbm corrupts index on macOS (_dbm module)

[Xiang Zhang]

Xiang Zhang  added the comment:

I highly suspect you don't have gdbm installed in your environment and `import 
dbm.gnu` will fail. When simply using `dbm.open`, it searches through [dbm.gnu, 
dbm.ndbm, dbm.dumb]. In my environment, macOS 10.13.3, dbm.gnu works 
correctly(so dbm works correctly) and dbm.ndbm fails with same error. Currently 
I cannot see any code in Python _dbm module could lead to this error. And POSIX 
only requires dbm library to support at least 1023 bytes long key/value pairs.

--
nosy: +xiang.zhang

___
Python tracker 

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

[issue33166] os.cpu_count() returns wrong number of processors on specific systems

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

That makes sense to me. Thanks for deciphering this.

--

___
Python tracker 

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

[issue33175] dataclasses should look up __set_name__ on class, not instance

[Eric V. Smith]

Change by Eric V. Smith :


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

[issue33181] SimpleHTTPRequestHandler shouldn't redirect to directories with code 301

[Oliver Urs Lenz]

New submission from Oliver Urs Lenz :

SimpleHTTPRequestHandler.send_head() has this bit:

if os.path.isdir(path):
parts = urllib.parse.urlsplit(self.path)
if not parts.path.endswith('/'):
# redirect browser - doing basically what apache does
self.send_response(HTTPStatus.MOVED_PERMANENTLY)

https://github.com/python/cpython/blob/521995205a2cb6b504fe0e39af22a81f785350a3/Lib/http/server.py#L676

I think there are two issues here:
1) why should the server return a redirect code here, and not (in the code that 
immediately follows) when it serves an index file?
2) code 301 (permanent redirect) is really unforgiving, browsers like Firefox 
and Chrome will permanently cache the redirect, making it essentially 
impossible to undo if you do not control the client, and not trivial even if 
you do. This will probably not change on the browser-side, general opinion 
seems to be that limited caching should either be specified in the response 
header or that a different redirect code should be sent back.
https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/thread.html#msg363

Therefore I would like to propose that preferably,
- no redirect code be sent back, or else that
- a different redirect code be sent back, or else that
- no-caching or a time limit be added to the header

(This may require that send_head check for index files instead)

--
components: Library (Lib)
messages: 314663
nosy: oulenz
priority: normal
severity: normal
status: open
title: SimpleHTTPRequestHandler shouldn't redirect to directories with code 301
versions: Python 3.6

___
Python tracker 

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

[issue32823] Regression in test -j behavior and time in 3.7.0b1

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Yes. For 3.7 and 3.8, nothing appears until 41 seconds because test___all__ 
takes 40 seconds.  For 3.6, the batch result appears at 37 seconds because 
test___all__ runs in 36 seconds.

--

___
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

[Nick Coghlan]

Nick Coghlan  added the comment:

Also mentioning 
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.set_executable,
 since it came up on the pickle-protocol-version-5 thread.

--

___
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

[Nick Coghlan]

Nick Coghlan  added the comment:

I'm not sure what the right solution is at the design level, but I did recently 
run into a quirk related to this in the embedding tests: on \*nix systems, 
PySys_SetProgramName affects sys.executable, while Windows ignores it.

But certainly the intention is that a non-None sys.executable should be usable 
the way multiprocessing and the test suite use it: as a way to run Python in a 
subprocess. If an embedding environment wants to support that, it can set it to 
something suitable, and if it doesn't, it can set it to None.

(I do sometimes wonder if subprocess should have some sys.executable-specific 
helpers though - rerunning Python with the same settings as the current Python 
requires quite a bit more than just calling sys.executable with no particular 
options)

--

___
Python tracker 

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

[issue33175] dataclasses should look up __set_name__ on class, not instance

[miss-islington]

miss-islington  added the comment:


New changeset faa6f5c74ca56d4cc0dd9db78d5c8e864b617d0c by Miss Islington (bot) 
in branch '3.7':
bpo-33175: dataclasses should look up __set_name__ on class, not instance 
(GH-6305)
https://github.com/python/cpython/commit/faa6f5c74ca56d4cc0dd9db78d5c8e864b617d0c


--
nosy: +miss-islington

___
Python tracker 

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

[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

[Mark Dickinson]

Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue33179] Investigate using a context variable for zero-arg super initialisation

[Yury Selivanov]

Yury Selivanov  added the comment:

> Even without context chaining, it seems to me that nesting of class 
> definitions could be handled by making the context variable a list of cell 
> objects and having type.__new__ look at the final entry rather than the whole 
> thing.

Hum, yeah, this might work :)

--

___
Python tracker 

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

[issue33175] dataclasses should look up __set_name__ on class, not instance

[Eric V. Smith]

Eric V. Smith  added the comment:


New changeset 521995205a2cb6b504fe0e39af22a81f785350a3 by Eric V. Smith in 
branch 'master':
bpo-33175: dataclasses should look up __set_name__ on class, not instance 
(GH-6305)
https://github.com/python/cpython/commit/521995205a2cb6b504fe0e39af22a81f785350a3


--

___
Python tracker 

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

[issue33175] dataclasses should look up __set_name__ on class, not instance

[miss-islington]

Change by miss-islington :


--
pull_requests: +6027

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

Looking at the docs https://docs.python.org/3/library/sys.html#sys.executable 
maybe we only need to clarify that it's not None only if it provides the normal 
command line? Then file bugs against all the libraries that don't work when 
it's not set?

--

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

New submission from Steve Dower :

If you host Python in another program, it's likely that sys.executable is not 
pointing to a normal Python interpreter. This can cause libraries such as 
multiprocessing to fail when they try to launch the interpreter again. Worse, 
it may have launched your application many more times before failure :)

I think we should add either a flag to indicate to any such library that 
sys.executable is not useful for relaunching Python, or a field that points to 
the actual executable but can safely be left None (or for most horrendous 
generality, a list of arguments to relaunch, as sometimes a command line option 
can get you into a normal interpreter). These would be set by embedders only, 
and Programs/python.c would set the "normal" values.

Thoughts?

--
assignee: steve.dower
messages: 314655
nosy: eric.snow, ncoghlan, steve.dower
priority: normal
severity: normal
status: open
title: Flag for unusable sys.executable
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue33179] Investigate using a context variable for zero-arg super initialisation

[Nick Coghlan]

Nick Coghlan  added the comment:

Note that this isn't about the __class__ reference itself - that would still be 
a closure cell.

This issue is about the fact that since Python 3.6, type.__new__ has handled 
calling __set_name__ on all the descriptors, so __build_class__ needs a way to 
pass the cell over to type.__new__.

Currently, the channel for that is the class body execution namespace itself, 
which created a new requirement for metaclasses to ensure that the 
"__classcell__" entry actually makes it all the way to "type.__new__". Django 
at least had to make changes to account for that, and it's mildly disappointing 
to be imposing that requirement on library and framework authors solely because 
of a technical limitation in CPython.

Even without context chaining, it seems to me that nesting of class definitions 
could be handled by making the context variable a list of cell objects and 
having type.__new__ look at the final entry rather than the whole thing.

--

___
Python tracker 

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

[issue33177] make install hangs on macOS when there is an existing Python app

[Joongi Kim]

Joongi Kim  added the comment:

I found that the reason was my Python 3.6.4 installed via the 
official-installer has the permission of "root:wheel" and pyenv is running in 
my plain user privilege. Using chown command to change the permissions to 
"joongi:admin" and retrying worked.

What I'm curious now is: why didn't "rm -r /Application/Python\ 3.6" command 
explicitly display the permission error and just the whole installation process 
hanged up?

--

___
Python tracker 

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

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

[Nick Coghlan]

Nick Coghlan  added the comment:

The locale module has its own extra layer of oddities that I don't personally 
understand - #29571 and #20087 are another couple of issues along those lines.

--

___
Python tracker 

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

[issue33179] Investigate using a context variable for zero-arg super initialisation

[Yury Selivanov]

Yury Selivanov  added the comment:

This would work only if we had chained contexts from PEP 550.  With PEP 567, 
swapping the current Context in boundmethods would cause all methods to lose 
the context that the user wanted them to run in.

--

___
Python tracker 

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

[issue33179] Investigate using a context variable for zero-arg super initialisation

[Nick Coghlan]

New submission from Nick Coghlan :

As noted in 
https://docs.python.org/3/reference/datamodel.html?#creating-the-class-object, 
implementing PEP 487 required the introduction of __classcell__ as a way for 
__build_class__ to pass the zero-arg super() cell object through to 
type.__new__.

Now that Python 3.7+ offers context variables, we may be able to design a more 
robust (and better hidden) alternative which stashes the "current zero-arg 
super cell object" in a context variable, allowing type.__new__ to retrieve it 
when needed, without having to pass it through the class body execution 
namespace.

--
messages: 314650
nosy: Martin.Teichmann, encukou, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: Investigate using a context variable for zero-arg super initialisation
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

[issue33178] Add support for BigEndianUnion and LittleEndianUnion in ctypes

[emezh]

emezh  added the comment:

updated nosy list

--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, theller

___
Python tracker 

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

[issue33178] Add support for BigEndianUnion and LittleEndianUnion in ctypes

[emezh]

New submission from emezh :

Python documentation says that "To build structures with non-native byte order, 
you can use one of the BigEndianStructure, LittleEndianStructure, 
BigEndianUnion, and LittleEndianUnion base classes"

However, BigEndianUnion ad LittleEndianUnion are not implemented

>>> from ctypes import *
>>> BigEndianStructure

>>> BigEndianUnion
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'BigEndianUnion' is not defined

Is that something that can be added?

See also https://bugs.python.org/issue19023

--
components: ctypes
messages: 314647
nosy: Eugene Mezhibovsky
priority: normal
severity: normal
status: open
title: Add support for BigEndianUnion and LittleEndianUnion in ctypes
type: enhancement
versions: Python 2.7, Python 3.6

___
Python tracker 

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

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

[Ned Deily]

Ned Deily  added the comment:

Thanks for the headsup, Nick.  BTW, some of the discussion in languishing 
Issue18378 might be relevant here.

--

___
Python tracker 

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

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

[Nick Coghlan]

Nick Coghlan  added the comment:

Ned, I'd forgotten about the part of this issue which amounts to "Check for 
'POSIX' as a locale coercion trigger in addition to 'C', as not every platform 
aliases the former to the latter the way glibc does".

So while I don't think this is really a release blocker (as you have to 
explicitly request the POSIX locale to encounter the discrepancy, and I think 
fixing it in 3.7.1 would be OK), I *am* bumping it up to "critical", as I think 
it would be better to resolve this for 3.7.0b4 rather than letting it linger 
further.

--
priority: normal -> critical

___
Python tracker 

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

[issue32726] macOS installer and framework enhancements and changes for 3.7.0 and 3.6.5

[Ned Deily]

Ned Deily  added the comment:


New changeset b9e7fe38a07a16942cb65cb922c234c95e2823a0 by Ned Deily in branch 
'master':
bpo-32726: macOS 10.6+ installer now builds Tcl/TK 8.6 (GH-6307)
https://github.com/python/cpython/commit/b9e7fe38a07a16942cb65cb922c234c95e2823a0


--

___
Python tracker 

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

[issue32380] functools.singledispatch interacts poorly with methods

[Nick Coghlan]

Nick Coghlan  added the comment:

Added Łukasz to the nosy list, as I'd like his +1 before accepting this change 
(I do still think it's a good idea, for the same reasons we added 
partialmethod).

--
nosy: +lukasz.langa, ncoghlan

___
Python tracker 

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

[issue32726] macOS installer and framework enhancements and changes for 3.7.0 and 3.6.5

[Ned Deily]

Ned Deily  added the comment:


New changeset 7a6f59e123db1ff4bdf311711ad179421ee12b83 by Ned Deily in branch 
'3.7':
bpo-32726: macOS 10.6+ installer now builds Tcl/TK 8.6 (GH-6308)
https://github.com/python/cpython/commit/7a6f59e123db1ff4bdf311711ad179421ee12b83


--

___
Python tracker 

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

[issue32726] macOS installer and framework enhancements and changes for 3.7.0 and 3.6.5

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +6026

___
Python tracker 

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

[issue32726] macOS installer and framework enhancements and changes for 3.7.0 and 3.6.5

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +6025

___
Python tracker 

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

[issue32380] functools.singledispatch interacts poorly with methods

[Ethan Smith]

Change by Ethan Smith :


--
versions: +Python 3.8 -Python 3.6

___
Python tracker 

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

[issue32380] functools.singledispatch interacts poorly with methods

[Ethan Smith]

Change by Ethan Smith :


--
pull_requests: +6024

___
Python tracker 

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

[issue32823] Regression in test -j behavior and time in 3.7.0b1

[Ned Deily]

Ned Deily  added the comment:

Terry, is this still an issue?  Are other Windows developers seeing this?

--
nosy: +ned.deily, paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue33177] make install hangs on macOS when there is an existing Python app

[Ned Deily]

Ned Deily  added the comment:

P.S. There *is* an old languishing issue, Issue11486, to add an option to 
configure to have framework builds not try to install into /Applications.  The 
patch there would need to be updated and turned into a PR for review.

--

___
Python tracker 

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

[issue33177] make install hangs on macOS when there is an existing Python app

[Ned Deily]

Ned Deily  added the comment:

Sorry, we can't do much about pyenv issues, suggest you pursue with that 
project.  If pyenv uses the python.org installers, there is an installer option 
to avoid installing into /Applications.  If pyenv does its own Python framework 
build, it can install the framework and the Applications directory into any 
directory using the --enable-framework=/path/to/directory option of ./configure.

--
resolution:  -> third party
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

[issue33177] make install hangs on macOS when there is an existing Python app

[Joongi Kim]

New submission from Joongi Kim :

I have installed Python 3.6.4 for macOS by downloading from the official site 
(www.python.org) and then tried installing 3.6.5 using pyenv.

Then the installation process hangs here:

https://user-images.githubusercontent.com/555156/38078784-57e44462-3378-11e8-8011-9579afc3c811.png

There is a 2-years old issue in pyenv 
(https://github.com/pyenv/pyenv/issues/512) but this may have to be fixed from 
here.

--
components: Installation, macOS
messages: 314639
nosy: achimnol, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: make install hangs on macOS when there is an existing Python app
type: behavior
versions: Python 3.6

___
Python tracker 

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

[issue31817] Compilation Error with Python 3.6.1/3.6.3 with Tkinter

[Artur Yarmolin]

Artur Yarmolin <6598...@gmail.com> added the comment:

Python 3.6.4
tcl8.6.5+dfsg-2
tk8.6.5-1

The problem:

*** WARNING: renaming "_tkinter" since importing it failed: 
build/lib.linux-x86_64-3.6/_tkinter.cpython-36m-x86_64-linux-gnu.so: undefined 
symbol: Tcl_GetCharLength

still remains!

--
nosy: +6598335

___
Python tracker 

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

[issue33175] dataclasses should look up __set_name__ on class, not instance

[Eric V. Smith]

Change by Eric V. Smith :


--
keywords: +patch
pull_requests: +6023
stage: needs patch -> patch review

___
Python tracker 

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

[issue33176] Allow memoryview.cast(readonly=...)

[Antoine Pitrou]

New submission from Antoine Pitrou :

It may be useful to get a readonly view of a memoryview.

--
components: Interpreter Core
messages: 314637
nosy: pitrou, skrah
priority: normal
severity: normal
status: open
title: Allow memoryview.cast(readonly=...)
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

[issue33175] dataclasses should look up __set_name__ on class, not instance

[Eric V. Smith]

New submission from Eric V. Smith :

Reported by Jelle Zijlstra at 
https://github.com/python/cpython/pull/6260#pullrequestreview-107905037

--
assignee: eric.smith
components: Library (Lib)
messages: 314636
nosy: eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: dataclasses should look up __set_name__ on class, not instance
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with PROTOCOL_TLS

[Ned Deily]

Ned Deily  added the comment:

Christian, is there more needed for this issue or can it be closed?

--

___
Python tracker 

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

[issue33131] Upgrade to pip 10 for Python 3.7

[Ned Deily]

Ned Deily  added the comment:

The changelog for a release is our primary notification to users about what has 
changed in a Python release.  With 3.6.5, we just had a case where it seemed 
important to update pip between the release candidate and the final, something 
we normally would not do.  In the past, we could manually munge the changelog 
to include this info but it's much more difficult to do so now with the NEWS 
entries managed via blurb.  In fact, IIRC, it was a design decision to require 
a b.p.o issue for any item meriting a NEWS item.  So, it's a bit of extra work 
for you all but it does make life a lot easier for the release team as it's a 
lot easier to add the NEWS item at the time when the updates are checked in 
rather than having to go back and do it after the fact. Thanks!

https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-5-final

--

___
Python tracker 

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

[issue9584] fnmatch, glob: Allow curly brace expansion

[Matúš Valo]

Matúš Valo  added the comment:

Hi All,

I have created new patch for handling curly brace expansion. The patch is 
available on Github PR #6299

--
nosy: +Matúš Valo

___
Python tracker 

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