date:20150120


Neil Girdhar added the comment:

Yup, that's it.  So two problems down:

It has yet to be updated to the most recent Python version
It features a now redundant replacement for yield from which should be removed

I'm working on:

It also loses support for calling function with keyword arguments before 
positional arguments, which is an unnecessary backwards-incompatible change.

I'm waiting on some feedback from python-ideas to make sure I know what should 
be allowed post PEP448.

--

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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Berker Peksag


Berker Peksag added the comment:

 Python/ast.c:2433:5: error: ‘npositionals’ undeclared (first use in this 
 function)

Line 2425 should be

int i, nargs, nkeywords, npositionals, ngens;

--

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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Fred L. Drake, Jr.


Changes by Fred L. Drake, Jr. fdr...@gmail.com:


--
nosy:  -fdrake

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

Hi Chris.  It might be hard to notice, but you're seeing the same build failure.

Looking at the patch-to-patch differences, I didn't see anything out of the 
ordinary.  My patch file includes more surrounding lines, dates, and is against 
a different repository, so it sees a lot of the new matrix multiplication 
operator stuff, etc.  Is there a best practice for creating diff files?  I just 
did hg diff  starunpack3.diff.

Anyway, here's a new patch with the yield *args code that has been supplanted 
by yield from removed.

--
Added file: http://bugs.python.org/file37787/starunpack4.diff

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

[issue2292] Missing *-unpacking generalizations


Changes by Neil Girdhar mistersh...@gmail.com:


Added file: http://bugs.python.org/file37788/starunpack4.diff

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

[issue2292] Missing *-unpacking generalizations


Changes by Neil Girdhar mistersh...@gmail.com:


Removed file: http://bugs.python.org/file37787/starunpack4.diff

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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Chris Angelico


Chris Angelico added the comment:

*facepalm* Of course I am. I don't know how I missed that in there, but maybe I 
was focusing too much on the abort that followed it to actually read the 
exception text. Duh.

But with the latest version of the patch, I'm seeing something that I'm fairly 
sure *is* a different failure:

gcc -pthread -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG 
-g -fwrapv -O3 -Wall -Wstrict-prototypes-Werror=declaration-after-statement 
  -I. -IInclude -I./Include-DPy_BUILD_CORE -o Python/ast.o Python/ast.c
Python/ast.c: In function ‘ast_for_call’:
Python/ast.c:2433:5: error: ‘npositionals’ undeclared (first use in this 
function)
Python/ast.c:2433:5: note: each undeclared identifier is reported only once for 
each function it appears in
make: *** [Python/ast.o] Error 1

--

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

[issue23275] Can assign [] = (), but not () = []

2015-01-20 Thread eryksun


eryksun added the comment:

In ast.c, set_context checks for assignment to an empty tuple, but not an empty 
list.

case List_kind:
e-v.List.ctx = ctx;
s = e-v.List.elts;
break;
case Tuple_kind:
if (asdl_seq_LEN(e-v.Tuple.elts))  {
e-v.Tuple.ctx = ctx;
s = e-v.Tuple.elts;
}
else {
expr_name = ();
}
break;

https://hg.python.org/cpython/file/ab2c023a9432/Python/ast.c#l912

--
nosy: +eryksun

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

[issue23281] Access violation - pyc file

2015-01-20 Thread Brett Cannon


Brett Cannon added the comment:

If it was created by a fuzzer then this isn't a bug as we do no validation of 
bytecode formatting as we assume it was generated by Python and not an 
external, malicious source.

--
nosy: +brett.cannon
resolution:  - not a bug
status: open - closed

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

[issue23281] Access violation - pyc file

2015-01-20 Thread Paweł Zduniak


Paweł Zduniak added the comment:

This file is created by fuzzer

--

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

[issue23281] Access violation - pyc file

2015-01-20 Thread Eric V. Smith


Eric V. Smith added the comment:

Was this file generated by CPython from a .py file? If so, can you share the 
.py file?

If not, how was this file generated? As eryksun says, it appears to not be a 
valid .pyc file.

--
nosy: +eric.smith

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

[issue23281] Access violation - pyc file


STINNER Victor added the comment:

 we assume it was generated by Python and not an external, malicious source.

Said differently: you must not trust .py or .pyc downloaded from untrusted 
sources. Executing arbitary .py or .pyc file allows to execute arbitrary Python 
code.

Instead of writing complex code to inject machine code in the Python evaluation 
loop (Python/ceval.c), just execute import os; os.system('echo pwn!') which 
runs an arbitrary shell command. Compile it to .pyc if you want to exploit 
the PYC path.

--
nosy: +haypo

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

[issue2292] Missing *-unpacking generalizations


Joshua Landau added the comment:

The problem seems to be that with the removal of

-else if (TYPE(ch) == STAR) {
-vararg = ast_for_expr(c, CHILD(n, i+1));
-if (!vararg)
-return NULL;
-i++;
-}
-else if (TYPE(ch) == DOUBLESTAR) {
-kwarg = ast_for_expr(c, CHILD(n, i+1));
-if (!kwarg)
-return NULL;
-i++;
-}

the code will ignore any subnodes that aren't of type argument. However, the 
grammar still says

arglist: (argument ',')* (argument [','] | '*' test [',' '**' test] | '**' test)

so this is incorrect.

Here's an example of what you might get

inner(
a,argument comma
*bcd, star test comma
e,argument comma
f=6,argument comma
**{g: 7}, doublestar test comma
h=8,argument comma
**{i:9}   doublestar test
)

--

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

Yes, thank you!  That explained it.  I am almost done fixing this patch.  
Here's my progress so far if you want to try it out.  Just one test left to fix.

--
Added file: http://bugs.python.org/file37790/starunpack5.diff

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

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

2015-01-20 Thread Demian Brecht

Demian Brecht added the comment:

TL;DR: Because HTTP is an application-level protocol, it's nearly impossible to
gauge how a server will behave given a set of conditions. Because of that, any
time that assumptions can be avoided, they should be.

@R. David Murray:

That is, if the connection has been closed, I think an operation attempted on
the connection should raise an exception that makes it clear that the
connection is closed (in the case of some stdlib modules, that may be a
socket level exception for the operation on the closed socket).

In the typical case, this is exactly what happens. This issue is around a race
condition that can occur between the client issuing a request prior to
terminating the connection with the server, but the server terminating it prior
to processing the request. In these cases, the client is left in a state where
as far as it's concerned, it's in a valid state waiting for a response which
the server will not issue as it has closed the socket on its side. In this
case, the client reading an empty string from the receive buffer implies a
closed socket. Unfortunately, it's not entirely uncommon when using persistent
connections, as Martin's examples demonstrate.

I think the remote server writing a blank line to the socket is a very
different thing from the remote server closing the connection without writing
anything, so I may be misunderstanding something here.

+1. What Martin is arguing here (Martin, please correct me if I'm wrong) is
that a decently behaved server should not, at /any/ time write a blank line to
(or effectively no-op) the socket, other than in the case where the socket
connection has been closed. While I agree in the typical case, a blend of
Postel and Murphy's laws leads me to believe it would be better to expect,
accept and handle the unexpected.

@Martin:

Here's a concrete example of the unexpected behaviour. It's not specific to
persistent connections and would be caught by the proposed first request
solution, but ultimately, similar behaviour may be seen at any time from other
servers/sources:
http://stackoverflow.com/questions/22813645/options-http-methods-gives-an-empty-response-on-heroku.

Googling for http empty response and similar search strings should also
provide a number of examples where unexpected behaviour is encountered and in
which case raising an explicit ConnectionClosed error would add to the
confusion.

Other examples are really hypotheticals and I don't think it's worth digging
into them too deeply here. Unexpected behaviour (regardless of whether it's on
the first or Nth request) should be captured well enough by now.

Eventually the server _would_ probably drop the connection (so
ConnectionClosed would not be misleading)

Sure, but you're raising an exception based on future /expected/ behaviour.
That's my issue with the proposed solution in general. ConnectionClosed assumes
specific behaviour, where literally /anything/ can happen server side.

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

All tests pass for me!  Would anyone be kind enough to do a code review?

--
Added file: http://bugs.python.org/file37791/starunpack6.diff

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

[issue23266] Faster implementation to collapse non-consecutive ip-addresses

2015-01-20 Thread Markus


Markus added the comment:

My initial patch was wrong wrt. _find_address_range.
It did not loop over equal addresses.
Thats why performance with many equal addresses was degraded when dropping the 
set().

Here is a patch to fix _find_address_range, drop the set, and improve 
performance again.

python3 -m timeit -s import bipaddress; ips = 
[bipaddress.ip_address('2001:db8::1000') for i in range(1000)] -- 
bipaddress.collapse_addresses(ips)
1000 loops, best of 3: 1.76 msec per loop

python3 -m timeit -s import aipaddress; ips = 
[aipaddress.ip_address('2001:db8::1000') for i in range(1000)] -- 
aipaddress.collapse_addresses(ips)
1000 loops, best of 3: 1.32 msec per loop

--
Added file: http://bugs.python.org/file37794/ipaddress_faster_collapse4.patch

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

[issue2292] Missing *-unpacking generalizations


Changes by Neil Girdhar mistersh...@gmail.com:


Added file: http://bugs.python.org/file37792/starunpack6.diff

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

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

2015-01-20 Thread Demian Brecht


Demian Brecht added the comment:

Now I think I'd like to take my foot out of my mouth.

Previous quick experiments that I had done were at the socket level, 
circumventing some of the logic in the HTTPResponse, mainly the calls to 
readline() rather than simple socket.recv(N).

I've confirmed that the /only/ way that the HTTPConnection object can possibly 
get a 0-length read is, in fact, if the remote host has closed the connection.

In light of that, I have no objection at all to the suggested addition of 
ConnectionClosed exception and my apologies for the added confusion and 
dragging this issue on much longer than it should have been.

I've also attached my proof of concept code for posterity.

--
Added file: http://bugs.python.org/file37793/zero_response_poc.py

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

[issue23280] Convert binascii.{un}hexlify to Argument Clinic (fix docstrings)

2015-01-20 Thread Roundup Robot


Roundup Robot added the comment:

New changeset 1cb2b46c5109 by Zachary Ware in branch '3.4':
Issue #23280: Fix docstrings for binascii.(un)hexlify
https://hg.python.org/cpython/rev/1cb2b46c5109

New changeset 754c630c98a3 by Zachary Ware in branch 'default':
Merge with 3.4 (closes #23280)
https://hg.python.org/cpython/rev/754c630c98a3

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

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

[issue23280] Convert binascii.{un}hexlify to Argument Clinic (fix docstrings)

2015-01-20 Thread Zachary Ware


Zachary Ware added the comment:

Thanks for the (very quick!) review, Serhiy.

--
assignee:  - zach.ware

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

[issue23266] Faster implementation to collapse non-consecutive ip-addresses

2015-01-20 Thread Serhiy Storchaka


Serhiy Storchaka added the comment:

Only one duplicated address is degenerated case. When there is a lot of 
duplicated addresses in range the patch causes regression.

$ ./python -m timeit -s import ipaddress; ips = 
[ipaddress.ip_address('2001:db8::%x' % (i%100)) for i in range(10)] -- 
ipaddress.collapse_addresses(ips)

Unpatched: 10 loops, best of 3: 369 msec per loop
Patched: 10 loops, best of 3: 1.04 sec per loop

--

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

[issue2292] Missing *-unpacking generalizations


Joshua Landau added the comment:

This was a rather minor fix; I basically moved from STORE_SUBSCR to STORE_MAP 
and fixed a BUILD_MAP opcode.

--
Added file: http://bugs.python.org/file37795/starunpack7.diff

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

[issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS


Changes by Poor Yorick pooryor...@users.sourceforge.net:


--
keywords: +patch
Added file: http://bugs.python.org/file37796/34d54cc5ecfd.diff

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

[issue2292] Missing *-unpacking generalizations


Joshua Landau added the comment:

Aye, I'd done so (see starunpack7.diff). It was the fuss to reapply it ontop of 
your newer diff and making sure I'd read at least *some* of the devguide before 
barging on.

Anyhow, here's another small fix to deal with the [*[0] for i in [0]] problem. 
I'm not nearly confident I can touch the grammar, though, so the other problems 
are out of my reach.

--
Added file: http://bugs.python.org/file37798/starunpack8.diff

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

I think there will still be a problem ceval with the way the dicts are combined 
unfortunately, but that should be easy to fix.

--

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

[issue2292] Missing *-unpacking generalizations


Joshua Landau added the comment:

I'm getting

 f(x=5, **{'x': 1}, **{'x': 3}, y=2)
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: f() got multiple values for keyword argument 'x'

Which, as I understand, is the correct result. I'm using starunpack8.diff right 
now.

--

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

[issue2292] Missing *-unpacking generalizations


Joshua Landau added the comment:

 The problem with using STORE_MAP is you create a new dict for each keyword 
 argument in that situation.

You don't; if you look at the disassembly for producing a built-in dict 
(dis.dis('{1:2, 2:3, 3:4}')) you'll see they use STORE_MAP too. STORE_MAP 
seems to just be the map equivalent of LIST_APPEND.

I've done simple timings that show my version being faster...

Unfortunately, it points out there is definitely a memory leak. This reproduces:

def f(a):
pass

while True:
f(**{}, a=1)

This goes for both patches 8 and 9.

--

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

[issue2292] Missing *-unpacking generalizations


Joshua Landau added the comment:

I think I've got it working; I'm just working out how to make a patch and 
adding a test or two. I think I'll also need to sign the contributor agreement.

While I'm at it, here are a few other deviations from the PEP:


- {*()} and {**{}} aren't supported

- [*[0] for i in [0]] gives a SystemError

- return *(1, 2, 3), fails whilst *(1, 2, 3), succeeds

--

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

[issue23287] ctypes.util.find_library needlessly call crle on Solaris

2015-01-20 Thread John Beck


New submission from John Beck:

On Solaris, in Lib/ctypes/util.py, we have code that looks for
/usr/bin/crle and calls it to parse its output to try to determine
the Default Library Path.  This code broke recently (Solaris 12 build
65), as it expects to find a line starting with
Default Library Path (ELF):
but the  (ELF) part of that line was removed because it was no longer
needed.  So we need a change here regardless.  But it turns out that
calling crle is not needed at all because the default library path is
a constant on Solaris: /lib/64:/usr/lib/64 in 64-bit mode and
/lib:/usr/lib in 32-bit mode.  Thus I offer the attached patch
for both 2.7 and 3.4.

--
components: ctypes
files: crle-fix.patch
keywords: patch
messages: 234417
nosy: jbeck
priority: normal
severity: normal
status: open
title: ctypes.util.find_library needlessly call crle on Solaris
type: resource usage
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file37800/crle-fix.patch

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

Ah, nice!  I didn't realize what STORE_MAP did.  I thought it created a map 
each time.  We'll just do it your way.

--

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

[issue23208] asyncio: add BaseEventLoop._current_handle (only used in debug mode)


Changes by STINNER Victor victor.stin...@gmail.com:


--
title: asyncio: add BaseEventLoop._current_handle - asyncio: add 
BaseEventLoop._current_handle (only used in debug mode)

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

[issue23285] PEP 475 - EINTR hanndling


Changes by Charles-François Natali cf.nat...@gmail.com:


--
components: Library (Lib)
hgrepos: 293
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: PEP 475 - EINTR hanndling
type: enhancement

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

Post it?  It's just hg diff  a.diff

--

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

If there is a speed issue, the real answer I think is to add an opcode as 
suggested in the source code that coalesces keyword arguments into dicts rather 
than the weird dance as the previous authors described it, or turning each 
argument into an individual dict and merging them at the end as you're doing…

--

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

[issue23285] PEP 475 - EINTR hanndling


Changes by Charles-François Natali cf.nat...@gmail.com:


--
keywords: +patch
Added file: http://bugs.python.org/file37797/ff1274594739.diff

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

Thanks!

I've incorporated your changes to deal with the [*[0] for i in [0]] problem, 
although I don't understand them yet.

The problem with using STORE_MAP is you create a new dict for each keyword 
argument in that situation.  I optimized that away.  Good catch on the 
BUILD_MAP opcode problem.  I could not figure out why that wasn't working!

I added some tests.  Did you say you had some tests?

One of the tests that both of our code is failing on still is:

 def f(x, y):
... print(x, y)
...
 f(x=5, **{'x': 1}, **{'x': 3}, y=2)

It's just a problem in ceval that I'll work on now.

--
Added file: http://bugs.python.org/file37799/starunpack9.diff

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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Guido van Rossum


Guido van Rossum added the comment:

SGTM

On Tue, Jan 20, 2015 at 4:08 PM, Neil Girdhar rep...@bugs.python.org
wrote:


 Neil Girdhar added the comment:

 That makes sense.

 If you wanted to override, you could always write:

 f(**{**a, **b, 'x': 5})

 rather than

 f(**a, **b, x=5)

 Should I go ahead and fix it so that overriding is always wrong? E.g.,

 f(**{'x': 3}, **{'x': 4})

 which currently works?

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue2292
 ___


--

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

[issue23285] PEP 475 - EINTR hanndling


New submission from Charles-François Natali:

The test runs fine on Linux, but hangs in test_send() on OS-X and *BSD.
I don't know what's wrong, so if someone with access to one of these OS could 
have a look, it would be great.

--

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

[issue23285] PEP 475 - EINTR handling

2015-01-20 Thread Antoine Pitrou


Antoine Pitrou added the comment:

Perhaps Ned can help on the OS X side of things.

--
nosy: +ned.deily

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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread Guido van Rossum


Guido van Rossum added the comment:

Let's tread careful here. In regular dicts, for better or for worse, {'x':
1, 'x': 2} is defined and returns {'x': 2}. But in keyword arg processing,
duplicates are always rejected. This may be an area where we need to adjust
the PEP to match that expectation.

On Tue, Jan 20, 2015 at 3:51 PM, Neil Girdhar rep...@bugs.python.org
wrote:


 Neil Girdhar added the comment:

 Why is that correct?  The PEP mentions overriding.  Right now each dict
 overrides values from the last silently, which I think makes sense.  The
 keyword arguments you pass in override keys from previous dicts (also good
 I think).  The problem is that you can pass multiple duplicate keyword
 arguments, and the one below, which I think should succeed.

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue2292
 ___


--

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

[issue23285] PEP 475 - EINTR handling

2015-01-20 Thread Antoine Pitrou


Antoine Pitrou added the comment:

The review diff is weird: it seems it contains changes that aren't 
EINTR-related (see e.g. argparse.rst).

--

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

[issue23199] libpython27.a in amd64 release is 32-bit

2015-01-20 Thread Zach Welch


Zach Welch added the comment:

That's certainly an interesting data point.  We are just beginning to use 
MinGW-w64 internally, so I do not have enough experience to confirm or deny 
that advice.  For various reasons, we must use cross-compiling on a Linux host, 
so the advice to use a native compiler is moot for our situation.

Certainly, documenting the absense of the 64-bit library would be good.  
Providing a documented script to generate one is better.  Providing the library 
would be ideal, if there will not be forward compatibility or runtime issues.

It would be nice to see concrete details about the current state of affairs.  
The cython project's warning would carry more weight with me if it contained 
links to specific details: mailing list discussion that led to the deliberate 
decision to omit the 64-bit library, bug reports filed against the mingw-w64 
project about the runtime issues, etc..  That said, such details probably do 
exist, but my cursory searching has failed to turn them up.

--

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

[issue23285] PEP 475 - EINTR handling

2015-01-20 Thread Ned Deily


Ned Deily added the comment:

(It may be several days before I can spend much time on it but I will take a 
look.)

--

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

[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture


Changes by STINNER Victor victor.stin...@gmail.com:


--
title: asyncio: race condition when cancelling a _WaitHandleFuture - [Windows] 
asyncio: race condition when cancelling a _WaitHandleFuture

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

[issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS


New submission from Poor Yorick:

Building Python-2.7.9 using --prefix, with an ncurses that's linked to libtinfo
and a readline that isn't linked to any termcap library, I ran into the trouble
that the curses module wan't buing build with the needed -L and -l flags for
the libtinfo shared object.  I dug into setup.py, and ended up overhauling the
readline, curses, and also dbm handling (more on that in another ticket).  I
also made changes to allow setup.py to pick up options like -isystem from
$CPPFLAGS, replacing in the process the optparse module with the argparse
module.  Since argparse requires collections.OrderedDict, which isn't yet built
at this stage, I added Lib_boot/argparse_boot.py, which uses the pure-Python
OrderedDict from

https://pypi.python.org/pypi/ordereddict

and had setup.py use argparse_boot module instead.

The build also ran into trouble with system directories that setup.py
explicitly adds to inc_dirs and lib_dirs ahead of those of the alternate
prefix.

The attached files fixed all these issues in my scenario, allowing a succesful
build and install of Python-2.7.9.

--
components: Build
hgrepos: 290
messages: 234399
nosy: pooryorick
priority: normal
severity: normal
status: open
title: curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS
versions: Python 2.7

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

Why is that correct?  The PEP mentions overriding.  Right now each dict 
overrides values from the last silently, which I think makes sense.  The 
keyword arguments you pass in override keys from previous dicts (also good I 
think).  The problem is that you can pass multiple duplicate keyword arguments, 
and the one below, which I think should succeed.

--

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

That makes sense.

If you wanted to override, you could always write:

f(**{**a, **b, 'x': 5})

rather than

f(**a, **b, x=5)

Should I go ahead and fix it so that overriding is always wrong? E.g.,

f(**{'x': 3}, **{'x': 4})

which currently works?

--

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

Could you try this and tell me how many BUILD_MAPs you're doing?

dis.dis(def f(w, x, y, z, r): pass\nf(w=1, **{'x': 2}, y=3, z=4, r=5))

Mine does 2.

--

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

Thanks.  It's probably compile.c under /* Same dance again for keyword 
arguments */.  nseen remains zero and probably shouldn't.  I need to learn 
more about the opcodes.

--

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

[issue23208] asyncio: add BaseEventLoop._current_handle


STINNER Victor added the comment:

@Guido, @Yury: What do you think of this feature? Does it make sense to expose 
(internally) the handle currently executed?

--

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

[issue23208] asyncio: add BaseEventLoop._current_handle

2015-01-20 Thread Yury Selivanov


Yury Selivanov added the comment:

 What do you think of this feature? Does it make sense to expose (internally) 
 the handle currently executed?

I think it's OK to have something like `loop._current_handle` to work ~only~ in 
debug mode. Enhancing `loop.call_exception_handler` to use it also makes sense. 
I would also want to make sure, that this property exists only in debug mode 
and shouldn't be used outside of asyncio.

--

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

[issue23199] libpython27.a in amd64 release is 32-bit

2015-01-20 Thread Steve Dower


Steve Dower added the comment:

Just came across this advice on 
https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows:

 Do not use MinGW-w64. As you will notice, the MinGW import library for
 Python (e.g. libpython27.a) is omitted from the AMD64 version of
 Python. This is deliberate. Do not try to make one using dlltool.
 There is no official MinGW-w64 release yet, it is still in beta and
 considered unstable, although you can get a 64-bit build from e.g.
 TDM-GCC. There have also been issues with the mingw runtime
 conflicting with the MSVC runtime; this can happen from places you
 don't expect, such as inside runtime libraries for g++ or gfortran. To
 stay on the safe side, avoid MinGW-w64 for now.

How accurate is this? Would we be better to omit the mingw libraries from the 
installer and instead provide the commands (or even a shell script?) to 
generate it with whatever toolset you're currently using?

--

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

[issue2292] Missing *-unpacking generalizations


Joshua Landau added the comment:

2 here as well:

 15 LOAD_CONST   2 ('w')
 18 LOAD_CONST   3 (1)
 21 BUILD_MAP1
 24 LOAD_CONST   4 (2)
 27 LOAD_CONST   5 ('x')
 30 STORE_MAP
 31 BUILD_MAP1
 34 LOAD_CONST   6 (3)
 37 LOAD_CONST   7 ('y')
 40 STORE_MAP
 41 LOAD_CONST   8 (4)
 44 LOAD_CONST   9 ('z')
 47 STORE_MAP
 48 LOAD_CONST  10 (5)
 51 LOAD_CONST  11 ('r')
 54 STORE_MAP
 55 BUILD_MAP_UNPACK 2

--

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

[issue22947] Enable 'imageop' - Multimedia Srvices Feature module for 64-bit platform

2015-01-20 Thread koobs


Changes by koobs koobs.free...@gmail.com:


--
nosy: +koobs

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

[issue23283] Backport Tools/clinic to 3.4

2015-01-20 Thread Larry Hastings


Larry Hastings added the comment:

I would prefer the backport be more selective.  There are other changes (set 
literals, fix --converters) in trunk that aren't in 3.4 and I wouldn't want 
them pulled in willy-nilly.

However, I'd accept this backport if the patch looks minimal and clean.

--

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

[issue13299] namedtuple row factory for sqlite3

2015-01-20 Thread YoSTEALTH


YoSTEALTH added the comment:

note: sqlite_namedtuplerow.patch _cache method conflicts with attached database 
with say common table.column name like id

Using namedtuple method over sqlite3.Row was a terrible idea for me. I thought 
namedtuple is like tuple so should be faster then dict! wrong. I wasted 2 days 
change my work to namedtuple and back to sqlite3.Row, the speed difference on 
my working project was:

namedtuple 0.035s/result
sqlite3.Rows 0.0019s/result

for(speed test) range: 1
namedtuple 17.3s
sqlite3.Rows 0.4s

My solution was to use sqlite3.Row (for speed) but to get named like usage by 
convert dict keys() with setattr names:

class dict2named(dict):
def __init__(self, *args, **kwargs):
super(dict2named, self).__init__(*args, **kwargs)
self.__dict__ = self

Usage:

for i in con.execute('SELECT * FROM table'):
yield dict2named(i)

Now i can use:

print(i.title)

and handy dict methods for dash column names:

print(i['my-title'])
print(i.get('my-title', 'boo'))

Now working project speed:
sqlite3.Rows 0.0020s/result

for(speed test) range: 1
sqlite3.Rows 0.8s with dict2named converting

This i can work with, tiny compromise in speed with better usage.

--
nosy: +YoSTEALTH

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

[issue2292] Missing *-unpacking generalizations


Neil Girdhar added the comment:

Detecting overrides and raising TypeError. E.g.,

 def f(x, y):
... print(x, y)
...
 f(x=5, **{'x': 3}, y=2)
Traceback (most recent call last):
  ...
TypeError: f() got multiple values for keyword argument 'x'

--
Added file: http://bugs.python.org/file37801/starunpack10.diff

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

[issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS


Changes by Poor Yorick pooryor...@users.sourceforge.net:


--
hgrepos:  -290

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

[issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS


Changes by Poor Yorick pooryor...@users.sourceforge.net:


--
hgrepos: +291

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

[issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS


Changes by Poor Yorick pooryor...@users.sourceforge.net:


--
hgrepos: +292

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

[issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS


Changes by Poor Yorick pooryor...@users.sourceforge.net:


--
hgrepos:  -291

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

[issue23285] PEP 475 - EINTR handling


Changes by Charles-François Natali cf.nat...@gmail.com:


--
title: PEP 475 - EINTR hanndling - PEP 475 - EINTR handling

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

[issue23286] A typo in the tutorial

2015-01-20 Thread aruseni


New submission from aruseni:

https://docs.python.org/3/tutorial/introduction.html

 Lists also supports operations like concatenation

--
assignee: docs@python
components: Documentation
messages: 234401
nosy: aruseni, docs@python
priority: normal
severity: normal
status: open
title: A typo in the tutorial

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

[issue23266] Faster implementation to collapse non-consecutive ip-addresses

2015-01-20 Thread Markus


Markus added the comment:

Eleminating duplicates before processing is faster once the overhead of the set 
operation is less than the time required to sort the larger dataset with 
duplicates.

So we are basically comparing sort(data) to sort(set(data)).
The optimum depends on the input data.

python3 -m timeit -s import random; import bipaddress; ips = 
[bipaddress.ip_address('2001:db8::') + i for i in range(10)]; 
random.shuffle(ips) -- bipaddress.collapse_addresses(ips)

10 loops, best of 3: 1.49 sec per loop
vs.
10 loops, best of 3: 1.59 sec per loop

If the data is pre-sorted, possible if you retrieve from database, things are 
drastically different:

python3 -m timeit -s import random; import bipaddress; ips = 
[bipaddress.ip_address('2001:db8::') + i for i in range(10)];  -- 
bipaddress.collapse_addresses(ips)
10 loops, best of 3: 136 msec per loop
vs
10 loops, best of 3: 1.57 sec per loop

So for my usecase, I basically have less than 0.1% duplicates (if at all), 
dropping the set would be better, but ... other usecases will exist.

Still, it is easy to emulate the use of sorted(set()) from a users 
perspective - just call collapse_addresses(set(data)) in case you expect to 
have duplicates and experience a speedup by inserting unique, possibly even 
sorted, data.

On the other hand, if you have a huge load of 99.99% sorted non collapseable 
addresses, it is not possible to drop the set() operation in your sorted(set()) 
from a users perspective, no way to speed things up, and the slowdown you get 
is x10.

That said, I'd drop the set().
Optimization depends on data input, dropping the set() allows the user to 
optimize base on the nature of his input data.

--

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

[issue17975] altinstall should not install libpython3.so (conflict between multiple $VERSIONs)

2015-01-20 Thread koobs


Changes by koobs koobs.free...@gmail.com:


--
title: libpython3.so conflicts between $VERSIONs - altinstall should not 
install libpython3.so (conflict between multiple $VERSIONs)

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

[issue17975] altinstall should not install libpython3.so (conflict between multiple $VERSIONs)

2015-01-20 Thread koobs


koobs added the comment:

Adding 3.2 so I (and other downstream packagers) don't forget to backport the 
fix.

--
versions: +Python 3.2

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

[issue23276] hackcheck is broken in association with setattr

2015-01-20 Thread Alfred Krohmer


Alfred Krohmer added the comment:

 I'd expect a TypeError because of the extra cls argument. It's already a 
 bound method.

Sorry, that was a typo.

 Consider making a playlist class that *has* a SQL table, not one that *is* a 
 SQL table, i.e. use composition instead of inheritance. That sidesteps the 
 incompatible metaclasses.

That would be indeed a solution, but not for the original problem.

I think I have an example now that makes my point clear.

The following code works as it should:

import traceback
import sys

class MyMeta(type):
def __setattr__(cls, key, value):
print(OK)

class MyClass(metaclass=MyMeta):
pass

MyClass.abc = 12 # outputs OK
try:
print(MyClass.abc)
except:
traceback.print_exc(file=sys.stdout) # exception comes here as expected

type.__setattr__(MyClass, 'test', 42) # outputs nothing
print(MyClass.test) # outputs 42

If I get this right, this should be **valid code** (and it should **not** be a 
bug, that this actually works).

However, above define MyMeta like following:

from PyQt5.QtMultimedia import QMediaPlaylist

class MyMeta(type(QMediaPlaylist)):
def __setattr__(cls, key, value):
print(OK)

And you get:

TypeError: can't apply this __setattr__ to PyQt5.QtCore.pyqtWrapperType object

I think that this actually **is** unexpected behaviour. I'm **not** trying to 
apply __setattr__ to PyQt5.QtCore.pyqtWrapperType but to MyClass!

--

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

[issue23283] Backport Tools/clinic to 3.4

2015-01-20 Thread Zachary Ware


New submission from Zachary Ware:

Larry, in #22120 msg224817, you said:
Since IIUC there's no code in 3.4 that uses an unsigned integer return 
converter, I'm not backporting the fix.

Modules/binascii.c does have one use of an unsigned integer return, resulting 
in the only not-something-new difference between 3.4 and 3.5's Modules/clinic 
dir.  Is there any reason not to do a quick hg revert -Cr default Tools/clinic 
 make clinic  hg commit on 3.4 to update binascii.c.h?

--
messages: 234391
nosy: larry, zach.ware
priority: normal
severity: normal
status: open
title: Backport Tools/clinic to 3.4
versions: Python 3.4

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

[issue2292] Missing *-unpacking generalizations

2015-01-20 Thread fhahn


Changes by fhahn f...@fhahn.com:


--
nosy:  -fhahn

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

[issue23278] multiprocessing maxtasksperchild=1 + logging = task loss

2015-01-20 Thread Nelson Minar


Nelson Minar added the comment:

Doing some more testing, I noticed that if I ask multiprocessing to also log, 
the problem stops occurring. If I configure multiprocessing.log_to_stderr() 
instead, the error still occurs. 

Here's how I configured multiprocessing logging that makes the problem go away. 
This goes right at the top of the main() function.

mp_logger = multiprocessing.get_logger()
mp_logger.propagate=True
mp_logger.setLevel(logging.DEBUG)

--

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

[issue2292] Missing *-unpacking generalizations


Joshua Landau added the comment:

I take it back; that just causes

 f(**{}, c=2)
XXX lineno: 1, opcode: 105
Traceback (most recent call last):
  File stdin, line 1, in module
SystemError: unknown opcode

--

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

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

2015-01-20 Thread Demian Brecht


Demian Brecht added the comment:

(Admittedly, I may also have been doing something entirely invalid in previous 
experiments as well)

--

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

[issue2292] Missing *-unpacking generalizations


Joshua Landau added the comment:

This causes a segmentation fault if any keyword arguments come after a 
**-unpack. Minimal demo:

f(**x, x=x)

--

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

[issue2292] Missing *-unpacking generalizations