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

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

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

Changes by koobs : -- title: libpython3.so conflicts between $VERSIONs -> altinstall should not install libpython3.so (conflict between multiple $VERSIONs) ___ Python tracker __

[issue13299] namedtuple row factory for sqlite3

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.

[issue23283] Backport Tools/clinic to 3.4

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.

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

Changes by koobs : -- nosy: +koobs ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mail

[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

[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 ___ _

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

[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

[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

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

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 Libra

[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

[issue2292] Missing *-unpacking generalizations

Guido van Rossum added the comment: SGTM On Tue, Jan 20, 2015 at 4:08 PM, Neil Girdhar 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

[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? -- ___

[issue2292] Missing *-unpacking generalizations

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.

[issue23285] PEP 475 - EINTR handling

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

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

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

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

[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 "", line 1, in TypeError: f() got multiple values for keyword argument 'x' Which, as I understand, is the correct result. I'm using starunpack8.diff ri

[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

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

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 comp

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

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

[issue2292] Missing *-unpacking generalizations

Neil Girdhar added the comment: Post it? It's just "hg diff > a.diff" -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue23285] PEP 475 - EINTR handling

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

[issue23285] PEP 475 - EINTR handling

Antoine Pitrou added the comment: Perhaps Ned can help on the OS X side of things. -- nosy: +ned.deily ___ Python tracker ___ ___ Pyth

[issue23285] PEP 475 - EINTR handling

Changes by Charles-François Natali : -- title: PEP 475 - EINTR hanndling -> PEP 475 - EINTR handling ___ Python tracker ___ ___ Python

[issue23286] A typo in the tutorial

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 ty

[issue23285] PEP 475 - EINTR hanndling

Changes by Charles-François Natali : -- keywords: +patch Added file: http://bugs.python.org/file37797/ff1274594739.diff ___ Python tracker ___ ___

[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

[issue23285] PEP 475 - EINTR hanndling

Changes by Charles-François Natali : -- components: Library (Lib) hgrepos: 293 nosy: haypo, neologix, pitrou priority: normal severity: normal status: open title: PEP 475 - EINTR hanndling type: enhancement ___ Python tracker

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

Changes by Poor Yorick : -- keywords: +patch Added file: http://bugs.python.org/file37796/34d54cc5ecfd.diff ___ Python tracker ___ ___

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

Changes by Poor Yorick : -- hgrepos: -291 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

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

Changes by Poor Yorick : -- hgrepos: +292 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.o

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

Changes by Poor Yorick : -- hgrepos: +291 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.o

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

Changes by Poor Yorick : -- hgrepos: -290 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

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

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

Changes by STINNER Victor : -- title: asyncio: add BaseEventLoop._current_handle -> asyncio: add BaseEventLoop._current_handle (only used in debug mode) ___ Python tracker ___ _

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

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 deli

[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

[issue23208] asyncio: add BaseEventLoop._current_handle

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

[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

[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

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

Changes by STINNER Victor : -- title: asyncio: race condition when cancelling a _WaitHandleFuture -> [Windows] asyncio: race condition when cancelling a _WaitHandleFuture ___ Python tracker ___

[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

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

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

[issue2292] Missing *-unpacking generalizations

Changes by fhahn : -- nosy: -fhahn ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mail

[issue23283] Backport Tools/clinic to 3.4

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 d

[issue23276] hackcheck is broken in association with __setattr__

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 si

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

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)]" -- "

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

Zachary Ware added the comment: Thanks for the (very quick!) review, Serhiy. -- assignee: -> zach.ware ___ Python tracker ___ ___ Pyt

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

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

[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 "", line 1, in SystemError: unknown opcode -- ___ Python tracker

[issue2292] Missing *-unpacking generalizations

Joshua Landau added the comment: Just change if (!PyUnicode_Compare(tmp, key)) { when iterating over prior keyword arguments to if (tmp && !PyUnicode_Compare(tmp, key)) { since tmp (the argument's name) can now be NULL. -- ___ Python track

[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 ___ __

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

Demian Brecht added the comment: (Admittedly, I may also have been doing something entirely invalid in previous experiments as well) -- ___ Python tracker ___ ___

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

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

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

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(). I've confirmed that

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar : Added file: http://bugs.python.org/file37792/starunpack6.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

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

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

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

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

[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) == DOUBLES

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

[issue23281] Access violation - pyc file

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

[issue23281] Access violation - pyc file

Paweł Zduniak added the comment: This file is created by fuzzer -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue23281] Access violation - pyc file

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 tr

[issue2292] Missing *-unpacking generalizations

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 b

[issue1602] windows console doesn't print or input Unicode

Mark Hammond added the comment: > File redirection has nothing to do with win-unicode-console Thank you, that comment is spot on - there are multiple issues being conflated here. This bug is purely about the tty/console behaviour. -- ___ Python trac

[issue2292] Missing *-unpacking generalizations

Changes by Fred L. Drake, Jr. : -- nosy: -fdrake ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue2292] Missing *-unpacking generalizations

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

[issue23276] hackcheck is broken in association with __setattr__

eryksun added the comment: >def __setattr__(cls, key, value): >super(type(QMediaPlaylist), cls).__setattr__(cls, key, value) >return > > The program segfaults when instantiating the Playlist class. I'd expect a TypeError because of the extra cls argument. It's already a bound

[issue2292] Missing *-unpacking generalizations

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 *

[issue23282] Slightly faster set lookup

New submission from Serhiy Storchaka: Currently set_lookkey() first tests entry->key == NULL, then entry->hash == hash and entry->key != dummy, and only after that entry->key == key. Proposed patch optimizes the order of comparisons. entry->key == key is tested first as for dicts. And no need

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar : Added file: http://bugs.python.org/file37788/starunpack4.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue2292] Missing *-unpacking generalizations

Changes by Neil Girdhar : Removed file: http://bugs.python.org/file37787/starunpack4.diff ___ Python tracker ___ ___ Python-bugs-list mailing l

[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, s

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

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

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

Martin Panter added the comment: But () is the odd one out if you consider >>> [a, b] = range(2) >>> [] = range(0) >>> (a, b) = range(2) >>> () = range(0) File "", line 1 SyntaxError: can't assign to () -- nosy: +vadmium ___ Python tracker

[issue1508475] transparent gzip compression in urllib

Martin Panter added the comment: The Lib/xmlrpc/client.py file appears to already support compression using “Content-Encoding: gzip”. Perhaps it could be leveraged for any work on this issue. -- ___ Python tracker

[issue23255] SimpleHTTPRequestHandler refactor for more extensible usage.

Ent added the comment: Following is updated patch with * Refactored code with helper functions * Unit Tests * Documentation - Explanation + Examples SimpleHTTPRequestHandler's copyfile has been renamed to copy_file but not shutils'. -- Added file: http://bugs.python.org/file37786/help

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

Kyle Buzsaki added the comment: It seems that assigning to [] is the odd one out in this case. Why is this even possible? >>> [] = () >>> [] = {} >>> [] = set() >>> list() = () File "", line 1 SyntaxError: can't assign to function call >>> () = [] File "", line 1 SyntaxError: can't assign t

[issue23281] Access violation - pyc file

eryksun added the comment: You attached a corrupt bytecode cache for stdlib bisect.py: >>> f = open('test.pyc', 'rb') >>> magic,tstamp = struct.unpack('>> magic27 = 62211 | (ord('\r') << 16) | (ord('\n') << 24) >>> magic == magic27 True >>> datetime.fromtimestamp(tstamp)

[issue23276] hackcheck is broken in association with __setattr__

Alfred Krohmer added the comment: Can you elaborate what QtClass and QtMeta is in your case? My original example was reduced to a minimal case and seems to work with your suggestions. The complete example involving SQLalchemy is here: http://stackoverflow.com/questions/28032928/sqlalchemy-mul

[issue18898] Apply the setobject optimizations to dictionaries

Changes by Raymond Hettinger : -- versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue23269] Tighten-up search loops in sets

Changes by Raymond Hettinger : -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing