[issue21415] Python __new__ method doc typo (it's a class and not a static method)

2014-05-03 Thread Jurko Gospodnetić

Jurko Gospodnetić added the comment:

Thanks for the detailed response! :-(

I should have tested more before reporting the issue.
Sorry for the noise. :-(

I saw the 'cls' argument and assumed it was a class
method. Having to explicitly specify cls did not
seem to be in contradiction with this since I assumed
__new__ is generally invoked on the class directly.

I still do not see why it had to be a static method
and has not been implemented as a class method, but I
guess I'll better ask that kind of a question on the
python user's newsgroup. :-)

Just in case it can help someone else, here's some
sample code what convinced me __new__ was indeed
implemented as a static method:

> class X:
> pass
> X.__new__()   # TypeError: object.__new__(): not enough arguments
> X.__new__(X)  # creates a new X instance
> x = X()
> x.__new__()   # TypeError: object.__new__(): not enough arguments
> x.__new__(X)  # creates a new X instance

If __new__ had been a class method then calling
'x.__new__()' would have worked as well.

Thanks again for the replies!

Best regards,
  Jurko Gospodnetić

--

___
Python tracker 

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



[issue21420] Optimize 2 ** n: implement it as 1 << n

2014-05-03 Thread Stefan Behnel

Stefan Behnel added the comment:

LGTM, can't see a case where this might go wrong (errors and type checks are 
handled before the added code).

It also seems a sufficiently common case to optimise it internally. The 2**n 
spelling is easier to read and to get right than the shifting, so it's good to 
make both similarly fast to remove an excuse for micro optimisations in Python 
code.

--
nosy: +scoder

___
Python tracker 

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



[issue20544] Use specific asserts in operator tests

2014-05-03 Thread Andrew Svetlov

Andrew Svetlov added the comment:

Ok. I agree with Teddy but Raymond's arguments make a value also.
Thus we need to make any decision and close the issue (and bunch of
similar issues).

On Sat, May 3, 2014 at 8:38 AM, Terry J. Reedy  wrote:
>
> Terry J. Reedy added the comment:
>
> The generic error message for the first is 'False is not true'. Clear but 
> useless. The error message for the second is the more specific 
> ' is not None'. Since the expression was supposed 
> to evaluate to None, but did not, it would be helpful to me, at least, to 
> know what it did evaluate to.
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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



[issue21422] int << 0: return the number unmodified

2014-05-03 Thread STINNER Victor

New submission from STINNER Victor:

I propose to add a micro-optimization for int << 0: return the number 
unmodified.

See attached patch.

--
files: long_lshift0.patch
keywords: patch
messages: 217822
nosy: haypo, mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: int << 0: return the number unmodified
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file35144/long_lshift0.patch

___
Python tracker 

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



[issue21420] Optimize 2 ** n: implement it as 1 << n

2014-05-03 Thread STINNER Victor

STINNER Victor added the comment:

pow2_specialized.patch: here is a different approach, a little bit faster. I 
wrote a dedicated long_pow2() function which computes 2**k.

Arguments in favor of pow2_specialized.patch instead of pow2.patch:

- it's a little bit faster
- don't touch long_lshift(), so there is no risk of performance regression
- it becomes easier to implement #21419 optimization: use calloc() instead of 
malloc() for very large power of 2, to avoid allocating physical memory pages 
for zeros

Results of bench_pow2.py comparing original Python, pow2.pathc and 
pow2_specialized.patch:

Common platform:
Platform: Linux-3.13.9-200.fc20.x86_64-x86_64-with-fedora-20-Heisenbug
Timer info: namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, 
resolution=1e-09)
Python unicode implementation: PEP 393
Bits: int=32, long=64, long long=64, size_t=64, void*=64
Timer: time.perf_counter
CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g 
-fwrapv -O3 -Wall -Wstrict-prototypes

Platform of campaign orig:
SCM: hg revision=62438d1b11c7 tag=tip branch=default date="2014-05-02 23:26 
+0200"
Date: 2014-05-03 14:42:56
Timer precision: 46 ns
Python version: 3.5.0a0 (default:62438d1b11c7, May 3 2014, 14:41:50) [GCC 4.8.2 
20131212 (Red Hat 4.8.2-7)]

Platform of campaign pow2:
SCM: hg revision=62438d1b11c7+ tag=tip branch=default date="2014-05-02 23:26 
+0200"
Python version: 3.5.0a0 (default:62438d1b11c7+, May 3 2014, 14:41:13) [GCC 
4.8.2 20131212 (Red Hat 4.8.2-7)]
Date: 2014-05-03 14:41:21
Timer precision: 51 ns

Platform of campaign pow2_specialized:
SCM: hg revision=62438d1b11c7+ tag=tip branch=default date="2014-05-02 23:26 
+0200"
Date: 2014-05-03 14:40:26
Python version: 3.5.0a0 (default:62438d1b11c7+, May 3 2014, 14:40:18) [GCC 
4.8.2 20131212 (Red Hat 4.8.2-7)]
Timer precision: 46 ns

---++--+-
Tests  |   orig | pow2 | pow2_specialized
---++--+-
2 ** 0 |  39 ns (*) | 44 ns (+11%) |    41 ns
2 ** 1 | 264 ns (+531%) | 62 ns (+48%) |    42 ns (*)
2 ** 3 | 269 ns (+554%) | 62 ns (+50%) |    41 ns (*)
2 ** 5 | 269 ns (+560%) | 62 ns (+51%) |    41 ns (*)
2 ** 10    | 279 ns (+410%) | 63 ns (+15%) |    55 ns (*)
2 ** 15    | 299 ns (+460%) | 62 ns (+16%) |    53 ns (*)
2 ** 20    | 287 ns (+426%) | 62 ns (+14%) |    55 ns (*)
2 ** 25    | 302 ns (+466%) | 62 ns (+16%) |    53 ns (*)
2 ** 28    | 293 ns (+438%) | 62 ns (+14%) |    55 ns (*)
2 ** (2 ** 0)  | 264 ns (+549%) | 62 ns (+52%) |    41 ns (*)
2 ** (2 ** 1)  | 264 ns (+524%) | 62 ns (+48%) |    42 ns (*)
2 ** (2 ** 3)  | 263 ns (+548%) | 62 ns (+52%) |    41 ns (*)
2 ** (2 ** 5)  | 283 ns (+346%) |  68 ns (+8%) |    63 ns (*)
2 ** (2 ** 10) | 715 ns (+950%) |    68 ns (*) |    69 ns
2 ** (2 ** 15) |  89.6 us (+51109%) |   175 ns (*) |   177 ns
2 ** (2 ** 20) | 3.89 ms (+100603%) |  3.86 us (*) |  3.86 us
2 ** (2 ** 25) |   152 ms (+66557%) | 240 us (+5%) |   228 us (*)
2 ** (2 ** 28) | 1.35 sec (+33851%) |  3.99 ms (*) |  3.99 ms
---++--+-
Total  | 1.51 sec (+35664%) |  4.23 ms |  4.22 ms (*)
---++--+-

--
Added file: http://bugs.python.org/file35145/pow2_specialized.patch

___
Python tracker 

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



[issue20866] segfailt with os.popen and SIGPIPE

2014-05-03 Thread STINNER Victor

STINNER Victor added the comment:

I can reproduce the crash. It occurs at the line "fd.write(data)". It looks 
like the crash occurs in the C function fwrite() which doesn't handle EPIPE / 
SIGPIPE correctly.

Top of the gdb traceback:

#0  0x0033d0a8968b in __mempcpy_sse2 () from /lib64/libc.so.6
#1  0x0033d0a79339 in __GI__IO_default_xsputn () from /lib64/libc.so.6
#2  0x0033d0a77362 in __GI__IO_file_xsputn () from /lib64/libc.so.6
#3  0x0033d0a6cfad in fwrite () from /lib64/libc.so.6
#4  0x00435cc4 in file_write (f=0x7f46d74a2dc0, 
args=('0123456789\n0123456789\n0123456789\n...(truncated))
at Objects/fileobject.c:1852

Last syscalls (strace output):

...
pipe2([3, 4], O_CLOEXEC)= 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f5ce26aca10) = 4711
close(3)= 0
fcntl(4, F_SETFD, 0)= 0
fstat(4, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fstat(4, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f5ce26ca000
write(4, "0123456789\n0123456789\n0123456789"..., 1097728) = 98304
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=4710, si_uid=1000} ---
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4711, si_status=0, 
si_utime=0, si_stime=0} ---
write(4, "89\n0123456789\n0123456789\n0123456"..., 999424) = -1 EPIPE (Broken 
pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=4710, si_uid=1000} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7f5cdbe87000} ---
+++ killed by SIGSEGV (core dumped) +++

--
nosy: +haypo, neologix

___
Python tracker 

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



[issue14019] Unify tests for str.format and string.Formatter

2014-05-03 Thread Brett Cannon

Changes by Brett Cannon :


--
assignee:  -> brett.cannon
nosy: +brett.cannon

___
Python tracker 

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



[issue21352] improve documentation indexing

2014-05-03 Thread Tshepang Lekhonkhobe

Changes by Tshepang Lekhonkhobe :


--
nosy: +tshepang

___
Python tracker 

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



[issue18564] Integer overflow in socketmodule

2014-05-03 Thread Michele Orrù

Changes by Michele Orrù :


Added file: http://bugs.python.org/file35146/issue18564.3.patch

___
Python tracker 

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



[issue18564] Integer overflow in socketmodule

2014-05-03 Thread Michele Orrù

Michele Orrù added the comment:

Interestingly,  implements a function for parsing 
bluetooth addresses, but it's completely broken.
 
It would be much much more elegant to use str2ba() in our source code though.

I am thinking about patching it there and then open another ticket here in 
order to adopt str2ba(). This way we can close this ticket for now.
Does this sound reasonable to you, Antoine?

--

___
Python tracker 

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



[issue21233] Add *Calloc functions to CPython memory allocation API

2014-05-03 Thread Stefan Krah

Stefan Krah added the comment:

I did a post-commit review.  A couple of things:


1) I think Victor and I have a different view of the calloc() parameters.

  calloc(size_t nmemb, size_t size)

   If a memory region of bytes is allocated, IMO 'nbytes' should be in the
   place of 'nmemb' and '1' should be in the place of 'size'. That is,
   "allocate nbytes elements of size 1":

  calloc(nbytes, 1)


   In the commit the parameters are reversed in many places, which confuses
   me quite a bit, since it means "allocate one element of size nbytes".

  calloc(1, nbytes)


2) I'm not happy with the refactoring in bytearray_init(). I think it would
   be safer to make focused minimal changes in PyByteArray_Resize() instead.
   In fact, there is a behavior change which isn't correct:

Before:
===
>>> x = bytearray(0)
>>> m = memoryview(x)
>>> x.__init__(10)
Traceback (most recent call last):
  File "", line 1, in 
BufferError: Existing exports of data: object cannot be re-sized

 Now:
 
>>> x = bytearray(0)
>>> m = memoryview(x)
>>> x.__init__(10)
>>> x[0]
0
>>> m[0]
Traceback (most recent call last):
  File "", line 1, in 
IndexError: index out of bounds

3) Somewhat similarly, I wonder if it was necessary to refactor
   PyBytes_FromStringAndSize(). I find the new version more difficult
   to understand.


4) _PyObject_Alloc(): assert(nelem <= PY_SSIZE_T_MAX / elsize) can be called
   with elsize = 0.

--

___
Python tracker 

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



[issue20866] segfailt with os.popen and SIGPIPE

2014-05-03 Thread Charles-François Natali

Charles-François Natali added the comment:

> I can reproduce the crash. It occurs at the line "fd.write(data)". It looks 
> like the crash occurs in the C function fwrite() which doesn't handle EPIPE / 
> SIGPIPE correctly.

Wouldn't be the first time.

Note that in Python 3, we don't fopen/fwrite anymore, so Python 3
isn't affected.

I suggest closing as "won't fix".

--

___
Python tracker 

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



[issue20866] segfailt with os.popen and SIGPIPE

2014-05-03 Thread Terry J. Reedy

Terry J. Reedy added the comment:

I was thinking the same thing. This appears to be one of the 2.x bugs that have 
been fixed in 3.x but not 2.x because backporting the fix might break working 
code. If there another sensible fix that would be acceptable in 2.x?

--

___
Python tracker 

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



[issue21233] Add *Calloc functions to CPython memory allocation API

2014-05-03 Thread Stefan Krah

Stefan Krah added the comment:

I forgot one thing:

5) If WITH_VALGRIND is defined, nbytes is uninitialized in _PyObject_Alloc().

--

___
Python tracker 

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



[issue20866] segfailt with os.popen and SIGPIPE

2014-05-03 Thread Charles-François Natali

Charles-François Natali added the comment:

It's segfaulting inside fwrite(), so apart from completely rewriting
the IO layer in 2.x, I don't see.

--

___
Python tracker 

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



[issue21233] Add *Calloc functions to CPython memory allocation API

2014-05-03 Thread Stefan Krah

Stefan Krah added the comment:

Another thing:

6) We need some kind of prominent documentation that existing
   programs need to be changed:

Python 3.5.0a0 (default:62438d1b11c7+, May  3 2014, 23:35:03) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import failmalloc
>>> failmalloc.enable()
>>> bytes(1)
Segmentation fault (core dumped)

--

___
Python tracker 

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



[issue21233] Add *Calloc functions to CPython memory allocation API

2014-05-03 Thread Nathaniel Smith

Nathaniel Smith added the comment:

A simple solution would be to change the name of the struct, so that 
non-updated libraries will get a compile error instead of a runtime crash.

--

___
Python tracker 

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



[issue20215] Python2.7 socketserver can not listen IPv6 address

2014-05-03 Thread Andreas Røsdal

Andreas Røsdal added the comment:

Here's a patch which implements support in SocketServer to set IPv6 socket 
address family to AF_INET6 automatically if the TCPServer is specified to 
listen to an IPv6 address. This means that users of the TCPServer class will 
get the correct address family automatically for both IPv4 and IPv6 based on 
the IP address they specify, and hopefully this will be more userfriendly. The 
patch is against the latest Python 3.5.

Note that this is my first patch to the Python project, I hope I did everything 
correct.

--
keywords: +patch
nosy: +andreasr
Added file: http://bugs.python.org/file35147/issue20215_socketserver.patch

___
Python tracker 

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



[issue21422] int << 0: return the number unmodified

2014-05-03 Thread Raymond Hettinger

Raymond Hettinger added the comment:

Every branch has a cost (in particular, it tends to contaminate global branch 
prediction tables and blow other code out of the L1 code cache).  The cost 
isn't big, but branches shouldn't be added unless we know there is a real 
benefit.

I would think that in real-world code, this branch will almost never be taken.  
The common case will pay a price (albiet a small one) for almost zero benefit.

--
nosy: +rhettinger

___
Python tracker 

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



[issue21375] Fix and test overflow behavior in the C version of heapq

2014-05-03 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 725cb631699a by Raymond Hettinger in branch '3.4':
Issue 21375:  Fix possible Py_ssizet overflow in heapq.
http://hg.python.org/cpython/rev/725cb631699a

--
nosy: +python-dev

___
Python tracker 

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



[issue21375] Fix and test overflow behavior in the C version of heapq

2014-05-03 Thread Roundup Robot

Roundup Robot added the comment:

New changeset b768d41dec0a by Raymond Hettinger in branch '2.7':
Issue 21375:  Fix possible Py_ssizet overflow in heapq.
http://hg.python.org/cpython/rev/b768d41dec0a

--

___
Python tracker 

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



[issue21422] int << 0: return the number unmodified

2014-05-03 Thread STINNER Victor

STINNER Victor added the comment:

> I would think that in real-world code, this branch will almost never be
taken.  The common case will pay a price (albiet a small one) for almost
zero benefit.

I think that x << 0 is common even if it's not written like that (it's more
for i in range(8): ... x << i).

The benefit is to reduce the memory footprint.

Can you sow the overhead of the branch in a microbenchmark? The test is
only done once, it's out of a loop.

*If* it's possible to notice an overhead, we can maybe use GCC macro
unlikely().

--

___
Python tracker 

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



[issue21375] Fix and test overflow behavior in the C version of heapq

2014-05-03 Thread Raymond Hettinger

Changes by Raymond Hettinger :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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



[issue21233] Add *Calloc functions to CPython memory allocation API

2014-05-03 Thread STINNER Victor

STINNER Victor added the comment:

> 6) We need some kind of prominent documentation that existing
>programs need to be changed:

My final commit includes an addition to What's New in Python 3.5 doc,
including a notice in the porting section. It is not enough?

Even if the API is public, the PyMemAllocator thing is low level. It's not
part of the stable ABI. Except failmalloc, I don't know any user. I don't
expect a lot of complain and it's easy to port the code.

--

___
Python tracker 

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



[issue21233] Add *Calloc functions to CPython memory allocation API

2014-05-03 Thread STINNER Victor

STINNER Victor added the comment:

> 5) If WITH_VALGRIND is defined, nbytes is uninitialized in
_PyObject_Alloc().

Did you see my second commit? It's nlt already fixed?

--

___
Python tracker 

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



[issue21233] Add *Calloc functions to CPython memory allocation API

2014-05-03 Thread Stefan Krah

Stefan Krah added the comment:

> > 5) If WITH_VALGRIND is defined, nbytes is uninitialized in
> _PyObject_Alloc().
> 
> Did you see my second commit? It's nlt already fixed?

I don't think so, I have revision 5d076506b3f5 here.

--

___
Python tracker 

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



[issue21233] Add *Calloc functions to CPython memory allocation API

2014-05-03 Thread STINNER Victor

STINNER Victor added the comment:

>"allocate nbytes elements of size 1"

PyObject_Malloc(100) asks to allocate one object of 100 bytes.

For PyMem_Malloc() and PyMem_RawMalloc(), it's more difficult to guess, but
IMO it's sane to bet that a single memory block of size bytes is requested.

I consider that char data[100] is a object of 100 bytes, but you call it
100 object of 1 byte.

I don't think that using nelem or elsize matters in practice.

--

___
Python tracker 

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



[issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py

2014-05-03 Thread Ned Deily

Ned Deily added the comment:

I agree: issue21121-3.diff is a much better approach.

--

___
Python tracker 

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



[issue17338] Add length_hint parameter to list, dict, set constructors to allow efficient presizing

2014-05-03 Thread Raymond Hettinger

Raymond Hettinger added the comment:

Based on all the negative comments, I'm closing this one.  It adds too much 
complication in return for dubious value.

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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



[issue21233] Add *Calloc functions to CPython memory allocation API

2014-05-03 Thread Stefan Krah

Stefan Krah added the comment:

STINNER Victor  wrote:
> PyObject_Malloc(100) asks to allocate one object of 100 bytes.

Okay, then let's please call it:

_PyObject_Calloc(void *ctx, size_t nobjs, size_t objsize)

_PyObject_Alloc(int use_calloc, void *ctx, size_t nobjs, size_t objsize)

--

___
Python tracker 

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



[issue21101] Extend the PyDict C API to handle cases where the hash value is known

2014-05-03 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 39f475aa0163 by Raymond Hettinger in branch 'default':
Issue 21101:  Internal API for dict getitem and setitem where the hash value is 
known.
http://hg.python.org/cpython/rev/39f475aa0163

--
nosy: +python-dev

___
Python tracker 

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



[issue21423] concurrent.futures.ThreadPoolExecutor should accept an initializer argument

2014-05-03 Thread Andreas van Cranenburgh

New submission from Andreas van Cranenburgh:

It would be useful if concurrent.futures.ThreadPoolExecutor took an initializer 
argument, like multiprocessing.Pool.

This is useful for example to load a large dataset once upon initialization of 
each worker process, without have to pass the dataset as an argument with every 
job submission, which requires serialization.

concurrent.futures has some advantages over multiprocessing such as detecting 
killed processes ( http://bugs.python.org/issue9205 ), so it would be good if 
the advantages of both can be combined.

It appears that the following fork of concurrent.futures has added these 
arguments: 
https://github.com/enthought/encore/blob/7101984bc384da8e7975876ca2809cc0103c3efc/encore/concurrent/futures/enhanced_thread_pool_executor.py

--
components: Library (Lib)
messages: 217846
nosy: andreasvc
priority: normal
severity: normal
status: open
title: concurrent.futures.ThreadPoolExecutor should accept an initializer 
argument
versions: Python 3.5

___
Python tracker 

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



[issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py

2014-05-03 Thread Larry Hastings

Larry Hastings added the comment:

If you guys want this in 3.4.1, please get it checked in in the next, oh, eight 
hours.

--

___
Python tracker 

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



[issue21101] Extend the PyDict C API to handle cases where the hash value is known

2014-05-03 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 592a57682ced by Raymond Hettinger in branch 'default':
Issue #21101:  Eliminate double hashing in the C code for collections.Counter().
http://hg.python.org/cpython/rev/592a57682ced

--

___
Python tracker 

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



[issue21101] Extend the PyDict C API to handle cases where the hash value is known

2014-05-03 Thread Raymond Hettinger

Changes by Raymond Hettinger :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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



[issue21357] Increase filecmp test coverage from 63% to 76%

2014-05-03 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 57dacba9febf by Benjamin Peterson in branch '3.4':
improve test coverage of filecmp (closes #21357)
http://hg.python.org/cpython/rev/57dacba9febf

New changeset c597654a7fd8 by Benjamin Peterson in branch 'default':
merge 3.4 (#21357)
http://hg.python.org/cpython/rev/c597654a7fd8

--
nosy: +python-dev
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



[issue20642] Enhance deepcopy-ing for tuples

2014-05-03 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 0df3004581fe by Benjamin Peterson in branch 'default':
improve idioms (closes #20642)
http://hg.python.org/cpython/rev/0df3004581fe

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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



[issue20642] Enhance deepcopy-ing for tuples

2014-05-03 Thread Raymond Hettinger

Raymond Hettinger added the comment:

This was a nice patch.
Thanks.

--
nosy: +rhettinger

___
Python tracker 

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



[issue21421] ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__

2014-05-03 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 2c6a231e2c1e by Raymond Hettinger in branch 'default':
Issue #21421:  Add __slots__ to the MappingViews ABCs.
http://hg.python.org/cpython/rev/2c6a231e2c1e

--
nosy: +python-dev

___
Python tracker 

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



[issue21421] ABCs for MappingViews should declare __slots__ so subclasses aren't forced to have __dict__/__weakref__

2014-05-03 Thread Raymond Hettinger

Raymond Hettinger added the comment:

I've applied the __slots__ patch.  Thank you for submitting it.

Am leaving the rest of the ABCs code as-is.  The current form may be a bit 
wordy but it is clean, fast, and easy to trace through a debugger.  The 
expanded forms were chosen for a reason.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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



[issue21414] Add an intersperse function to itertools

2014-05-03 Thread Raymond Hettinger

Raymond Hettinger added the comment:

I've looked into this a bit more.  Even in Haskell, it seems that use case is 
for str.join() which we already have.  I don't see intersperse() in any other 
functional languages.  That suggests that its use cases aren't sufficiently 
common to warrant adding it to the standard library.

Thank you for the submission.

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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



[issue18604] Consolidate gui available checks in test.support

2014-05-03 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 7ecb6e4b1077 by Ned Deily in branch '3.4':
Issue #18604: Skip the Tk instantiation test on OS X because it can
http://hg.python.org/cpython/rev/7ecb6e4b1077

New changeset 7f6d9990a9b1 by Ned Deily in branch 'default':
Issue #18604: merge from 3.4
http://hg.python.org/cpython/rev/7f6d9990a9b1

--

___
Python tracker 

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



[issue18604] Consolidate gui available checks in test.support

2014-05-03 Thread Ned Deily

Ned Deily added the comment:

For some reason, the newly-added Tk instantiation check causes the OS X Cocoa 
Tk to segfault when tests are run under regrtest -jn option, which causes each 
test to be run under a separate subprocess called from a separate thread.  
Somewhat surprisingly, the segfault doesn't seem to happen under the same 
conditions with 2.7, only with 3.4 and default, so there is something more at 
play here.  But with the imminent tagging of 3.4.1rc1, I think it is better to 
disable the check for 3.4 (and default) on OS X pending further investigation.  
The check is redundant: if Tk doesn't work for some reason, the individual test 
should fail anyway, just a bit later.

--
nosy: +ned.deily
status: closed -> open
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



[issue19414] iter(ordered_dict) yields keys not in dict in some circumstances

2014-05-03 Thread Roundup Robot

Roundup Robot added the comment:

New changeset a3c345ba3563 by Raymond Hettinger in branch 'default':
Issue #19414: Have the OrderedDict mark deleted links as unusable.
http://hg.python.org/cpython/rev/a3c345ba3563

--
nosy: +python-dev

___
Python tracker 

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



[issue19414] iter(ordered_dict) yields keys not in dict in some circumstances

2014-05-03 Thread Raymond Hettinger

Raymond Hettinger added the comment:

To address Armin's concern, I'm triggering an early failure by setting the link 
fields to None.  That will help prevent accidental reliance on non-guaranteed 
behaviors.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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



[issue21424] Simplify and speed-up heaqp.nlargest()

2014-05-03 Thread Raymond Hettinger

New submission from Raymond Hettinger:

Consolidate the logic for nlargest() into a single function.  Remove both the C 
and pure Python base underlying code. 

With all the logic in a single function, it only becomes necessary to create, 
store, and compare the data tuples when a need item is added to the heap.  This 
means that the rest of the comparisons (checking to see whether a new item 
needs to be added to the heap) can run faster and not need to create a (key, 
order, elem) tuple.

The change reduces the number of tuples created and the number of ordering 
integers created.

When rich comparisons were introduced, tuple ordering comparisons became twice 
as expensive (they are compared elementwise for equality and then there is an 
additional comparison call to order the first differing element).  Under the 
existing nlargest() code, we pay that price for every lement in the iterable.  
In the new code, we pay that price only for the small subset of the iterable 
that actually gets added to the heap.

After this, another patch for simplifying nsmallest() is forthcoming.

--
components: Library (Lib)
files: rid_nlargest.py
messages: 217859
nosy: rhettinger
priority: low
severity: normal
status: open
title: Simplify and speed-up heaqp.nlargest()
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file35148/rid_nlargest.py

___
Python tracker 

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