[issue27810] Add METH_FASTCALL: new calling convention for C functions

Stefan Behnel added the comment: I agree that this would be cool. There is a tiny bit of a backwards compatibility concern as the new function signature would be incompatible with anything we had before, but I would guess that any code that chooses to bypass PyObject_Call() & friends would at

[issue27826] Null-pointer dereference in tuplehash() function

Serhiy Storchaka added the comment: The simplest example: import marshal t = [], t[0].append(t) b = marshal.dumps(t) b = bytearray(b) b[2] = b'<'[0] marshal.loads(b) Create a recursive tuple containing a list containing a reference to original tuple. Marshal it and replace TYPE_LIST ('[') by

[issue27792] bool % int has inconsistent return type.

Xiang Zhang added the comment: issue27792.patch tries to fix this. BTW, Mark, do you think the fast path in long_mod is really needed? Actually the same fast path has already existed in l_divmod. -- keywords: +patch Added file: http://bugs.python.org/file44185/issue27792.patch

Re: PEP suggestion: Uniform way to indicate Python language version

On Monday 22 August 2016 14:33, Chris Angelico wrote: > On Mon, Aug 22, 2016 at 1:37 PM, rocky wrote: >> Sorry should have been: >> >> assert sys.version_info >= (3,0) > > The next question is: How common is code like this? I don't put > version checks in any of my modules.

[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call

Hugo Geoffroy added the comment: Another argument for having the fix in `unwrap` rather than `signature` is that this bug does not actually seem to be called by `signature`, as the doctest module calls `unwrap` for "inspect.isroutine(inspect.unwrap(val))". Also, this call does not even check

Re: PEP suggestion: Uniform way to indicate Python language version

On Mon, Aug 22, 2016 at 1:37 PM, rocky wrote: > Sorry should have been: > > assert sys.version_info >= (3,0) The next question is: How common is code like this? I don't put version checks in any of my modules. Adding magic comments would be of value only if this sort of thing is

Re: Does This Scare You?

On Mon, Aug 22, 2016 at 1:26 AM, Chris Angelico wrote: > They're specifically documented as not touching any file system, which > means that they are cross-platform and cannot be guaranteed to be > perfect. If you know you're running on Windows, use WindowsPath > instead (trying

[issue27826] Null-pointer dereference in tuplehash() function

Raymond Hettinger added the comment: It may be better to focus on Python/marshal.c to see if there are ways to make it more robust (at least checking to see if all of the n entries allocated in a container were actually filled). -- ___ Python

Re: PEP suggestion: Uniform way to indicate Python language version

Sorry should have been: assert sys.version_info >= (3,0) On Sunday, August 21, 2016 at 11:30:11 PM UTC-4, Ben Finney wrote: > rocky writes: > > > The assertion should have been > > > > assert sys.version >= (3, 0) > > Perhaps you haven't tried any of these examples

Re: The Joys Of Data-Driven Programming

On Monday, August 22, 2016 at 12:24:30 AM UTC+5:30, Tim Chase wrote: > On 2016-08-21 04:53, Rustom Mody wrote: > > 2. Basic computing theory shows that re-s and dfas are equivalent. > > Which would one prefer to write/debug? [Thats not a rhetorical > > question] > > I'm curious where REs and DFAs

Re: PEP suggestion: Uniform way to indicate Python language version

rocky writes: > The assertion should have been > > assert sys.version >= (3, 0) Perhaps you haven't tried any of these examples before presenting them? >>> import sys >>> assert sys.version >= (3, 0) Traceback (most recent call last): File "", line 1, in

Re: PEP suggestion: Uniform way to indicate Python language version

The assertion should have been assert sys.version >= (3, 0) If we want to indicate the Python program supports language versions 3.0 and greater. On Sunday, August 21, 2016 at 3:59:48 PM UTC-4, Vincent Vande Vyvre wrote: > Le 21/08/2016 à 20:28, rocky a écrit : > > The problem: > > > > 1.

Re: Does This Scare You?

On 8/21/2016 9:08 PM, eryk sun wrote: On Mon, Aug 22, 2016 at 12:44 AM, Chris Angelico wrote: "Trying to be" cross-platform? The point of these path modules is to *be* cross-platform. I can't call Windows APIs on my Linux box (short of messing around with VMs or Wine or

[issue16113] Add SHA-3 and SHAKE (Keccak) support

Aaron Gallagher added the comment: I'm not sure why one would pick and choose here—SHAKE is part of the NIST SHA-3 standard. -- ___ Python tracker ___

[issue16113] Add SHA-3 and SHAKE (Keccak) support

Donald Stufft added the comment: > I asked a room full of network engineers about SHAKE and not a single one of > them had heard of it Why would a network engineer know about a new variable length hashing algorithm? It's not really within their problem domain. --

[issue26488] hashlib command line interface

Guido van Rossum added the comment: I prefer not to go down this road. The modules that do this where I use it are typically Python specific, e.g. pdb or timeit. In the past we sometimes had little main() functions in modules for testing but I think we have better ways to test modules these

[issue16113] Add SHA-3 and SHAKE (Keccak) support

Raymond Hettinger added the comment: > The SHAKEs were low hanging fruits to implement, so I included them. I don't think this is sufficient motivation. Each new API is a permanent maintenance and documentation burden. It is also a burden to every new user seeing the module and trying to

[issue26488] hashlib command line interface

Raymond Hettinger added the comment: Guido, would you can to opine on this? Every now and then we get a request to make command-line utilities out of tools in the standard library. Whether we should or not depends on whether the standard library intends to be primarily a library for Python

Re: The Joys Of Data-Driven Programming

On Monday, August 22, 2016 at 3:48:49 AM UTC+5:30, Marko Rauhamaa wrote: > Lawrence D’Oliveiro : > > > On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote: > >> ... can heartily recommend SCons. > > > > It’s Python 2 only, not Python 3. > > And? SCons is very good, definitely

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

Martin Panter added the comment: The ctypes tests all seem to be protected with code that checks for None, and explicitly skip the test in that case. The skip message should be visible when you run the test in verbose mode. We could avoid skipping these tests in 2.7 by adding a special case

[issue26488] hashlib command line interface

Changes by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___

[issue27826] Null-pointer dereference in tuplehash() function

Raymond Hettinger added the comment: > but it might be better to avoid a crash here. I'm reluctant to introduce changes like this, especially in the middle of a loop. This code and code like it has been nonproblematic for Python's 26 year history. The code throughout tupleobject.c assumes

[issue27826] Null-pointer dereference in tuplehash() function

Changes by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___

[issue21826] Performance issue (+fix) AIX ctypes.util with no /sbin/ldconfig present

Martin Panter added the comment: It looks like Bert’s patch adjusted two ldconfig calls; the first one was in a BSD-specific branch. Was this intended? Only the second call (default “else:” branch) seems applicable to AIX. Perhaps the performance is improved now that the popen() shell calls

Re: Does This Scare You?

On Mon, Aug 22, 2016 at 11:08 AM, eryk sun wrote: > On Mon, Aug 22, 2016 at 12:44 AM, Chris Angelico wrote: >> "Trying to be" cross-platform? The point of these path modules is to >> *be* cross-platform. I can't call Windows APIs on my Linux box (short >> of

Re: Does This Scare You?

On Mon, 22 Aug 2016 10:38 am, eryk sun wrote: > To me it's scary that this check misses cases because it's trying to > be cross-platform instead of simply relying on GetFullPathName to do > the work. For example, it misses at least the following cases: Instead of shaking in your boots over a

[issue27823] Change bare AttributeError messages to be more informative

Emanuel Barry added the comment: Thanks for your comments Xiang. Yes, it's not equal to #27794, but it's one of the multiple ways to fix it, so I made a new issue about it. The rationale between a bare `raise AttributeError` being changed is the idea that it carries no information, other than

Re: Does This Scare You?

On Mon, Aug 22, 2016 at 12:44 AM, Chris Angelico wrote: > "Trying to be" cross-platform? The point of these path modules is to > *be* cross-platform. I can't call Windows APIs on my Linux box (short > of messing around with VMs or Wine or something, which are > dependencies that

Re: Does This Scare You?

On Mon, Aug 22, 2016 at 10:38 AM, eryk sun wrote: > To me it's scary that this check misses cases because it's trying to > be cross-platform instead of simply relying on GetFullPathName to do > the work. "Trying to be" cross-platform? The point of these path modules is to *be*

Re: Does This Scare You?

On Sun, Aug 21, 2016 at 8:03 PM, Michael Torrie wrote: > On 08/19/2016 05:42 PM, Lawrence D’Oliveiro wrote: >> Python 3.5.2+ (default, Aug 5 2016, 08:07:14) >> [GCC 6.1.1 20160724] on linux >> Type "help", "copyright", "credits" or "license" for more information.

Re: The Joys Of Data-Driven Programming

On Sunday, August 21, 2016 at 11:18:49 PM UTC+1, Marko Rauhamaa wrote: > Lawrence D’Oliveiro : > > > On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote: > >> ... can heartily recommend SCons. > > > > It’s Python 2 only, not Python 3. > > And? SCons is

[issue27826] Null-pointer dereference in tuplehash() function

Changes by Artem Smotrakov : -- keywords: +patch Added file: http://bugs.python.org/file44184/tuplehash.patch ___ Python tracker

[issue27826] Null-pointer dereference in tuplehash() function

New submission from Artem Smotrakov: A null-pointer dereference may happen while deserialization incorrect data with marshal.loads() function. Here is a test which reproduces this (see also attached marshal_tuplehash_null_dereference.py): import marshal value = ( # tuple1

[issue27746] ResourceWarnings in test_asyncio

STINNER Victor added the comment: STINNER Victor added the comment: > @Paul: close() is asynchronous in Python :-) Sorry. Async in asyncio... -- ___ Python tracker

[issue27821] IDLE custom keymaps don't work anymore (Windows, Python 3.6.0a3)

Terry J. Reedy added the comment: (Don't install .0a2, .0a1 is good enough as comparison.) Are you saying that you see, in one line, (*) Use a Custom Key Set [IDLE Classic Windows --] (where -- is the select mini-button) This would be wrong and would suggest that 'IDLE Classis Windows' was

Re: The Joys Of Data-Driven Programming

Lawrence D’Oliveiro : > On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote: >> ... can heartily recommend SCons. > > It’s Python 2 only, not Python 3. And? SCons is very good, definitely beats make. It also illustrates the use of a real programming

Re: Two-Dimensional Expression Layout

On Sunday, August 21, 2016 at 7:19:49 PM UTC+12, Michael Selik wrote: > > On Sun, Aug 21, 2016, 3:06 AM Lawrence D’Oliveiro wrote: > >> On Sunday, August 21, 2016 at 6:49:19 PM UTC+12, Michael Selik wrote: >> >>> Indeed it is, not sure why. >> >> Moral: It helps to understand the code you’re

Re: The Joys Of Data-Driven Programming

Lawrence D’Oliveiro : > On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote: >> Lisp's "data is code and code is data" is a good principle. I have >> successfully used it with Python as well. > > You think self-modifying code is a good idea? Why change

Re: The Joys Of Data-Driven Programming

On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote: > ... can heartily recommend SCons. It’s Python 2 only, not Python 3. -- https://mail.python.org/mailman/listinfo/python-list

Re: The Joys Of Data-Driven Programming

On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote: > Lisp's "data is code and code is data" is a good principle. I have > successfully used it with Python as well. You think self-modifying code is a good idea? -- https://mail.python.org/mailman/listinfo/python-list

Re: The Joys Of Data-Driven Programming

On Monday, August 22, 2016 at 12:21:36 AM UTC+12, Chris Angelico wrote: > The issues with makefiles are mainly to do with metaprogramming (plus > a few specific issues with the format itself, which don't apply to the > more general concept). There's a ton of magic to cope with makefiles > that try

Re: The Joys Of Data-Driven Programming

On Sunday, August 21, 2016 at 11:53:52 PM UTC+12, Rustom Mody wrote: > However seeing that list together like that I cant help wondering: > Is the philosophy of data-driven-ness itself somehow ill-conceived? I don’t understand why. They are all examples of the success of the technique, and I can

[issue12713] argparse: allow abbreviation of sub commands by users

paul j3 added the comment: Another failure case: parser.add_argument('--int', type=int, choices=[10,15,25]) '--int 15` puts 'int=15' in the Namespace. '--int 2' puts 'int=2' in the Namespace, because it matches the 'str(25)'. '--int 1' raises an error in the ambiguity error formatting code:

Re: saving octet-stream png file

On 2016-08-19, Larry Martell wrote: > fd.write(request.POST[key]) You could try: request.encoding = "iso-8859-1" fd.write(request.POST[key].encode("iso-8859-1")) It's hacky and nasty and there might be a better "official" method but I think it should work. --

Re: The Joys Of Data-Driven Programming

Tim Chase writes: > On 2016-08-21 04:53, Rustom Mody wrote: >> 2. Basic computing theory shows that re-s and dfas are equivalent. >> Which would one prefer to write/debug? [Thats not a rhetorical >> question] > > I'm curious where REs and DFAs are shown to be

[issue27825] Make the documentation for statistics' data argument clearer.

New submission from Ned Batchelder: The docs for statistics.mean say, "Return the sample arithmetic mean of data, a sequence or iterator of real-valued numbers." Most of the functions in statistics have a `data` argument, but this function is the only one that says, "a sequence or iterator."

[issue24444] In argparse empty choices cannot be printed in the help

paul j3 added the comment: This error is also produced by help = ' ' that is, a help line with all blanks. As long as there is a nonblank character in the help line it format fine. This issue doesn't need to be resolved by itself, but should be considered if and when the formatting of

[issue27822] Fail to create _SelectorTransport with unbound socket

Paul McGuire added the comment: Patch file attached. -- keywords: +patch Added file: http://bugs.python.org/file44182/ptm_27822.patch ___ Python tracker

[issue27819] Always distribute sdist packages as gztar.

Changes by Jason R. Coombs : -- status: open -> closed ___ Python tracker ___ ___

[issue27819] Always distribute sdist packages as gztar.

Roundup Robot added the comment: New changeset ed9cabce9c38 by Jason R. Coombs in branch 'default': Issue #27819: Add more detail in What's New in 3.6. https://hg.python.org/cpython/rev/ed9cabce9c38 -- ___ Python tracker

Re: Does This Scare You?

On 08/19/2016 05:42 PM, Lawrence D’Oliveiro wrote: > Python 3.5.2+ (default, Aug 5 2016, 08:07:14) > [GCC 6.1.1 20160724] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> from pathlib import PureWindowsPath > >>>

Re: PEP suggestion: Uniform way to indicate Python language version

Le 21/08/2016 à 20:28, rocky a écrit : The problem: 1. there are various code inspection tools that parse Python programs looking for style issues or whatnot. The deeper ones have to do a full parse of the python program. It would be helpful if there were a uniform way to indicate the Python

[issue27819] Always distribute sdist packages as gztar.

Jason R. Coombs added the comment: Good suggestions. -- status: closed -> open ___ Python tracker ___ ___

[issue27746] ResourceWarnings in test_asyncio

STINNER Victor added the comment: @Paul: close() is asynchronous in Python :-) -- ___ Python tracker ___ ___

[issue23229] add inf, nan, infj, nanj to cmath module

Mark Dickinson added the comment: Here's a patch that adds inf, infj, nan and nanj. -- keywords: +patch Added file: http://bugs.python.org/file44181/cmath_inf_nan.patch ___ Python tracker

[issue27822] Fail to create _SelectorTransport with unbound socket

Guido van Rossum added the comment: Can you supply a patch yourself? --Guido (mobile) -- ___ Python tracker ___

Re: The Joys Of Data-Driven Programming

Rustom Mody : > On Sunday, August 21, 2016 at 7:50:39 PM UTC+5:30, Marko Rauhamaa wrote: >> Don't know jam, but can heartily recommend SCons. > > Likely true at some point > Probably not now: http://stackoverflow.com/questions/2847730/c-build-systems > [ tup seems to be the

Re: The Joys Of Data-Driven Programming

On 2016-08-21 04:53, Rustom Mody wrote: > 2. Basic computing theory shows that re-s and dfas are equivalent. > Which would one prefer to write/debug? [Thats not a rhetorical > question] I'm curious where REs and DFAs are shown to be equivalent (serious, not trying to be snarky). I can see with

[issue27823] Change bare AttributeError messages to be more informative

Xiang Zhang added the comment: -1. I don't think this is equal to issue27794. I don't hope when I use `raise AttributeError`, Python hides some magic and sets a message I totally don't want. If you do want a good message, why not passing the message when raising? --

PEP suggestion: Uniform way to indicate Python language version

The problem: 1. there are various code inspection tools that parse Python programs looking for style issues or whatnot. The deeper ones have to do a full parse of the python program. It would be helpful if there were a uniform way to indicate the Python language level used in Python source

[issue26984] int() can return not exact int instance

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker

[issue27643] test_ctypes fails on AIX with xlc

Michael Felt added the comment: I'll get to this asap. Have to install a new "clean" environment aka a new virtual machine. On 18-Aug-16 02:43, Martin Panter wrote: > Martin Panter added the comment: > > Michael, byref() is just a helper for passing an object’s address to a C > function.

[issue27817] tkinter string variable misinterpreted as boolean

Andreas Bolsch added the comment: I'm afraid I don't know Tcl nor python good enough to be able to strip this down to a reasonably simple test case. However, I wonder what's going on there: When the Tcl variable holding the radiobutton's value contains "x", "z", ..., value->typePtr always

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

Michael Felt added the comment: The more common TESTED "behavior" issue is simply: find_library("c") always returns None while it should be returning either libc.a(shr.o) in 32-bit mode and libc.a(shr_64.o) in 64-bit mode. If that gets corrected, then adding RTLD_MEMBER it's numerical

[issue27824] update ConfigParser docs regarding in-line comments

New submission from Joshua Haas: Originally reported at http://bugs.python.org/issue27762 as a behavior bug but was determined to be won't fix. Thus I think this needs to be mentioned in the documentation at https://docs.python.org/2/library/configparser.html I propose that directly after the

[issue26984] int() can return not exact int instance

Roundup Robot added the comment: New changeset 81f229262921 by Serhiy Storchaka in branch 'default': Issue #26984: int() now always returns an instance of exact int. https://hg.python.org/cpython/rev/81f229262921 -- nosy: +python-dev ___ Python

[issue27823] Change bare AttributeError messages to be more informative

Changes by Xiang Zhang : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list

[issue26488] hashlib command line interface

Antonio Valentino added the comment: Hi all, please note that to stay compatible with the GNU md5sum utility you should print the file name prefixed by a "*" if you read the file in binary mode. Also when digests is checked, files to check should be opened in binary or text mode according the

[issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection

Tom Tanner added the comment: will the fix be backported to 2.7? -- ___ Python tracker ___ ___

[issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection

Changes by Berker Peksag : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue27794] setattr a read-only property; the AttributeError should show the attribute that failed

Emanuel Barry added the comment: Opened #27823 as a followup to this, and carried nosy list over. -- ___ Python tracker ___

[issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection

Roundup Robot added the comment: New changeset 45ef062734d6 by Berker Peksag in branch '3.5': Issue #21718: cursor.description is now available for queries using CTEs https://hg.python.org/cpython/rev/45ef062734d6 New changeset cf18375732ae by Berker Peksag in branch 'default': Issue #21718:

[issue27823] Change bare AttributeError messages to be more informative

New submission from Emanuel Barry: Attached patch changes bare attribute errors to add a useful error message. As such, `raise AttributeError` and `raise AttributeError(None)` (but not `raise AttributeError('')` for example) inside any of the attribute lookup or descriptor methods

Re: The Joys Of Data-Driven Programming

On Sunday, August 21, 2016 at 7:50:39 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > >> > All I can say is that I've encountered numerous bad cases of rule > >> > systems, eg: > >> > > >> > - iptables > >> > > >> > - selinux policies > >> > > >> > - systemd unit files > >> > > >> > -

[issue27746] ResourceWarnings in test_asyncio

Paul McGuire added the comment: Ok, I will submit as a separate issue. -- ___ Python tracker ___ ___

[issue27746] ResourceWarnings in test_asyncio

Xiang Zhang added the comment: The patch I submitted is about to solve the resource leak in the test suite. Paul, your problem seems to need other triage. -- ___ Python tracker

Re: The Joys Of Data-Driven Programming

Rustom Mody : >> > All I can say is that I've encountered numerous bad cases of rule >> > systems, eg: >> > >> > - iptables >> > >> > - selinux policies >> > >> > - systemd unit files >> > >> > - asterisk >> > >> > - sendmail > [...] > Some other examples: > 1. >

[issue27821] IDLE custom keymaps don't work anymore (Windows, Python 3.6.0a3)

Vedran Čačić added the comment: Windows 10. No, I jumped from .0a1 to .0a3. Now I installed .0a4 and have the same problem. I'm afraid of going back to .0a2, was taught long ago to never downgrade anything. :-) But I have 3.5.1 installed separately, and its IDLE keeps working without problem.

[issue27539] negative Fraction ** negative int not normalized

Serhiy Storchaka added the comment: LGTM. -- nosy: +serhiy.storchaka stage: -> commit review ___ Python tracker ___

Re: The Joys Of Data-Driven Programming

On Sunday, August 21, 2016 at 5:51:36 PM UTC+5:30, Chris Angelico wrote: > On Sun, Aug 21, 2016 at 9:53 PM, Rustom Mody wrote: > > Some other examples: > > 1. > > Aren’t makefiles data-driven? And if so should not much more declarative > > attempts like jam have been correspondingly more

Re: The Joys Of Data-Driven Programming

On Sun, Aug 21, 2016 at 9:53 PM, Rustom Mody wrote: > Some other examples: > 1. > Aren’t makefiles data-driven? And if so should not much more declarative > attempts like jam have been correspondingly more successful? > https://www.perforce.com/resources/documentation/jam >

[issue27821] IDLE custom keymaps don't work anymore (Windows, Python 3.6.0a3)

Terry J. Reedy added the comment: I use a custom key set also and have no problem before or after the Modern Unux patch (else I would not have applied it ;-). Did you have .0a2 installed? Which Windows? What I have in config-main.cfg is [Keys] default = False name = Terry [Theme]

Re: The Joys Of Data-Driven Programming

On Sunday, August 21, 2016 at 5:13:28 AM UTC+5:30, Lawrence D’Oliveiro wrote: > On Saturday, August 20, 2016 at 8:08:24 PM UTC+12, Marko Rauhamaa wrote: > > > > Lawrence D’Oliveiro: > > > >> On Thursday, August 18, 2016 at 4:47:28 PM UTC+12, Marko Rauhamaa wrote: > >>> > >>> ... as a rule, I

[issue27746] ResourceWarnings in test_asyncio

Changes by Martin Panter : -- stage: needs patch -> patch review ___ Python tracker ___

[issue27810] Add METH_FASTCALL: new calling convention for C functions

Changes by Stefan Behnel : -- nosy: +scoder ___ Python tracker ___ ___

[issue27128] Add _PyObject_FastCall()

Changes by Stefan Behnel : -- nosy: +scoder ___ Python tracker ___ ___

[issue27822] Fail to create _SelectorTransport with unbound socket

Paul McGuire added the comment: (issue applies to both 3.5.2 and 3.6) -- versions: +Python 3.5 ___ Python tracker ___

[issue27746] ResourceWarnings in test_asyncio

Paul McGuire added the comment: I was about to report this same issue - I get the error message even though I explicitly call transport.close(): C:\Python35\lib\asyncio\selector_events.py:582: ResourceWarning: unclosed transport <_SelectorDatagramTransport closing fd=232> It looks like the

[issue27822] Fail to create _SelectorTransport with unbound socket

Paul McGuire added the comment: To clarify how I'm using a socket without a bound address, I am specifying the destination address in the call to transport.sendto(), so there is no address on the socket itself, hence getsockname() fails. -- ___

[issue26984] int() can return not exact int instance

Changes by Mark Dickinson : -- assignee: mark.dickinson -> serhiy.storchaka stage: patch review -> commit review ___ Python tracker

[issue27822] Fail to create _SelectorTransport with unbound socket

New submission from Paul McGuire: In writing a simple UDP client using asyncio, I tripped over a call to getsockname() in the _SelectorTransport class in asyncio/selector_events.py. def __init__(self, loop, sock, protocol, extra=None, server=None): super().__init__(extra, loop)

[issue26984] int() can return not exact int instance

Mark Dickinson added the comment: The patch LGTM. I'm still in two minds about whether `__trunc__` should be required to return a strict `int`, but for now it's probably better to go with the status quo. -- ___ Python tracker

[issue27821] IDLE custom keymaps don't work anymore (Windows, Python 3.6.0a3)

New submission from Vedran Čačić: I had a custom keymap in IDLE. Since I installed 3.6.0a3, it doesn't work anymore. Worse, I cannot switch to anything except "IDLE Classic Windows" - Apply does nothing, but when I click OK, it doesn't switch. I suppose

[issue25604] [Minor] bug in integer true division algorithm

Mark Dickinson added the comment: Fixed for 2.7 and 3.6. I don't think it's worth backporting the fix to 3.5 without evidence of actual incorrect results arising from this bug. -- resolution: -> fixed stage: -> resolved status: open -> closed ___

[issue25604] [Minor] bug in integer true division algorithm

Roundup Robot added the comment: New changeset 370bbeba21b3 by Mark Dickinson in branch '2.7': Issue #25604: Fix bug in integer true division that could have resulted in off-by-one-ulp results in unusual cases. https://hg.python.org/cpython/rev/370bbeba21b3 --

[issue27539] negative Fraction ** negative int not normalized

Mark Dickinson added the comment: > How/when does this appear in 3.6 line? After allowing a couple of days for review, I'll commit the issue_27539_fix patch to the 3.5 branch, then immediately merge it to the 3.6 "default" branch. So that fix should appear in the upcoming 3.6 beta1.

[issue27539] negative Fraction ** negative int not normalized

Mark Dickinson added the comment: > Do I report a new issue and refer to this one? Sure, that would work. A patch that included the change and a test that checks that `Fraction(3, 4, True)` raises TypeError would be good, too. -- ___ Python tracker

[issue27539] negative Fraction ** negative int not normalized

Vedran Čačić added the comment: > it's independent of the fix, and should probably be a 3.6-only change. Fair enough. Two questions: How/when does this appear in 3.6 line? I guess there is a standard timeline of how bugfixes are "forwardported", but I don't know what it is. How do I make the

[issue25604] [Minor] bug in integer true division algorithm

Roundup Robot added the comment: New changeset b9e12ca6fdb6 by Mark Dickinson in branch 'default': Issue #25604: Fix minor bug in integer true division, which could https://hg.python.org/cpython/rev/b9e12ca6fdb6 -- nosy: +python-dev ___ Python

[issue27539] negative Fraction ** negative int not normalized

Mark Dickinson added the comment: Here's a patch (against the 3.5 tip). I've dropped the keyword-only `_normalize` change; I have no objections to that change, but it's independent of the fix, and should probably be a 3.6-only change. -- Added file:

  1   2   >