[issue23105] os.O_SHLOCK and os.O_EXLOCK are not available on Linux

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

Which sentence with "Windows only" ?

Thanks

--

___
Python tracker 

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

[issue12946] PyModule_GetDict() claims it can never fail, but it can

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

you can merge the patch.

--
nosy: +matrixise

___
Python tracker 

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

[issue27701] [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present

[Ed Schouten]

New submission from Ed Schouten:

CloudABI is a sandboxed UNIX-like environment 
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html). As it 
implements a security framework similar to FreeBSD's Capsicum, file system 
access is only permitted by using POSIX-2008-style directory file descriptors. 
To explain it simply, the API is as follows:

- Take POSIX 2008
- Remove all the non-*at() functions
- Remove AT_FDCWD

It would be nice if Python could support CloudABI out of the box, but in my 
opinion this should be done in a way that's as unintrusive as possible. We 
shouldn't make a mess out of Python, just to support CloudABI. I've been 
looking at Python's posixmodule and I think there's some low-hanging fruit. We 
can make changes that significantly reduce the size of our patchset for 
CloudABI, while also making the existing code easier to understand:

- When support for *at() functions was added, they didn't replace the calls to 
the non-*at() functions. The non-*at() functions are still invoked when dir_fd 
== AT_FDCWD. This can be changed to invoke the *at() functions unconditionally. 
The advantage of this approach is that AT_FDCWD then only needs to be used in 
dir_fd_converter() and a small number of other places. It also means that the 
code builds on systems that don't prove the non-*at() functions.

- The *_DIR_FD_CONVERTER macros aren't used in a small number of places, 
requiring us to do additional checks against AT_FDCWD in os_*_impl(). In 
os.link(), os.rename() and os.replace(), we call into dir_fd_converter() 
unconditionally, only to let the respective implementation functions perform 
additional checks. If dir_fd_unavailable() would be used instead, the 
implementations would be cleaner.

The attached patch does this refactoring, also making some minor cleanups along 
the way.

--
components: Extension Modules
files: posixmodule-refactoring.diff
keywords: patch
messages: 272114
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [posixmodule] [Refactoring patch] Simply call into *at() functions 
unconditionally when present
versions: Python 3.6
Added file: http://bugs.python.org/file44033/posixmodule-refactoring.diff

___
Python tracker 

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

[issue27701] [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present

[Stéphane Wirtel]

Changes by Stéphane Wirtel :


--
nosy: +matrixise

___
Python tracker 

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

[issue10496] Python startup should not require passwd entry

[Yury V. Zaytsev]

Yury V. Zaytsev added the comment:

Another scenario how this could happen is when Python interpreter is run from a 
scheduled job on a BlueGene/Q node by the CNK; this is a minimalist execution 
environment where getpwuid() is unable to resolve home directories for UIDs 
running the jobs.

--

___
Python tracker 

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

[issue10496] Python startup should not require passwd entry

[Stéphane Wirtel]

Changes by Stéphane Wirtel :


--
versions: +Python 3.6 -Python 3.4

___
Python tracker 

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

[issue18049] Re-enable threading test on OSX

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

yes, maybe, could you provide a patch ?

--

___
Python tracker 

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

[issue27702] [Patch] Only use SOCK_RAW when defined

[Ed Schouten]

New submission from Ed Schouten:

POSIX only requires socket types SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET to 
be present. SOCK_RAW is optional, as it is placed between [RS] tags in the 
specification:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html

It looks like Python's socketmodule.c does try to use it unconditionally. 
Comply to POSIX by only exposing it optionally, just like we do for some of the 
other socket types (SOCK_RDM, etc).

--
components: Extension Modules
files: sock_raw.diff
keywords: patch
messages: 272117
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [Patch] Only use SOCK_RAW when defined
versions: Python 3.6
Added file: http://bugs.python.org/file44034/sock_raw.diff

___
Python tracker 

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

[issue27702] [Patch] Only use SOCK_RAW when defined

[Stéphane Wirtel]

Changes by Stéphane Wirtel :


--
nosy: +matrixise

___
Python tracker 

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

[issue23740] http.client request and send method have some datatype issues

[Martin Panter]

Martin Panter added the comment:

I’ve decided I would prefer deprecating the Latin-1 encoding, rather than 
adding more encoding support for iterables and text files. If not deprecating 
it altogether, at least prefer just ASCII encoding (like Python 2). The 
urlopen() function already rejects text str, and in Issue 26045 people often 
want or expect UTF-8.

Here is a summary I made of the different data types handled for the body 
object, from highest priority to lowest priority.

 HTTPConnection   HTTPConn. default
body _send_output()   Content-Length urlopen() 
===  ===  =  ==
None No body  0 or unset #23539  C-L unset 
Has read()   read() #1065257 * #5038   
- Text file  encode() #5314
str  encode() r56128  len()  TypeError #11082  
Byte seq.sendall()len()  C-L: nbytes   
Bytes-like   * #27340 *  C-L: nbytes #3243 
Iterable iter() #3243C-L required #3243
Sized len()† #23350
fstat()   st_size #1065257 
OtherwiseTypeErrorUnset #1065257 C-L optional† 

* Possible bugs
† Degenerate cases not worth supporting IMO
C-L = Content-Length header field, set by default or required to be specified 
in various cases
Byte seq. = Sequence of bytes, including “bytes” type, bytearray, array("B"), 
etc
Bytes-like = Any C-contiguous buffer, including zero- and multi-dimensional 
arrays, and with items other than bytes
Iterable = Iterable of bytes or bytes-like objects (depending on Issue 27340 
about SSL)

--

___
Python tracker 

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

[issue27703] Replace two Py_XDECREFs with Py_DECREFs in do_raise

[Xiang Zhang]

New submission from Xiang Zhang:

In do_raise, the two Py_XDECREFs at the final of the success branch seem doing 
unnecessary NULL checks.

--
components: Interpreter Core
files: do_raise.patch
keywords: patch
messages: 272119
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: Replace two Py_XDECREFs with Py_DECREFs in do_raise
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44035/do_raise.patch

___
Python tracker 

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

[issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured

[Florian Höch]

Florian Höch added the comment:

It seems this hasn't landed yet?

--

___
Python tracker 

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

[issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data

[Martin Panter]

Martin Panter added the comment:

Yes when I say “text” I mean str objects, as opposed to byte strings, etc.

I wonder if it would be safer to test for TextIOBase. With the read(0) hack, 
the zero size may be unexpected. A file object may need special handling to 
generate an empty result, or to not interpret it as an EOF indicator. See e.g. 
Issue 23804, about zero-sized SSL reads, where both of these problems happened. 
As long as we document that the text file logic has changed, I think it would 
be okay. IMO it is better to keep things simple and robust for byte files than 
add more hacks for text files.

A common base class like HTTPException is useful when a caller may need to 
handle a set of exceptions in a common way. But a problem with Content-Length 
or Transfer-Encoding seems like a programming error, so ValueError seems fine 
IMO.

However I still don’t see why the checks are worthwhile. Sure having both is a 
technical violation of the current HTTP protocols. But if a caller is likely to 
end up in one of these situations, it may indicate a problem with the API that 
we should fix instead. If the checks are unlikely to ever fail, then drop them. 
Otherwise, I don’t think any of the bugs I pointed out have been addressed.

I don’t like converting bytes-like to bytes. I understand one of the main 
purposes of accepting bytes-like objects is to avoid copying them, but 
converting to bytes defeats that. Also, the copying is inconsistent with the 
lack of copying in _read_iterable().

I am wondering if it would be best to keep new logic out of send(); just put it 
into _send_output() instead. Once upon a time, send() was a simple wrapper 
around socket.sendall() without much bloat. But with the current patch, in 
order to send a single buffer, we have to jump through a bunch of checks, 
create a dummy lambda and singleton tuple, loop over the singleton, call the 
lambda, realize there is no chunked encoding, etc. IMO the existing support for 
iterables should have been put in _send_output() too (when that was an option). 
There is no need to use send() to send the whole body when endheaders() already 
supports that.

--

___
Python tracker 

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

[issue26750] Mock autospec does not work with subclasses of property()

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue26750] Mock autospec does not work with subclasses of property()

[Roundup Robot]

Roundup Robot added the comment:

New changeset e947248100ae by Gregory P. Smith in branch '3.5':
Issue #26750: unittest.mock.create_autospec() now works properly
https://hg.python.org/cpython/rev/e947248100ae

New changeset 0bc14c91ef7e by Gregory P. Smith in branch 'default':
Issue #26750: unittest.mock.create_autospec() now works properly for
https://hg.python.org/cpython/rev/0bc14c91ef7e

--
nosy: +python-dev

___
Python tracker 

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

[issue26750] Mock autospec does not work with subclasses of property()

[Gregory P. Smith]

Changes by Gregory P. Smith :


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

___
Python tracker 

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

[issue10721] Remove HTTP 0.9 server support

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
nosy:  -gregory.p.smith

___
Python tracker 

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

[issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux

[Vinay Sajip]

Changes by Vinay Sajip :


Added file: http://bugs.python.org/file44036/refresh-2016-08-07.diff

___
Python tracker 

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

[issue23306] Within zipfile, use of zlib.crc32 raises OverflowError at argument-parsing time on large strings

[Gregory P. Smith]

Gregory P. Smith added the comment:

This appears to have been fixed by at least issue27130's 
https://hg.python.org/cpython/rev/2192edcfea02 recent commits.

greg:cpython/build27$ ./python -c "import zlib;zlib.crc32('a'*(1<<31))"
greg:cpython/build27$ ./python ../zipfile_2gb_test.py
True
greg:cpython/build27$ ls -al /tmp/zip_test.zip
-rw-rw-r-- 1 greg greg 2087407 Aug  7 09:28 /tmp/zip_test.zip
greg:~/sandbox/python/cpython/build27$ unzip -t /tmp/zip_test.zip
Archive:  /tmp/zip_test.zip
testing: big  OK
No errors detected in compressed data of /tmp/zip_test.zip.
greg:cpython/build27$ unzip -l /tmp/zip_test.zip
Archive:  /tmp/zip_test.zip
  Length  DateTimeName
-  -- -   
2147483648  2016-08-07 09:27   big
- ---
2147483648 1 file

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

[issue26750] Mock autospec does not work with subclasses of property()

[Berker Peksag]

Berker Peksag added the comment:

Thanks! Is there a reason not to use inspect.isdatadescriptor() instead of 
_is_data_descriptor()?

--
stage: commit review -> resolved

___
Python tracker 

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

[issue27664] Allow specifying prefix for thread name in concurrent.futures.ThreadPoolExecutor

[Gregory P. Smith]

Gregory P. Smith added the comment:

A workaround for this on 3.5 and older versions is probably to do:

initialization:

num_q = queue.Queue()
map(num_q.put, range(max_workers))

Then schedule max_workers identical tasks:

def task():
  threading.current_thread().name = '%s_%d' % (your_prefix, num_q.get())
  num_q.task_done()
  num_q.join()  # block so that this thread cannot take a new thread naming 
task until all other tasks are complete.  guaranteeing we are executed once per 
max_workers threads.

--

___
Python tracker 

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

[issue27664] Allow specifying prefix for thread name in concurrent.futures.ThreadPoolExecutor

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1002a1bdc5b1 by Gregory P. Smith in branch 'default':
Issue #27664: Add to concurrent.futures.thread.ThreadPoolExecutor()
https://hg.python.org/cpython/rev/1002a1bdc5b1

--
nosy: +python-dev

___
Python tracker 

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

[issue27664] Allow specifying prefix for thread name in concurrent.futures.ThreadPoolExecutor

[Gregory P. Smith]

Gregory P. Smith added the comment:

cleaned up a bit with documentation added and submitted.  thanks.  
ThreadPoolExecutor threads now have a default name as well, because why not.

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

___
Python tracker 

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

[issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0

[Christian Heimes]

Changes by Christian Heimes :


Removed file: 
http://bugs.python.org/file42526/0001-Port-Python-s-SSL-module-to-OpenSSL-1.1.0-WIP.patch

___
Python tracker 

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

[issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0

[Christian Heimes]

Changes by Christian Heimes :


Added file: 
http://bugs.python.org/file44037/Port-Python-2.7-s-SSL-module-to-OpenSSL-1.1.0.patch

___
Python tracker 

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

[issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0

[Christian Heimes]

Changes by Christian Heimes :


Added file: 
http://bugs.python.org/file44038/Port-Python-s-SSL-module-to-OpenSSL-1.1.0.patch

___
Python tracker 

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

[issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

Hi Christian,

I have reviewed your patch, seems to be fine for me.

--
nosy: +matrixise

___
Python tracker 

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

[issue27392] Add a server_side keyword parameter to create_connection

[Jim Fulton]

Jim Fulton added the comment:

FTR another use case for this. :)

We have a ZEO applications where individual database users authenticate via 
self-signed certs. The server's SSL connection has to have this collection of 
certs. User CRUD operations can add and remove certs to authenticate against.  
SSL contexts don't provide an API for removing (or even clearing) CAs used for 
authentication, so we need to create new SSL contexts when the set of valid 
certs change.  There's no way to update the SSL context used by a server, so 
we're wrapping accepted sockets ourselves, so we can use dynamic SSL contexts.

Some alternatives:

- Add an SSLContext API for removing or clearing CAs

- Add a Server API to update the SSL context used for new connections.  (I may 
pursue this at some point. I spent a few minutes trying to find where a 
Server's SSL context is stored, but failed and can't spend more time ATM.)

--

___
Python tracker 

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

[issue27704] bytes(x) is slow when x is bytearray

[INADA Naoki]

New submission from INADA Naoki:

When bytes(x), bytes_new checks if x is integer via PyNumber_AsSize_t(x).
It cause TypeError internally.

When x is not an integer, especially bytearray or memoryview, the internal
exception cause significant overhead.

# HEAD
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
100 loops, best of 3: 0.696 usec per loop
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
100 loops, best of 3: 0.699 usec per loop
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
100 loops, best of 3: 0.701 usec per loop

# this patch
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
100 loops, best of 3: 0.265 usec per loop
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
100 loops, best of 3: 0.265 usec per loop
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
100 loops, best of 3: 0.267 usec per loop

--
components: Interpreter Core
files: fast-bytearray-fromobject.patch
keywords: patch
messages: 272130
nosy: methane
priority: normal
severity: normal
status: open
title: bytes(x) is slow when x is bytearray
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44039/fast-bytearray-fromobject.patch

___
Python tracker 

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

[issue27704] bytes(x) is slow when x is bytearray

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

the patch seems to be fine.

--
nosy: +haypo, matrixise

___
Python tracker 

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

[issue27705] Updating old C:/Windows/System32/ucrtbased.dll

[Terry J. Reedy]

New submission from Terry J. Reedy:

This is a continuation of msg269741 from #26624, summarizing how to resolve 
this message.

 C:\WINDOWS\SYSTEM32\ucrtbased.dll is version 10.0.10240.16384
 WARN: ucrtbased contains known issues. Please update Visual Studio or the 
Windows SDK.  See: http://bugs.python.org/issue26624

F:\Python\dev\36\PCbuild\python.vcxproj(91,5): warning MSB3073: The command 
""F:\Python\dev\36\PCBuild\win32\python_d.exe" 
"F:\Python\dev\36\PC\validate_ucrtbase.py" ucrtbased" exited with code 1.

Merely updating Visual Studio is not enough.  One must update the Windows SDK 
either directly or while updating Visual Studio by making sure that the new SDK 
is requested under Features.

[X] Windows and Web Development
[X] Universal Windows App Development Tools
[X] Tools (1.4.1) and Windows 10 SDK (10.0.14393)

(Versions and even the menu may change in the future.)

The best way to update Visual Studio is probably to uninstall it first via  
Control Panel / Programs and Features / Microsoft Visual Studio Community 2015 
(or whichever version you have).

I did not.  After downloading the current installer
  vs_community__9c4d694197656e43997d069a0ead2003.exe
I just ran without uninstalling.  It automatically installs in the current 
vs2015 directory,  Instead of a clean install, it updated and ended with the 
same 'bad hash' message as reported in msg269741.

I then went to Programs and Features and chose 'Repair'.  The first time it 
failed because it did not like the existing 
  Microsoft Visual C++ 2015 Redistributable (x86 or x64)
files being present.  With those removed, and the SDK feature checked, Repair 
worked and Python builds without the warning.

The current SDK is not listed as 'Microsoft Windows SDK...' but as
  Windows Software Development Kit - Windows 10.0.14393

Steve: my suggestion is that "Please update Visual Studio or the Windows SDK." 
be changed to "Please update the Windows SDK, possibly by updating Visual 
Studio with the Windows SDK feature selected."  Also change the issue number 
from 26624 to whatever this one gets.

--
assignee: docs@python
components: Build, Documentation, Windows
messages: 272132
nosy: docs@python, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Updating old C:/Windows/System32/ucrtbased.dll
type: behavior
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue26624] Windows hangs in call to CRT setlocale()

[Terry J. Reedy]

Terry J. Reedy added the comment:

I updated ucrtbased.dll and resolved the warning as described in #27705.

--

___
Python tracker 

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

[issue27703] Replace two Py_XDECREFs with Py_DECREFs in do_raise

[Raymond Hettinger]

Raymond Hettinger added the comment:

Have you checked all the possibly code paths to be sure?   "Seems to be 
unnecessary" is insufficient reason for undoing Guido's code that has stood 
since 1997.   


Looking at the snarl of possible code paths, I not finding it obvious why some 
of the paths require Py_XDECREF and others don't.   Even if you are sure, then 
the patch needs to include assertions at key checkpoints (i.e. after a given 
assignment to "type" or "value" can we reliably assert the value is non-null) 
and/or comments showing what the reasoning is.  Otherwise, even if the patch 
happens to be correct, it increases the risk that future maintenance will 
introduce a bug when the current code would have allowed the maintenance in a 
safer context.

--
nosy: +rhettinger

___
Python tracker 

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

[issue27350] Compact and ordered dict

[Raymond Hettinger]

Raymond Hettinger added the comment:

You make need to ask for review help on python-dev.  Patches this big take a 
lot of time and energy to review.  Making pings into the blind doesn't help 
much (most of the patch reviewers are highly time constrained).

--

___
Python tracker 

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

[issue23105] os.O_SHLOCK and os.O_EXLOCK are not available on Linux

[Sworddragon]

Sworddragon added the comment:

Maybe it sounded a bit confusing but this text was not to be meant as a direct 
match against the documentation.

--

___
Python tracker 

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

[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization

[Glyph Lefkowitz]

New submission from Glyph Lefkowitz:

The purpose of 'seeding' a random number generator is usually to supply a 
deterministic sequence of values starting from a known point.  This works fine 
if you seed random.Random with an integer.  Often (for example, see Minecraft's 
map generation interface) one wants to begin with a human-memorable string as 
the seed, and superficially it would seem that passing a string to Random.seed 
would serve exactly this use-case.  In fact in its original incarnation it did.

However, since the introduction of PYTHONHASHSEED in 2.6.8, it's possible that 
strings now hash to different values, and on 3.2+, they'll _always_ hash to 
different values unless otherwise configured (which, as per the reason for 
introducing this feature in the first place, is a security flaw).

Right now the way to work around this is to get some deterministic hash from 
your string; one mechanism being a truncated SHA256 hash, for example, like 
this:

Random(struct.unpack("!I", sha256(seed.encode("utf-8")).digest()[:4])[0])

but this strikes me as an obscure trick to require of someone just trying to 
get their D&D character generator to produce the same values twice in a row for 
unit testing.

I'm not sure what the resolution should be, but I figured I should report this 
since I tripped over it.

--
components: Library (Lib)
messages: 272137
nosy: glyph
priority: normal
severity: normal
status: open
title: Random.seed, whose purpose is purportedly determinism, behaves 
non-deterministically with strings due to hash randomization
type: behavior

___
Python tracker 

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

[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue27128] Add _PyObject_FastCall()

[STINNER Victor]

STINNER Victor added the comment:

Rebased patch.

--
Added file: http://bugs.python.org/file44040/fastcall-2.patch

___
Python tracker 

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

[issue27128] Add _PyObject_FastCall()

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file44040/fastcall-2.patch

___
Python tracker 

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

[issue27128] Add _PyObject_FastCall()

[STINNER Victor]

Changes by STINNER Victor :


Added file: http://bugs.python.org/file44041/fastcall-2.patch

___
Python tracker 

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

[issue27128] Add _PyObject_FastCall()

[STINNER Victor]

STINNER Victor added the comment:

(Oops, I removed a broken fastcall-2.patch which didn't include new 
pystack.c/pystack.h files. It's now fixed in the new fastcall-2.patch.)

--

___
Python tracker 

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

[issue6422] timeit called from within Python should allow autoranging

[Steven D'Aprano]

Steven D'Aprano added the comment:

Nick gave a +1 to my auto-range patch with callback on 2016-05-13, and there's 
been no negative feedback since. Should I go ahead and check it in for 3.6?

--

___
Python tracker 

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

[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization

[Raymond Hettinger]

Raymond Hettinger added the comment:

Thanks for the bug report.  This is a case of something that used to work fine 
but was affected by an incidental change elsewhere.   

To support the use case for deterministic sequences of values starting from a 
known point, the docs promise, "If a new seeding method is added, then a 
backward compatible seeder will be offered. The generator’s random() method 
will continue to produce the same sequence when the compatible seeder is given 
the same seed." (See 
https://docs.python.org/3/library/random.html#notes-on-reproducibility )

The resolution is to have the random module (line 327 in 
Modules/_randommodule.c) use a new _PyObject_Hash() function that 
deterministically matches what the old PyObject_Hash() function used to do.

Marking this as "needs patch" and saving it for Nofar Schnider to work on 
(she's an aspiring core dev).

--
stage:  -> needs patch
versions: +Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

[issue6422] timeit called from within Python should allow autoranging

[Raymond Hettinger]

Raymond Hettinger added the comment:

I think the patch is good to go.

--

___
Python tracker 

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

[issue27703] Replace two Py_XDECREFs with Py_DECREFs in do_raise

[Xiang Zhang]

Xiang Zhang added the comment:

Thanks for your reply Raymond. You always provide thoughtful feedbacks, though 
it makes me somewhat more nervous. ;) (I am nervous about making noise here and 
waste others' time.)

> Have you checked all the possibly code paths to be sure?

Yes. I did check all the code paths. I don't want to be a noise maker so I did 
check it carefully.

>  "Seems to be unnecessary" is insufficient reason for undoing Guido's code 
> that has stood since 1997.

I use the word "seems" because even if I think my opinion is right, I am only 
99% sure. Just as you said, the code is legacy and changing it has to be 
careful. I can miss something and be wrong. But now I think I am right.

> Looking at the snarl of possible code paths, I not finding it obvious why 
> some of the paths require Py_XDECREF and others don't.

When we reach the two Py_XDECREFs, can type and value be NULL?

> then the patch needs to include assertions at key checkpoints (i.e. after a 
> given assignment to "type" or "value" can we reliably assert the value is 
> non-null) and/or comments showing what the reasoning is

Sorry, I didn't realize that. This is definitely good practice I know. But this 
is not documented and not a must then so I didn't do that. But I'll remember 
this in later patches.

--

___
Python tracker 

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

[issue27703] Replace two Py_XDECREFs with Py_DECREFs in do_raise

[Xiang Zhang]

Changes by Xiang Zhang :


Added file: http://bugs.python.org/file44042/do_raise_v2.patch

___
Python tracker 

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

[issue27350] Compact and ordered dict

[INADA Naoki]

INADA Naoki added the comment:

I see, and I'm sorry about that.

--

___
Python tracker 

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

[issue12276] 3.x ignores sys.tracebacklimit=0

[Stéphane Wirtel]

Changes by Stéphane Wirtel :


--
nosy: +matrixise

___
Python tracker 

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

[issue23746] sysconfg.is_python_build() is buggy

[Stéphane Wirtel]

Changes by Stéphane Wirtel :


--
nosy: +matrixise

___
Python tracker 

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

[issue24459] Mention PYTHONFAULTHANDLER in the man page

[Stéphane Wirtel]

Changes by Stéphane Wirtel :


--
nosy: +matrixise

___
Python tracker 

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

[issue27703] Replace two Py_XDECREFs with Py_DECREFs in do_raise

[Antti Haapala]

Antti Haapala added the comment:

Normally I wouldn't recommend changing working code. However those asserts 
would be OK; if either of them is NULL, then the previous if would have had 
undefined behaviour already. Thus the `XDECREF` wrongly signals that it'd be OK 
if they were NULLs until this point, which is not true.

I'd rather see more asserts in the code; would be a big aid in possible 
refactoring; now for example `PyErr_SetObject` checks twice and thrice if 
either of the arguments is NULL; would be nice to go see the call site and see 
asserts in place there, showing that the arguments never were NULL to begin 
with.

--
nosy: +ztane

___
Python tracker 

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

[issue6057] sqlite3 error classes should be documented

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

Hi Jaysinh,

I have reviewed your patch, but for me, this one should be have an order for 
the exception.

* Warning
* Error
  * DatabaseError
* ProgrammingError
* IntegrityError 

Thank you

--
nosy: +matrixise

___
Python tracker 

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

[issue6057] sqlite3 error classes should be documented

[Stéphane Wirtel]

Changes by Stéphane Wirtel :


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

[issue6057] sqlite3 error classes should be documented

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

Here is the patch with my comments.

--
Added file: http://bugs.python.org/file44043/issue6057-3.6.diff

___
Python tracker 

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

[issue27703] Replace two Py_XDECREFs with Py_DECREFs in do_raise

[Xiang Zhang]

Xiang Zhang added the comment:

Thanks for the comment, Antti.

>  would be nice to go see the call site and see asserts in place there, 
> showing that the arguments never were NULL to begin with.

So is it still not enough getting the two asserts? IMHO I think the two asserts 
have already meet your expectations since the cause block is impossible to make 
type or value NULL.

--

___
Python tracker 

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