date:20171227


Serhiy Storchaka  added the comment:

This file is a correct empty tar file. The tar utility accepts it too.

$ tar tf big_0_file_1.gz; echo $?
0

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue21288] hashlib.pbkdf2_hmac Hash Constructor


Christian Heimes  added the comment:

Do you have a proper solution that works within the limits of PEP 247? I could 
not, hence the existing API.

--

___
Python tracker 

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

[issue32435] tarfile recognizes .gz file as tar

2017-12-27 Thread Sergey Petrunin


New submission from Sergey Petrunin :

Library's function 'tarfile.is_tarfile' returns 'True' on GZip file (9.7 
megabytes see attachment), that is a file with 10 gigabytes of '0' character 
compressed with 'gzip' utility (no 'tar' whatsoever).

Desired result: this function should return False in this case, b.c. this file 
is not a tar file.

--
components: Library (Lib)
files: big_0_file_1.gz
messages: 309106
nosy: spetrunin
priority: normal
severity: normal
status: open
title: tarfile recognizes .gz file as tar
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file47353/big_0_file_1.gz

___
Python tracker 

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

[issue31639] http.server and SimpleHTTPServer hang after a few requests


Julien Palard  added the comment:

David you're right, I updated my patch, also added some documentation and a 
news entry.

Glenn I can't tell if my PR fixes your issue without an strace or a test. It 
fixes the one I straced (pre-opening sockets leading to Python reading 
indefinitly on a socket which may never be used). If you could try my PR I 
would appreciate it.

--

___
Python tracker 

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

[issue8800] add threading.RWLock

2017-12-27 Thread Jesús Cea Avión


Change by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue21288] hashlib.pbkdf2_hmac Hash Constructor

2017-12-27 Thread Armin Ronacher


Armin Ronacher  added the comment:

Yes, I'm definitely still interested in this. I still carry this hack around.

--
status: pending -> open

___
Python tracker 

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

[issue17258] multiprocessing.connection challenge implicitly uses MD5


Christian Heimes  added the comment:

Dave, are you still interested to address the issue?

I think it's a good idea to replace HMAC-MD5 in the long run. But instead of 
hard-coding another hash algorithm, I would like to see an improved handshake 
protocol that supports flexible authentication algorithms. You could send an 
algorithm indicator (e.g. HMAC_SHA256) in the request.

It would be really cool to run multiprocessing protocol over TLS with support 
for SASL with SCRAM or EXTERNAL (TLS cert auth, AF_UNIX PEERCRED, GSSAPI)...

--
status: open -> pending
versions: +Python 3.7 -Python 3.4

___
Python tracker 

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

[issue32434] pathlib.WindowsPath.reslove(strict=False) returns absoulte path only if at least one component exists

2017-12-27 Thread Martin Liska


New submission from Martin Liska :

The documentation for pathlib.Path.resolve says: "Make the path absolute, 
resolving any symlinks."

On Windows, the behavior doesn't always match the first part of the statement.

Example:
On a system with an existing, but empty directory C:\Test.
Running the interpreter at C:\ resolve behaves like so:

>>> os.path.realpath(r'Test\file')
'C:\\Test\\file'
>>> WindowsPath(r'Test\file').resolve(strict=False)
WindowsPath('C:/Test/file')

When running the interpreter inside C:\Test it instead behaves in the following 
manner:

>>> os.path.realpath('file')
'C:\\Test\\file'
>>> WindowsPath('file').resolve(strict=False)
WindowsPath('file')

Resolving a path object specifying a non-existent relative path results in an 
identical (relative) path object.
This is also inconsistent with the behavior of os.path.realpath as demonstrated.

The root of the issue is in the pathlib._WindowsFlavour.resolve method at lines 
193, 199 and 201.
If at least one component of the path gets resolved at line 193 by the 
expression self._ext_to_normal(_getfinalpathname(s)), the path returned at line 
201 will be joined from the absolute, resolved part and the unresolved remained.
If none of the components get resolved then the path will be returned at line 
199 as passed into the function.

--
components: Library (Lib)
messages: 309102
nosy: mliska
priority: normal
severity: normal
status: open
title: pathlib.WindowsPath.reslove(strict=False) returns absoulte path only if 
at least one component exists
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

[issue21288] hashlib.pbkdf2_hmac Hash Constructor


Christian Heimes  added the comment:

Is anybody interested still to solve the problem? I don't see a viable way to 
solve the issue in a correct way (*). The hashlib API is not designed to 
provide sufficient information from a digestmod object. I don't want to include 
hacks like mapping _hashlib.openssl_sha256 function to SHA256 EVP_MD.

(*) correct means: don't call the function, always reuse the hasher's EVP_MD* 
context and never fall back to slow path silently.

--
status: open -> pending
versions: +Python 3.7 -Python 3.4

___
Python tracker 

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

[issue32416] Refactor and add new tests for the f_lineno setter


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

[issue32416] Refactor and add new tests for the f_lineno setter


Serhiy Storchaka  added the comment:


New changeset c60eca06adda4900e6b469d989e6082cda3a3004 by Serhiy Storchaka in 
branch '2.7':
[2.7] bpo-32416: Refactor tests for the f_lineno setter and add new tests. 
(GH-4991). (#5017)
https://github.com/python/cpython/commit/c60eca06adda4900e6b469d989e6082cda3a3004


--

___
Python tracker 

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

[issue32416] Refactor and add new tests for the f_lineno setter


Serhiy Storchaka  added the comment:


New changeset ea98eba3465fff2b191610cea253d43000c84b4a by Serhiy Storchaka in 
branch '3.6':
[3.6] bpo-32416: Refactor tests for the f_lineno setter and add new tests. 
(GH-4991). (#5016)
https://github.com/python/cpython/commit/ea98eba3465fff2b191610cea253d43000c84b4a


--

___
Python tracker 

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

[issue29504] blake2: compile error with -march=bdver2


Christian Heimes  added the comment:

The issue has been fixed on Nov 1st in PR 
https://github.com/python/cpython/pull/4173 (master) and 
https://github.com/python/cpython/pull/4214 (3.6.4).

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

[issue32433] Provide optimized HMAC digest


Change by Christian Heimes :


--
keywords: +patch
pull_requests: +4913

___
Python tracker 

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

[issue32431] Two bytes objects of zero length don't compare equal


Jonathan Underwood  added the comment:

Actually the commentary at the top of bytesobject.c for 
PyBytes_FromStringAndSize says:

"... If `str' is NULL then PyBytes_FromStringAndSize() will allocate `size+1' 
bytes (setting the last byte to the null terminating character)... "

So, perhaps that's as close to gospel as it gets - this does imply that bytes 
objects are expected to be null terminated. Why PyBytesAsString then adds an 
extra null terminator is a bit of a mystery.

Perhaps what's needed is some documentation clarifications:

1/ State early on that bytes objects are always expected to be null terminated.

2/ As such, the string pointer returned by PyBytes_AsString will point to a 
null terminated string - I think the current docs could be misinterpreted to 
suggest that _AsString *adds* an extra byte for the null, which it doesn't.

3/ Document that using Py_SIZE to reduce the length of a bytes object is 
dangerous, because the null terminator will be lost, and subsequent behaviour 
undefined.

4/ Document that the preferred way to resize is to use 
PyBytes_FromStringAndSize with a new size.

5/ Indicate clearly that _PyBytes_Resize is not a public interface and its use 
is discouraged in favour of PyBytes_FromStringAndSize

--

___
Python tracker 

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

[issue32433] Provide optimized HMAC digest


New submission from Christian Heimes :

hmac.HMAC's flexibility comes with a cost. To create the MAC of a message, it 
has to create between three and four hash instances (inner, outer, key for long 
keys, result), multiple bound method objects and other temporary objects. For 
short messages, memory allocation, object handling and GIL release/acquire 
operations dominate the performance.

I propose to provide a fast one-shot HMAC function: hmac.digest(key, msg, 
digstmod) -> bytes function. A PoC implementation based on OpenSSL's HMAC() 
function and a pure Python implementation as inlined HMAC showed promising 
performance improvements. The C implementation is 3 times faster.

Standard HMAC:
$ ./python -m timeit -n20 -s "import hmac" -- "hmac.HMAC(b'key', 
b'message', 'sha256').digest()"
20 loops, best of 5: 5.38 usec per loop

Optimized Python code:
$ ./python -m timeit -n 20 -s "import hmac; hmac._hashopenssl = None" -- 
"hmac.digest(b'key', b'message', 'sha256')"
20 loops, best of 5: 3.87 usec per loop

OpenSSL HMAC()
$ ./python -m timeit -n 20 -s "import hmac" -- "hmac.digest(b'key', 
b'message', 'sha256')"
20 loops, best of 5: 1.82 usec per loop

--
components: Extension Modules
messages: 309097
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: patch review
status: open
title: Provide optimized HMAC digest
type: performance
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

[issue32431] Two bytes objects of zero length don't compare equal

Jonathan Underwood added the comment:

Py_SIZE is actually precisely specified and documented[1] as it stands; I don't
think a change there is needed. The usage I outlined is in line with that
documentation, and many other uses of that macro in the cpython sources.

The documentation issues are, at least:

1. There is no documentation specifying that bytes objects should be null
terminated.

2. Nothing in the documentation of PyBytes_FromStringAndSize[2] specifies that
passing 0 as the size results in a singleton being returned. This is
undocumented behaviour, and it would seem fragile to rely on this.

But there are more implementation inconsistencies: the documentation for
PyBytes_AsString()[3] returns a buffer which is one byte longer than the length
of the object *in order to store a terminating null*, which implies that the
object need not itself have a terminating null. I could go on with other
examples, but this is very poorly defined behaviour.

Question: are bytes objects defined to be null terminated, or not?

Because if they're not defined to be null terminated, the fix I propose is
correct even if it doesn't solve the other 100 bugs lurking in the code.

[Aside: even if bytes objects are in fact defined to be null terminated, I
think the change proposed amounts to an optimization in any case.]

[1] https://docs.python.org/3/c-api/structures.html#c.Py_SIZE
[2]
https://docs.python.org/3/c-api/bytes.html?highlight=pybytes_fromstringandsize#c.PyBytes_FromStringAndSize
[3]
https://docs.python.org/3/c-api/bytes.html?highlight=pybytes_asstring#c.PyBytes_AsString

___
Python tracker

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

[issue31639] http.server and SimpleHTTPServer hang after a few requests

2017-12-27 Thread Glenn Linderman


Glenn Linderman  added the comment:

I tried the approach in the PR "externally" (when starting the server using a 
test program), and I couldn't get it to work. But my test case was probably 
different: I was using Chrome rather than Chromium, and while they both work 
for me for simple HTTP file access to localhost without threading, I had tried 
to set up a PWA with a service worker, and maybe that does something different, 
so I got the hang, applied the Threading.mixIn, and it still hung.  I don't 
know how to tell for sure if it is the same sort of hang, or something 
different, in the Windows environment.

--

___
Python tracker 

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

[issue32431] Two bytes objects of zero length don't compare equal

2017-12-27 Thread R. David Murray


R. David Murray  added the comment:

I think what Py_SIZE "means" depends on the object type in the general case, 
not just this one, so documenting that it is mucking with the internal 
representation is probably the way to go.

--

___
Python tracker 

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

[issue32432] [BUG] Python vs Macbook High Sierra 10.13.2

2017-12-27 Thread Felipe Filgueira Barral


New submission from Felipe Filgueira Barral :

When i open the IDLE and try include ' or " in any script, the python closes 
alone! Does anyone know what might be happening? I use mac, version high 
sierra...

Process: Python [1048]
Path: /Applications/Python 3.6/IDLE.app/Contents/MacOS/Python
Identifier: org.python.IDLE
Version: 3.6.4 (3.6.4)
Code Type: X86 (Native)
Parent Process: ??? [1]
Responsible: Python [1048]
User ID: 501

Date/Time: 2017-12-27 14:12:58.552 -0200
OS Version: Mac OS X 10.13.2 (17C88)
Report Version: 12
Anonymous UUID: 0681CD4F-4E3E-670B-B04B-6F062C271803

Time Awake Since Boot: 3800 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0001, 0x
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: exc handler [0]

Application Specific Information:
*** Terminating app due to uncaught exception 'NSRangeException', reason: 
'-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds'

Application Specific Backtrace 1:
0 CoreFoundation 0x93a5f0e2 __raiseError + 178
1 libobjc.A.dylib 0xa6aaa346 objc_exception_throw + 273
2 CoreFoundation 0x93a5f005 +[NSException raise:format:] + 101
3 CoreFoundation 0x9394de6d -[__NSCFString characterAtIndex:] + 93
4 Tk 0x9d5c486a TkpInitKeymapInfo + 609
5 Tk 0x9d5c0cb7 TkpRedirectKeyEvent + 1098
6 Tk 0x9d5ca1f6 Tk_MacOSXSetupTkNotifier + 744
7 Tcl 0x9d4ca37e Tcl_DoOneEvent + 269
8 _tkinter.cpython-36m-darwin.so 0x003ee679 _tkinter_tkapp_mainloop + 233
9 Python 0x0006c566 _PyCFunction_FastCallDict + 582
10 Python 0x000f5e75 call_function + 629
11 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
12 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367
13 Python 0x000f59f9 fast_function + 249
14 Python 0x000f5e50 call_function + 592
15 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
16 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367
17 Python 0x000f59f9 fast_function + 249
18 Python 0x000f5e50 call_function + 592
19 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
20 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367
21 Python 0x000f5383 PyEval_EvalCode + 115
22 Python 0x0013090e PyRun_FileExFlags + 206
23 Python 0x00130c39 PyRun_SimpleFileExFlags + 505
24 Python 0x0014b3fb Py_Main + 4139
25 Python 0x1e62 main + 498
26 Python 0x1c65 start + 53
27 ??? 0x0002 0x0 + 2

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x93a5f3e3 TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION + 3
1 com.apple.CoreFoundation 0x93a5f381 __raiseError + 849
2 libobjc.A.dylib 0xa6aaa346 objc_exception_throw + 273
3 com.apple.CoreFoundation 0x93a5f005 +[NSException raise:format:] + 101
4 com.apple.CoreFoundation 0x9394de6d -[__NSCFString characterAtIndex:] + 93
5 Tk 0x9d5c486a 0x9d518000 + 70
6 Tk 0x9d5c0cb7 0x9d518000 + 691383
7 Tk 0x9d5ca1f6 0x9d518000 + 729590
8 Tcl 0x9d4ca37e Tcl_DoOneEvent + 269
9 _tkinter.cpython-36m-darwin.so0x003ee679 _tkinter_tkapp_mainloop + 233
10 org.python.python 0x0006c566 _PyCFunction_FastCallDict + 582
11 org.python.python 0x000f5e75 call_function + 629
12 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
13 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367
14 org.python.python 0x000f59f9 fast_function + 249
15 org.python.python 0x000f5e50 call_function + 592
16 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
17 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367
18 org.python.python 0x000f59f9 fast_function + 249
19 org.python.python 0x000f5e50 call_function + 592
20 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241
21 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367
22 org.python.python 0x000f5383 PyEval_EvalCode + 115
23 org.python.python 0x0013090e PyRun_FileExFlags + 206
24 org.python.python 0x00130c39 PyRun_SimpleFileExFlags + 505
25 org.python.python 0x0014b3fb Py_Main + 4139
26 Python 0x1e62 main + 498
27 Python 0x1c65 start + 53

Thread 1:
0 libsystem_kernel.dylib 0xa76ad6ee __workq_kernreturn + 10
1 libsystem_pthread.dylib 0xa77dae70 _pthread_wqthread + 992
2 libsystem_pthread.dylib 0xa77daa6a start_wqthread + 34

Thread 2:
0 libsystem_kernel.dylib 0xa76ad6ee __workq_kernreturn + 10
1 libsystem_pthread.dylib 0xa77db090 _pthread_wqthread + 1536
2 libsystem_pthread.dylib 0xa77daa6a start_wqthread + 34

Thread 3:
0 libsystem_kernel.dylib 0xa76ad07e __select + 10
1 Tcl 0x9d4fa09e 0x9d454000 + 680094
2 libsystem_pthread.dylib 0xa77db50d _pthread_body + 347
3 libsystem_pthread.dylib 0xa77db3b2 _pthread_start + 357
4 libsystem_pthread.dylib 0xa77daa8e thread_start + 34

Thread 4:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0xa76a3742 mach_msg_trap + 10
1 libsystem_kernel.dylib 0xa76a2d7f mach_msg + 47
2 com.apple.CoreFoundation 0x9394d3b8

[issue32431] Two bytes objects of zero length don't compare equal


Serhiy Storchaka  added the comment:

Much C code implies that bytes are null terminated. For example bytes-to-number 
converters and most functions that accept bytes as file path. Changing just the 
compare logic will not help.

The documented way of changing the size of the bytes object is 
_PyBytes_Resize(). But since this is a private function the only way of 
resizing the bytes object using public functions is creating a new object with 
PyBytes_FromStringAndSize(). If the new size is 0, it will return a singleton, 
thus this is a fast and memory efficient way.

Using the Py_SIZE() macro with the bytes object is not even documented. We 
should either document this way with its caveats (for example misusing it can 
lead to inefficient use of memory), or admit that this is working with internal 
representation which we shouldn't encourage.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32431] Two bytes objects of zero length don't compare equal


Change by Jonathan Underwood :


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

___
Python tracker 

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

[issue32431] Two bytes objects of zero length don't compare equal


Jonathan Underwood  added the comment:

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

--

___
Python tracker 

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

[issue32424] Rename copy() to copy() in xml.etree.ElementTree.Element Python implementation

2017-12-27 Thread Gordon P. Hemsley


Gordon P. Hemsley  added the comment:

Ultimately, yeah, the Python version should probably define __deepcopy__ as 
well. But since this is just a rename of an existing method, I figure we can 
defer that to another time.

--

___
Python tracker 

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

[issue32431] Two bytes objects of zero length don't compare equal

2017-12-27 Thread R. David Murray


R. David Murray  added the comment:

My suspicion is that this behavior/code is left over from when the code was 
handling strings in python2, where strings were always null terminated and so 
the equal-bytes test would always pass.  I don't think this is appropriate for 
bytes objects, so I think the compare logic should be fixed.  But I don't deal 
with the C code much, so I'd like an opinion from a core dev who does.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue32424] Rename copy() to copy() in xml.etree.ElementTree.Element Python implementation

2017-12-27 Thread Gordon P. Hemsley


Change by Gordon P. Hemsley :


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

___
Python tracker 

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

[issue32431] Two bytes objects of zero length don't compare equal


New submission from Jonathan Underwood :

With the current logic in Objects/bytesobject.c in the function 
bytes_compare_eq it can be the case that zero length bytes object object 
created in an extension module like this:

val = PyBytes_FromStringAndSize (NULL, 20);
Py_SIZE(val) = 0;

won't compare equal to b'' because the memory is not initialized, so the first 
two bytes won't be equal. Nonetheless, the Python interpreter does return b'' 
for print(repr(val)), so this behaviour is very confusing. To get the correct 
behaviour, one would have to initialize the memory:

val = PyBytes_FromStringAndSize (NULL, 20);
c = PyBytes_AS_STRING (val);
c[0] = '\0';
Py_SIZE(val) = 0;

However, it would be more sensible to fix the logic in bytes_compare_eq in my 
opinion. That function should return true for two zero length bytes objects, 
irrespective of the memory contents.

--
components: Interpreter Core
messages: 309086
nosy: jonathanunderwood
priority: normal
severity: normal
status: open
title: Two bytes objects of zero length don't compare equal
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

[issue26746] struct.pack(): trailing padding bytes on x64

2017-12-27 Thread Stefan Krah


Change by Stefan Krah :


--
versions: +Python 3.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

[issue26746] struct.pack(): trailing padding bytes on x64

2017-12-27 Thread Stefan Krah


Stefan Krah  added the comment:

I have just worked on PEP-3118 ==> Datashape translation and I have
encountered many issues similar to the ones in the PR referenced by
Allan.

It seems to me that we should simplify the PEP-3118 struct syntax as much 
as possible in order to remove any ambiguities.


I think generally that numpy's approach is the best for data interchange, so I
would propose this modified struct syntax for PEP-3118:


1) Padding is always explicit and exact, also for natively aligned types.

2) Padding is only allowed in struct fields.

3) Trailing padding is explicit.

4) If no padding is present in a struct, it is assumed to be packed with
alignment 1 for the entire struct.

5) The tuple syntax "bxL" is not supported, only the T{} syntax with
explicit field names.

6) Repetition "10s" is only allowed for bytes. "10f" is a tuple (not
supported), an array of 10 floats would be (10)f.

7) Modifiers (@, =, <, >, !) are only given for primitive data types,
not for entire structs or types.

8) Implementations are free to reject any padding that would not arise
naturally by specifying alignment or packing constraints (like gcc does 
with attributes).


Here is my implementation with a grammar:

  https://github.com/plures/ndtypes/blob/master/libndtypes/compat/bpgrammar.y

Some tests against numpy:

  https://github.com/plures/xnd/blob/master/python/test_xnd.py#L1509


I think the best way forward would be to tweak the above grammar so that
it covers everything that numpy can export.

--

___
Python tracker 

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

[issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6

2017-12-27 Thread Jerome Leclanche


Jerome Leclanche  added the comment:

Anything holding up the PR? Looks good at a glance, would be nice to get this 
landed in time for 3.7.

--
nosy: +jleclanche

___
Python tracker 

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

[issue31639] http.server and SimpleHTTPServer hang after a few requests

2017-12-27 Thread R. David Murray


R. David Murray  added the comment:

I don't think the PR as it stands is a good idea.  These classes are designed 
to be composable, so it should be up to the library user whether or not to use 
threads.  However it would be perfectly reasonable to choose to use threads in 
the 'test' function and thus the cli.  Which fact should then be documented, 
and chromium can even be mentioned as one of the motivations for using threads 
in the cli server.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue31639] http.server and SimpleHTTPServer hang after a few requests


Julien Palard  added the comment:

I wrote a 2 lines PR in which I propose to use threads to handle connections as 
it's well supported by socketserver via a ThreadingMixIn and fixes the issue.

--

___
Python tracker 

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

[issue31639] http.server and SimpleHTTPServer hang after a few requests


Change by Julien Palard :


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

___
Python tracker 

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

[issue12178] csv writer doesn't escape escapechar

2017-12-27 Thread Dmitriy Shashkin


Change by Dmitriy Shashkin :


--
nosy: +Dmitriy Shashkin

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}

2017-12-27 Thread Antoine Pitrou


Antoine Pitrou  added the comment:

> Personally I'll go for a single Setup file (No .dist, no .local, no copy), 
> that one can modify and commit, delegating the pain of merging to git, as I 
> prefer simple solutions.

+1 for this.

--
nosy: +barry, pitrou
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

[issue32430] Simplify Modules/Setup{,.dist,.local}


New submission from Julien Palard :

Related to: https://bugs.python.org/issue32429 

The bahavior of Modules/Setup{,.dist,.local} looks inherited from an old time:

- A Setup.dist exist
- ./configure copies it to Setup (cp $srcdir/Modules/Setup.dist Modules/Setup)
- ./configure installs a dummy Modules/Setup.local file
- One can add an optional things to Setup.local
- One can have to modify Setup itself (to modify things)

>From this point in time, Setup is newer than Setup.dist (as copied from it), 
>the following can happen:

- The Setup file is manually modified, it's still newer than Setup.dist, it 
does not change the situation
- The Setup.dist file gets updated (via a git checkout or git merge), the 
Makefile detects it and warn the user:
  - Either the user modified the Setup file and don't want it to be overridden
  - Either the user didn't modified it and just want the updated version

We don't know, so the Makefile is printing a warning telling he don't know and 
we have to fix the situation. First problem is: this warning is invisible due 
to the high load of Makefile prints, this is the issue 
https://bugs.python.org/issue32429.

Proposed solutions are:

- Xavier de Gaye: Use Setup.dist instead of Setup when Setup is missing 
(https://bugs.python.org/issue32429#msg309078)
- Just keep a single versionned Setup file, let those who modify it use 
branches to commit their modifications

Marc-Andre Lemburg noted that for those using a sources tarballs, in the single 
Setup file case, it's not nice for them to loose the original content of Setup 
when modifying it, and being able to do a `cp Modules/Setup.dist Modules/Setup` 
to restore it is nice.

Personally I'll go for a single Setup file (No .dist, no .local, no copy), that 
one can modify and commit, delegating the pain of merging to git, as I prefer 
simple solutions.

I don't think the importance of keeping a ".dist" backup is worth the pain and 
we're not doing it for other files (If one using a source tarball is modifying 
a .c file, the original content is lost too, and we'll not provide .c.dist 
files).

--
messages: 309079
nosy: mdk
priority: normal
severity: normal
status: open
title: Simplify Modules/Setup{,.dist,.local}

___
Python tracker 

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

[issue32429] Outdated Modules/Setup warning is invisible


Julien Palard  added the comment:

Discussion about further simplifications goes here: 
https://bugs.python.org/issue32430

--

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}


Change by Julien Palard :


--
components: +Build
versions: +Python 2.7, 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

[issue32429] Outdated Modules/Setup warning is invisible

2017-12-27 Thread Xavier de Gaye


Xavier de Gaye  added the comment:

It seems that it is possible to keep the current behavior for those that want 
to customize the configuration of Modules/Setup.dist (knowing that they can 
just use Modules/Setup.local if they are only doing additions to the Setup 
configuration) and at the same time get rid of these warnings for those that 
never change Modules/Setup.dist. This could be done this way:

* 'configure' does not create anymore Modules/Setup.
* The 'Makefile' target of the Makefile uses now Modules/Setup.dist when 
Modules/Setup is missing.
* A developer that wants to customize Modules/Setup.dist needs to copy (only 
once) manually Modules/Setup.dist to Modules/Setup and to modify this last file 
accordingly. She/he gets then the same warnings as those that are occuring 
currently and in that case it is useful to have the build abort upon such 
warnings as proposed in the current issue.

If this proposal is acceptable then it should be implemented in another issue, 
I think.

--

___
Python tracker 

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

[issue32416] Refactor and add new tests for the f_lineno setter


Change by Serhiy Storchaka :


--
pull_requests: +4907

___
Python tracker 

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

Re: [issue32429] Outdated Modules/Setup warning is invisible

2017-12-27 Thread M.-A. Lemburg

On 27.12.2017 00:24, Antoine Pitrou wrote:
> 
> Antoine Pitrou  added the comment:
> 
>> +1 - do you have any thoughts on that?
> 
> I think the current scheme may have been useful at a time where DVCS didn't 
> exist.  You would maintain an unversioned copy of Modules/Setup.dist in your 
> work-tree.  Nowadays you can fork a github repo and maintain your own branch 
> with changes to a tracked file.  I don't think Modules/Setup deserves special 
> treatment compared to, say, setup.py or Makefile.pre.in.

The file is mostly meant for people using tar balls rather than
checkouts to give them an easy way back to default settings
after making changes to the Modules/Setup file.

The same could be had by having Makefile.pre.in generate Setup.dist
from Setup while booting into build mode, avoiding the need to
sometimes create Modules/Setup manually.

-- 
Marc-Andre Lemburg
eGenix.com

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

[issue31639] http.server and SimpleHTTPServer hang after a few requests


Julien Palard  added the comment:

I straced both chromium and Python during the issue and seen this:

Chromium open a socket (port 55084), sends "GET /domain1.html" to it.
Python accepts it, reads "GET /domain1.html", replies, OK
Chromium closes socket on port 55084
Chromium opens three sockets:
  - port 55086
  - port 55088
  - port 55090
Python accepts a socket on port 55088 and read on it (blocking)
Chromium writes "GET /domain2.html" on socket on port 55090

At this point we're stuck, three socket are opened, Python is reading on one of 
them, Chromium is writing on another.

--
nosy: +mdk

___
Python tracker 

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

[issue32416] Refactor and add new tests for the f_lineno setter