[issue34987] A possible null pointer dereference in _pickle.c's save_reduce()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is checked, and there is a comment about this.

p = obj_class != cls;/* true iff a problem */

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue34747] SSLSocket.context cannot be changed on non-connected sockets

[Vincent Pelletier]

Change by Vincent Pelletier :


--
assignee:  -> christian.heimes
components: +Library (Lib), SSL
nosy: +christian.heimes

___
Python tracker 

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

[issue34987] A possible null pointer dereference in _pickle.c's save_reduce()

[Zackery Spytz]

Change by Zackery Spytz :


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

___
Python tracker 

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

[issue34987] A possible null pointer dereference in _pickle.c's save_reduce()

[Zackery Spytz]

New submission from Zackery Spytz :

The get_class() call in save_reduce() is not checked for failure.

--
components: Extension Modules
messages: 327732
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A possible null pointer dereference in _pickle.c's save_reduce()
type: crash
versions: 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

[issue34957] Segementation faults on ARM and ARM64

[Kubilay Kocak]

Kubilay Kocak  added the comment:

All our FreeBSD ports (lang/python??) and the packages produced from them all 
contain a LIBFFI option which is enabled by default, since 2015 [1][2]:

LIBFFI=on: Use libffi from ports instead of bundled version

This means that any 'default' package builds of these ports, including those in 
the official package repositories, will install and build again st the 
port/package version of libffi, and not the bundled version.

This was originally due to broken builds on i386 (see #22521 and issue23042), 
but also to due library policy (use external/upstream, not bundled libraries), 
and not wanting to use outdated/stale version any longer.

[1] python27: https://svnweb.freebsd.org/changeset/ports/377581
[2] python34+: https://svnweb.freebsd.org/changeset/ports/378821

--

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 43308dfc3335906cfefe9f14a44e468935f3c321 by Serhiy Storchaka in 
branch '2.7':
[2.7] bpo-34974: Do not replace unexpected errors in bytearray(). (GH-9852) 
(GH-9885)
https://github.com/python/cpython/commit/43308dfc3335906cfefe9f14a44e468935f3c321


--

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
versions: +Python 2.7

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +9248

___
Python tracker 

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

[issue34572] C unpickling bypasses import thread safety

[Tim Burgess]

Tim Burgess  added the comment:

Hi!  Just wondering if there is anything I can do to move this along?

--

___
Python tracker 

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

[issue34986] python finds test modules from the wrong directory during PGO build

[Kal Sze]

Kal Sze  added the comment:

Oops, sorry for the noise. This is mostly a duplicate of #34985 because the 
crash log attachment was too big and caused the issue tracker's proxy server to 
return an error code, so I thought the initial bug report creation failed. An 
e-mail confirmation arrived only much later.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue34986] python finds test modules from the wrong directory during PGO build

[Kal Sze]

New submission from Kal Sze :

OS: Ubuntu Desktop 18.04.1 x86-64
Python 3.7.0

When trying to build Python 3.7 from source, with the `--enable-shared 
--enable-optimizations --with-lto` configure options, python needs to run the 
test suite in order to generate PGO data. However, it turns out that it would 
find test modules from the wrong directory, if there is already another version 
of Python 3 installed system-wide (Ubuntu 18.04 comes with Python 3.6 
pre-installed).

I found out because Ubuntu's automatic crash reporter caught a core dump during 
`python -m tests.regrtest` and I could see that python found the tests.regrtest 
module at `/usr/lib/python3.6/test/regrtest.py`.

In the end, the build is reported as "successful", I guess it's because the 
Makefile expects it the crash anyway. In any case, it still seems wrong because 
it means the wrong test suite is run.

Ubuntu's crash report in raw format is attached, for anybody who knows how to 
read it (it's in plain text anyway)

--
components: Build
files: _usr_lib_python3.6_test_regrtest.py.1000.crash
messages: 327726
nosy: Kal Sze2
priority: normal
severity: normal
status: open
title: python finds test modules from the wrong directory during PGO build
type: behavior
versions: Python 3.7
Added file: 
https://bugs.python.org/file47868/_usr_lib_python3.6_test_regrtest.py.1000.crash

___
Python tracker 

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

[issue34985] python finds test modules from the wrong directory during PGO build

[Kal Sze]

New submission from Kal Sze :

OS: Ubuntu Desktop 18.04.1 x86-64
Python 3.7.0

When trying to build Python 3.7 from source, with the `--enable-shared 
--enable-optimizations --with-lto` configure options, python needs to run the 
test suite in order to generate PGO data. However, it turns out that it would 
find test modules from the wrong directory, if there is already another version 
of Python 3 installed system-wide (Ubuntu 18.04 comes with Python 3.6 
pre-installed).

I found out because Ubuntu's automatic crash reporter caught a core dump during 
`python -m tests.regrtest` and I could see that python found the tests.regrtest 
module at `/usr/lib/python3.6/test/regrtest.py`.

In the end, the build is reported as "successful", I guess it's because the 
Makefile expects it the crash anyway. In any case, it still seems wrong because 
it means the wrong test suite is run.

I have uploaded Ubuntu's crash report in raw format here, for anybody who knows 
how to read it (it's in plain text anyway): 
https://www.dropbox.com/s/6ihxoouoqe1k98f/_usr_lib_python3.6_test_regrtest.py.1000.crash?dl=0

--
components: Build
messages: 327725
nosy: Kal Sze2
priority: normal
severity: normal
status: open
title: python finds test modules from the wrong directory during PGO build
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

[issue33450] unexpected EPROTOTYPE returned by sendto on MAC OSX

[Eamonn Nugent]

Eamonn Nugent  added the comment:

Fwiw, this also happens in asyncio. Theoretically, I *think* you could wrap a 
try-except as a monkey patch.

My stack trace is:

Fatal write error on socket transport
protocol: 
transport: <_SelectorSocketTransport fd=163 read=polling write=>
Traceback (most recent call last):
  File 
"/usr/local/Cellar/python/3.6.5_1/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/selector_events.py",
 line 761, in write
n = self._sock.send(data)
OSError: [Errno 41] Protocol wrong type for socket

I can try to PR the fix mentioned by @ronaldoussoren, though it might take me a 
bit. I'm happy to do whatever to get this fixed, though, since it's flooding my 
terminal with several hundred errors every time it happens...

--
nosy: +Eamonn Nugent

___
Python tracker 

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

[issue32321] functools.reduce has a redundant guard or needs a pure Python fallback

[Braden Groom]

Change by Braden Groom :


--
pull_requests: +9246

___
Python tracker 

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

[issue24653] Mock.assert_has_calls([]) is surprising for users

[Srinivas Reddy T]

Change by Srinivas  Reddy T :


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

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[miss-islington]

miss-islington  added the comment:


New changeset 08ba7eb89d5353af31ef9e66a5337abea1b676ef by Miss Islington (bot) 
in branch '3.6':
bpo-34974: Do not replace unexpected errors in bytes() and bytearray(). 
(GH-9852)
https://github.com/python/cpython/commit/08ba7eb89d5353af31ef9e66a5337abea1b676ef


--

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[miss-islington]

miss-islington  added the comment:


New changeset 1370832af24cc6f0f464354b9ec3ecdb343d35ce by Miss Islington (bot) 
in branch '3.7':
bpo-34974: Do not replace unexpected errors in bytes() and bytearray(). 
(GH-9852)
https://github.com/python/cpython/commit/1370832af24cc6f0f464354b9ec3ecdb343d35ce


--
nosy: +miss-islington

___
Python tracker 

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

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +9244

___
Python tracker 

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

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +9243

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset e890421e334ccf0c000c6b29c4a521d86cd12f47 by Serhiy Storchaka in 
branch 'master':
bpo-34974: Do not replace unexpected errors in bytes() and bytearray(). 
(GH-9852)
https://github.com/python/cpython/commit/e890421e334ccf0c000c6b29c4a521d86cd12f47


--

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[miss-islington]

Change by miss-islington :


--
pull_requests: +9241

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[miss-islington]

Change by miss-islington :


--
pull_requests: +9242

___
Python tracker 

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

[issue9453] pulldom.SAX2DOM Doesn't support processing instructions before the root element

[Tal Einat]

Tal Einat  added the comment:

Proposing removal of SAX2DOM doesn't seem unreasonable to me. However, 
considering it hasn't been removed so far, we'll need good reason to do so 
since that would break backwards compatibility.

Jonathan, if the solution to this is simple, I say go for it and make a PR.

--

___
Python tracker 

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

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

[Srinivas Reddy T]

Change by Srinivas  Reddy T :


--
keywords: +patch
pull_requests: +9240
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

[issue17561] Add socket.create_server_sock() convenience function

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Since Tulip/asyncio has gone through a lot of development since this issue was 
added, I wasn't sure if this has been included already or if there was still 
interest in it.  In either case, I think it might be able to be closed, but I 
wanted to make sure first.  Thanks!

--
nosy: +asvetlov, cheryl.sabella

___
Python tracker 

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

[issue34976] IDLE: Replace the search dialog with a search bar

[Cheryl Sabella]

Cheryl Sabella  added the comment:

+1 on adding this to IDLE

I haven't looked at the code or all the details yet, but just downloading the 
patch and running code in IDLE, this is a nice change.

--

___
Python tracker 

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

[issue34939] Possibly spurious SyntaxError: annotated name can't be global

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

[issue9453] pulldom.SAX2DOM Doesn't support processing instructions before the root element

[Jonathan Gossage]

Jonathan Gossage  added the comment:

This test case demonstrates that the issue still exists in 3.8. The fix is 
relatively simple but I am unsure whether it is worthwhile as the original 
comments on the quality and usability of SAX2DOM are spot on. My recommendation 
would be to mark it as pending and close it at the end of a month if no-one 
submits a fix.

--
nosy: +Jonathan.Gossage, taleinat
Added file: https://bugs.python.org/file47867/issue9453.py

___
Python tracker 

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

[issue34939] Possibly spurious SyntaxError: annotated name can't be global

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset de2aea0ff02fa9486365ce9d215bef150fae3a0b by Pablo Galindo in 
branch 'master':
bpo-34939: Allow annotated global names in module namespace (GH-9844)
https://github.com/python/cpython/commit/de2aea0ff02fa9486365ce9d215bef150fae3a0b


--
nosy: +pablogsal

___
Python tracker 

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

[issue29159] Regression in bytes constructor

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests:  -1003

___
Python tracker 

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

[issue34984] Improve error messages in bytes and bytearray constructors

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue34984] Improve error messages in bytes and bytearray constructors

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The proposed PR improves error messages in bytes and bytearray constructors.

1. When pass only encoding or errors to the bytes or bytearray constructor, it 
raises a TypeError with the message "encoding or errors without sequence 
argument". But the required argument is not a sequence, it is a string. 
"sequence argument" will be replaced with "a string argument".

2. Also "encoding or errors" will be replaced with just "encoding" or "errors", 
as in bytes(0, 'utf-8') and bytes(0, errors='utf-8').

3. When pass an unsupported type to the bytearray constructor, it raises  a 
TypeError with the message like "'float' object is not iterable". It will be 
replaced with "cannot convert 'float' object to bytearray" (similar to the 
message raised in the bytes constructor).

4. When pass an unsupported type to the bytearray's extend() method, it raises  
a TypeError with the message like "'float' object is not iterable". It will be 
replaced with "can't extend bytearray with float".

--
assignee: serhiy.storchaka
components: Interpreter Core
messages: 327715
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve error messages in bytes and bytearray constructors
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

[issue34521] Multiple tests (test_socket, test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer lengths, causing failures on FreeBSD CURRENT

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset bd036d3d15fc1310ccc32a43a3296b8c157ac221 by Pablo Galindo in 
branch 'master':
bpo-34521: Add NEWS entry for changes in GH-9613 (GH-9850)
https://github.com/python/cpython/commit/bd036d3d15fc1310ccc32a43a3296b8c157ac221


--

___
Python tracker 

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

[issue20216] Misleading docs for sha1, sha256, sha512, md5 modules

[Srinivas Reddy T]

Change by Srinivas  Reddy T :


--
pull_requests: +9238
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

[issue34983] expose symtable.Symbol.is_nonlocal()

[Pablo Galindo Salgado]

New submission from Pablo Galindo Salgado :

The symtable has information about if a particular symbol is nonlocal though 
the DEF_LOCAL flag but this information is not exposed in symtable.py, making 
impossible to ask if a symbol is declared as nonlocal using the python symtable 
module.

--
components: Interpreter Core
messages: 327713
nosy: pablogsal
priority: normal
severity: normal
status: open
title: expose symtable.Symbol.is_nonlocal()
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

[issue34983] expose symtable.Symbol.is_nonlocal()

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue34982] re.sub() different behavior in 3.7

[purificant]

purificant  added the comment:

Great, thank you for explaining. My specific use case can be fixed by replacing 
* with + as per your suggestion.

--

___
Python tracker 

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

[issue34982] re.sub() different behavior in 3.7

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Yes, this is an intended change. Your pattern matches an empty string at the 
end of the input string. It was a bug in earlier Python versions that re.sub() 
didn't replace empty matches adjacent to a previous non-empty match.

It is not clear what is the purpose of your code, but adding anchors or 
replacing * with + usually helps.

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

___
Python tracker 

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

[issue34982] re.sub() different behavior in 3.7

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue34982] re.sub() different behavior in 3.7

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks for the report. git bisect tells me this change was introduced with 
fbb490fd2f38bd817d99c20c05121ad0168a38ee (issue32308)

# ../backups/bpo34982.py
import re

print(re.sub(r'(([^/]*)(/.*)?)', r'\2.zip/\1/', 'example'))

# Running script at fbb490fd2f38bd817d99c20c05121ad0168a38ee

➜  cpython git:(fbb490fd2f) ./python.exe ../backups/bpo34982.py
example.zip/example/.zip//

# Script at fbb490fd2f38bd817d99c20c05121ad0168a38ee~1

➜  cpython git:(fbb490fd2f) git checkout -q 
fbb490fd2f38bd817d99c20c05121ad0168a38ee~1
➜  cpython git:(0cc99c8cd7) make > /dev/null
➜  cpython git:(0cc99c8cd7) ./python.exe ../backups/bpo34982.py
example.zip/example/

I think is an intended change as noted in the message that might break third 
party code (msg308229) . Adding Serhiy for thoughts.

--

___
Python tracker 

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

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

[Lu jaymin]

Lu jaymin  added the comment:

Thanks for your suggestions. I will make  a PR on github.

The buffer is resizeable now, please see cpython/Parser/tokenizer.c#L1043

for details.

--

___
Python tracker 

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

[issue6686] xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes

[Jonathan Gossage]

Jonathan Gossage  added the comment:

The other thing to consider which also supports option 2 is that 
xml.parsers.expat provides an interface to the Expat parser which is easier to 
use and more complete than the Sax parser implementation and is the 
implementation likely to be used by anyone needing a streaming parser.

--

___
Python tracker 

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

[issue34982] re.sub() different behavior in 3.7

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue34982] re.sub() different behavior in 3.7

[purificant]

New submission from purificant :

A call to re.sub() returns different results in Python 3.7 compared to versions 
3.6 / 3.5 and 2.7

Example behavior in 2.7 / 3.5 and 3.6:
>>> re.sub(r'(([^/]*)(/.*)?)', r'\2.zip/\1/', 'example')
'example.zip/example/'

Example in 3.7.0 and 3.7.1rc2:
>>> re.sub(r'(([^/]*)(/.*)?)', r'\2.zip/\1/', 'example')
'example.zip/example/.zip//'

As you can see the returned string is different for the same regex. re.subn() 
confirms that 2 replacements are made instead of 1.

Is it intended to have different behaviour in 3.7+ or is this a bug?
Thanks

--
components: Regular Expressions
messages: 327707
nosy: ezio.melotti, mrabarnett, purificant
priority: normal
severity: normal
status: open
title: re.sub() different behavior in 3.7
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks for the confirmation. I think the expected solution is to use a buffer 
that can be resized. CPython accepts GitHub PRs so if you have time then I 
would suggest raising a PR against the linked issue since a lot of people have 
subscribed there and would get a good feedback.

As a suggestion when you reply from email please remove the quoted content 
since it makes the message very long and hard to read in the bug tracker.

--

___
Python tracker 

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

[issue34912] Update overflow checks in resize_buffer

[Stefan Behnel]

Stefan Behnel  added the comment:

If I understand the code right, "PY_SSIZE_T_MAX/sizeof(Py_UCS4)" would not be 
correct since it would unnecessarily limit the length of ASCII-only unicode 
strings.

I think the initial check avoids the risk of integer overflow in the 
calculations below, so it's not entirely redundant.

--
nosy: +scoder

___
Python tracker 

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

[issue34981] Unable to install Python from web-based installer and executable installer

[Eric V. Smith]

Change by Eric V. Smith :


--
components: +Windows
nosy: +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

[issue34972] json dump silently converts int keys to string

[Eric V. Smith]

Change by Eric V. Smith :


--
resolution:  -> not a bug

___
Python tracker 

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

[issue34972] json dump silently converts int keys to string

[My-Tien Nguyen]

Change by My-Tien Nguyen :


--
status: open -> closed

___
Python tracker 

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

[issue34981] Unable to install Python from web-based installer and executable installer

[skycraper]

New submission from skycraper :

I have a PC with 2 HDD with 2 Vista OS at each other. One system is old and it 
has Python 3.7 installed and working successfully. The second system is 
new-installed and it has a problems with running web-based installers and 
executable-installer of the latest Python`s version from there: 
https://www.python.org/downloads/windows/ 

So I can run an install from any MSI-package for every version, but 3.5-3.7 
versions don`t have it. When I`m trying to install wb-inst or exe-inst nothing 
happens: no error window, no system lags etc. 

I suppose that this problem connected with Microsoft libraries or extensions. I 
installed all Visual Studio C++ packages, but it didn`t help. 

Could you tell me which components I forgot to intall.

--
components: Installation
messages: 327704
nosy: skycraper
priority: normal
severity: normal
status: open
title: Unable to install Python from web-based installer and executable 
installer
type: crash
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

[issue34972] json dump silently converts int keys to string

[My-Tien Nguyen]

My-Tien Nguyen  added the comment:

Sure, I can do that, but wanted to propose this regardless. I guess this is a 
disagreement on a language design level.
As a proponent of strong typing I wouldn’t have allowed non-string keys in the 
first place, and if they are allowed I would warn about conversion. This is 
also more aligned with the “explicit is better than implicit” principle.

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

___
Python tracker 

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

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

[Lu jaymin]

Lu jaymin  added the comment:

I think these two issue is the same issue, and the following is a patch
write by me, hope this patch will help.

```
diff --git a/Parser/tokenizer.c b/Parser/tokenizer.c
index 1af27bf..ba6fb3a 100644
--- a/Parser/tokenizer.c
+++ b/Parser/tokenizer.c
@@ -617,32 +617,21 @@ decoding_fgets(char *s, int size, struct tok_state
*tok)
 if (!check_coding_spec(line, strlen(line), tok, fp_setreadl)) {
 return error_ret(tok);
 }
-}
-#ifndef PGEN
-/* The default encoding is UTF-8, so make sure we don't have any
-   non-UTF-8 sequences in it. */
-if (line && !tok->encoding) {
-unsigned char *c;
-int length;
-printf("[DEBUG] - [decoding_fgets]: line = %s\n", line);
-for (c = (unsigned char *)line; *c; c += length)
-if (!(length = valid_utf8(c))) {
-badchar = *c;
-break;
+if(!tok->encoding){
+char* cs = new_string("utf-8", 5, tok);
+int r = fp_setreadl(tok, cs);
+if (r) {
+tok->encoding = cs;
+tok->decoding_state = STATE_NORMAL;
+} else {
+PyErr_Format(PyExc_SyntaxError,
+ "You did not decalre the file encoding at the
top of the file, "
+ "and we found that the file is not encoding
by utf-8,"
+ "see http://python.org/dev/peps/pep-0263/ for
details.");
+PyMem_FREE(cs);
 }
+}
 }
-if (badchar) {
-/* Need to add 1 to the line number, since this line
-   has not been counted, yet.  */
-PyErr_Format(PyExc_SyntaxError,
-"Non-UTF-8 code starting with '\\x%.2x' "
-"in file %U on line %i, "
-"but no encoding declared; "
-"see http://python.org/dev/peps/pep-0263/ for details",
-badchar, tok->filename, tok->lineno + 1);
-return error_ret(tok);
-}
-#endif
 return line;
 }
```

by the way, my platform is macOS Mojave Version 10.14

Karthikeyan Singaravelan  于2018年10月14日周日 下午5:10写道：

>
> Karthikeyan Singaravelan  added the comment:
>
> Got it. Thanks for the details and patience. I tested with less number of
> characters and it seems to work fine so using the encoding at the top is
> not a good way to test the original issue as you have mentioned. Then I
> searched around and found issue14811 with test. This seems to be a very
> similar issue and there is a patch to detect this scenario to throw
> SyntaxError that the line is longer than the internal buffer instead of an
> encoding related error. I applied the patch to master and it throws an
> error about the internal buffer length as expected. But the patch was not
> applied and it seems Victor had another solution in mind as per msg167154.
> I tested with the patch as below :
>
> # master
>
> ➜  cpython git:(master) cat ../backups/bpo34979.py
>
> s =
> '测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试'
>
> print("str len : ", len(s))
> print("bytes len : ", len(s.encode('utf-8')))
> ➜  cpython git:(master) ./python.exe ../backups/bpo34979.py
>   File "../backups/bpo34979.py", line 2
> SyntaxError: Non-UTF-8 code starting with '\xe8' in file
> ../backups/bpo34979.py on line 2, but no encoding declared; see
> http://python.org/dev/peps/pep-0263/ for details
>
>
> # Applying the patch file from issue14811
>
> ➜  cpython git:(master) ✗ ./python.exe ../backups/bpo34979.py
>   File "../backups/bpo34979.py", line 2
> SyntaxError: Line 2 of file ../backups/bpo34979.py is longer than the
> internal buffer (1024)
>
> # Patch on master
>
> diff --git a/Parser/tokenizer.c b/Parser/tokenizer.c
> index fc75bae537..48b3ac0ee9 100644
> --- a/Parser/tokenizer.c
> +++ b/Parser/tokenizer.c
> @@ -586,6 +586,7 @@ static char *
>  decoding_fgets(char *s, int size, struct tok_state *tok)
>  {
>  char *line = NULL;
> +size_t len;
>  int badchar = 0;
>  for (;;) {
>  if (tok->decoding_state == STATE_NORMAL) {
> @@ -597,6 +598,15 @@ decoding_fgets(char *s, int size, struct tok_state
> *tok)
>  /* We want a 'raw' read. */
>  line = Py_UniversalNewlineFgets(s, size,
>  tok->fp, NULL);
> +   if (line != NULL) {
> +len = strlen(line);
> +if (1 < len && line[len-1] != '\n') {
> +PyErr_Format(PyExc_SyntaxError,
> +"Line %i of file %U is longer than the
> internal buffer (%i)",
> +tok->lineno + 1, tok->filename, size);
> + 

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

[Mario]

Mario  added the comment:

On 13/10/2018 17:37, Steve Dower wrote:
> 
> Steve Dower  added the comment:
> 
> I meant why are you using an embedded application with a virtual environment? 
> What sort of application do you have that requires users to configure a 
> virtual environment, rather than providing its own set of libraries?
> 
> The embedding scenarios I'm aware of almost always want privacy/isolation 
> from whatever a user has installed/configured, so that they can work reliably 
> even when users modify other parts of their own system. I'm trying to 
> understand what scenario (other than "I am an interactive Python shell") 
> would want to automatically pick up the configuration rather than having its 
> own configuration files/settings.

Does it really matter who owns main(), whether it is in python.exe or in some 
other C app.

This is exactly how you described, users want to use some C application which 
will call into python 
using some (user defined) python modules to execute some tasks which are 
scriptable.
And they want to be able to do in a confined environment where they can install 
the exact set of 
packages they require. And it is possible at the same time to set up multiple 
environments where 
different versions are tested independently.

There is as well the totally independent scenario where the app ships exactly 
what it needs, but 
there are some ways in between where one can script an app and in doing so you 
might need packages 
that the app itself knew nothing about.

For another example have a look at JEP
https://github.com/ninia/jep/search?q=virtual&unscoped_q=virtual

This is a way to call python from Java: same problem above, people might want 
to run it in a virtual 
environment and the only way to do this now is to manually set up PYTHONHOME, 
but it is pretty weak 
and does not replicate exactly what happens with virtual environments (e.g. 
inherit system's 
site-packages).

Again, in Linux, JEP works out of the box with no need to tell it about virtual 
environments, 
Py_Initialise() finds it (if they are indeed present) with absolutely no extra 
configuration (no 
need to change PYTHONPATH).

Andrea

--

___
Python tracker 

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

[issue6686] xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes

[Tal Einat]

Tal Einat  added the comment:

See additional research and discussion in the comments of PR GH-9715.

Simply changing this to return a string rather than bytes would break backwards 
compatibility.

I certainly agree that this should have returned a string in the first place, 
especially since the Unicode decoding is otherwise completely abstracted away 
and the encoding used is not made available.

Our options:

1. Return a string starting with 3.8, document the change in What's New & fix 
the docs for older 3.x.
2. Continue returning bytes, update the docs for all 3.x that this returns 
bytes, and that there's no good way to know the proper encoding to use for 
decoding it.
3. As 2 above, but also expose the encoding used.

Since this appears to be rarely used and option 3 requires significantly more 
effort than the others, I am against it. 

Option 2 seems the safest, but I'd like to hear more from those more 
experienced with XML.

--
nosy: +Jonathan.Gossage, taleinat
versions: +Python 3.6, Python 3.7, Python 3.8 -Python 3.1

___
Python tracker 

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

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Got it. Thanks for the details and patience. I tested with less number of 
characters and it seems to work fine so using the encoding at the top is not a 
good way to test the original issue as you have mentioned. Then I searched 
around and found issue14811 with test. This seems to be a very similar issue 
and there is a patch to detect this scenario to throw SyntaxError that the line 
is longer than the internal buffer instead of an encoding related error. I 
applied the patch to master and it throws an error about the internal buffer 
length as expected. But the patch was not applied and it seems Victor had 
another solution in mind as per msg167154. I tested with the patch as below : 

# master

➜  cpython git:(master) cat ../backups/bpo34979.py

s = 
'测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试'

print("str len : ", len(s))
print("bytes len : ", len(s.encode('utf-8')))
➜  cpython git:(master) ./python.exe ../backups/bpo34979.py
  File "../backups/bpo34979.py", line 2
SyntaxError: Non-UTF-8 code starting with '\xe8' in file ../backups/bpo34979.py 
on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ 
for details


# Applying the patch file from issue14811

➜  cpython git:(master) ✗ ./python.exe ../backups/bpo34979.py
  File "../backups/bpo34979.py", line 2
SyntaxError: Line 2 of file ../backups/bpo34979.py is longer than the internal 
buffer (1024)

# Patch on master

diff --git a/Parser/tokenizer.c b/Parser/tokenizer.c
index fc75bae537..48b3ac0ee9 100644
--- a/Parser/tokenizer.c
+++ b/Parser/tokenizer.c
@@ -586,6 +586,7 @@ static char *
 decoding_fgets(char *s, int size, struct tok_state *tok)
 {
 char *line = NULL;
+size_t len;
 int badchar = 0;
 for (;;) {
 if (tok->decoding_state == STATE_NORMAL) {
@@ -597,6 +598,15 @@ decoding_fgets(char *s, int size, struct tok_state *tok)
 /* We want a 'raw' read. */
 line = Py_UniversalNewlineFgets(s, size,
 tok->fp, NULL);
+   if (line != NULL) {
+len = strlen(line);
+if (1 < len && line[len-1] != '\n') {
+PyErr_Format(PyExc_SyntaxError,
+"Line %i of file %U is longer than the internal 
buffer (%i)",
+tok->lineno + 1, tok->filename, size);
+return error_ret(tok);
+}
+}
 break;
 } else {
 /* We have not yet determined the encoding.


If it's the same issue then I think closing this issue and discussing there 
will be good since the issue has a patch with test and relevant discussion. 
Also it seems BUFSIZ is platform dependent so adding your platform details 
would also help.

TIL about difference Python 2 and 3 on handling unicode related files. Thanks 
again!

--

___
Python tracker 

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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 7c1c42b3209f1d2546daab6cd77f953eb255df6c by Serhiy Storchaka in 
branch '3.6':
[3.6] bpo-34941: Fix searching Element subclasses. (GH-9766) (GH-9868)
https://github.com/python/cpython/commit/7c1c42b3209f1d2546daab6cd77f953eb255df6c


--

___
Python tracker 

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

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

[Lu jaymin]

Lu jaymin  added the comment:

If you declare the encoding at the top of the file, then everything is
fine, because in this case Python will use `io.open` to open the file and
use `stream.readline` to read one line of code, please see function
`fp_setreadl` in `cpython/Parser/tokenizer.c` for detail.

But if you did not declare the encoding, then Python will use
`Py_UniversalNewlineFgets` to read one line of raw bytes and check these
raw bytes's encoding by `valid_utf8`.

In my opinion, when the encoding of the file is utf-8, and because the
default file encoding of Python3 is utf-8, so whether we declare encoding
or did not is ok.

Karthikeyan Singaravelan  于2018年10月14日周日 下午1:06写道：

>
> Karthikeyan Singaravelan  added the comment:
>
> Thanks for the report. Is this a case of encoding not being declared at
> the top of the file or am I missing something?
>
> ➜  cpython git:(master) cat ../backups/bpo34979.py
> s =
> '测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试'
>
> print("str len : ", len(s))
> print("bytes len : ", len(s.encode('utf-8')))
> ➜  cpython git:(master) ./python.exe ../backups/bpo34979.py
>   File "../backups/bpo34979.py", line 1
> SyntaxError: Non-UTF-8 code starting with '\xe8' in file
> ../backups/bpo34979.py on line 1, but no encoding declared; see
> http://python.org/dev/peps/pep-0263/ for details
>
> # With encoding declared
>
> ➜  cpython git:(master) cat ../backups/bpo34979.py
> # -*- coding: utf-8 -*-
>
> s =
> '测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试'
>
> print("str len : ", len(s))
> print("bytes len : ", len(s.encode('utf-8')))
> ➜  cpython git:(master) ./python.exe ../backups/bpo34979.py
> str len :  340
> bytes len :  1020
>
> # Double the original string
>
> ➜  cpython git:(master) cat ../backups/bpo34979.py
> # -*- coding: utf-8 -*-
>
> s =
> '测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试'
>
> print("str len : ", len(s))
> print("bytes len : ", len(s.encode('utf-8')))
> ➜  cpython git:(master) ./python.exe ../backups/bpo34979.py
> str len :  680
> bytes len :  2040
>
>
> Thanks
>
> --
> nosy: +xtreak
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[miss-islington]

miss-islington  added the comment:


New changeset b1c800303e8458e00428ae66351ad492a503a46f by Miss Islington (bot) 
in branch '3.7':
bpo-34941: Fix searching Element subclasses. (GH-9766)
https://github.com/python/cpython/commit/b1c800303e8458e00428ae66351ad492a503a46f


--
nosy: +miss-islington

___
Python tracker 

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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +9236

___
Python tracker 

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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[miss-islington]

Change by miss-islington :


--
pull_requests: +9235

___
Python tracker 

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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset b11c5667f99c4f0018e3394c4d07c519d835671a by Serhiy Storchaka in 
branch 'master':
bpo-34941: Fix searching Element subclasses. (GH-9766)
https://github.com/python/cpython/commit/b11c5667f99c4f0018e3394c4d07c519d835671a


--

___
Python tracker 

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

[issue34980] KillPython target doesn't detect 64-bit processes

[Jeremy Kloth]

New submission from Jeremy Kloth :

Since the KillPython target has been rewritten as an InlineTask, it can no 
longer detect 64-bit processes due to MSBuild being 32-bit.

This leads to stuck buildbot runs:
  https://buildbot.python.org/all/#/builders/17/builds/348

A few solutions that I can think of:

1) Switch the InlineTask to an Exec using a PowerShell script to kill the 
processes.
   In my limited testing, PowerShell is installed by default on the supported 
OSes (Win7+).

   

2) When building for platform x64, modify find_msbuild.bat to locate the 64-bit 
MSBuild executable

3) On 64-bit OS, always use the 64-bit MSBuild executable

4) Only use the 64-bit MSBuild (when available) for the KillPython target (the 
64-bit KillPython target can detect 32-bit processes)

I am unsure of any issues that may arise from building with the 64-bit MSBuild 
toolchain.

--
components: Build, Windows
messages: 327694
nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: KillPython target doesn't detect 64-bit processes
versions: 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

[issue34968] loop.call_soon_threadsafe should be documented to be re-entrant-safe too

[Nathaniel Smith]

Nathaniel Smith  added the comment:

> What would make it not reentrant-safe?

Probably the most obvious example of a non-reentrant-safe operation is taking a 
lock. It's very natural to write code like:

def call_soon(...):
with self._call_soon_lock:
...

but now imagine that inside the body of that 'with' statement, a signal 
arrives, so the interpreter pauses what it's doing to invoke the signal 
handler, and the signal handler turns around and invokes call_soon, which tries 
to acquire the same lock that it already holds → instant deadlock.

And this rules out quite a few of the tools you might normally expect to use in 
thread-safe code, like queue.Queue, since they use locks internally.

The reason I think the stdlib's call_soon is OK is that it doesn't perform any 
blocking operations, and the critical operation is simply 
'self._ready.append(...)', which in CPython is atomic with respect to 
threads/signals/GC.

--

___
Python tracker 

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