[issue24160] Pdb sometimes crashes when trying to remove a breakpoint defined in a different debugger sessoon
Xavier de Gaye added the comment:
I can reproduce the problem on python 3.5 with test3.py as:
def foo():
foo = 7789
bar = 7788
$ python
Python 3.5.0a4+ (default:8bac00eadfda, May 6 2015, 17:40:12)
[GCC 4.9.2 20150304 (prerelease)] on linux
Type help, copyright, credits or license for more information.
import pdb, test3
pdb.run('test3.foo()')
string(1)module()
(Pdb) step
--Call--
/home/xavier/tmp/test3.py(1)foo()
- def foo():
(Pdb) break 3
Breakpoint 1 at /home/xavier/tmp/test3.py:3
(Pdb) continue
/home/xavier/tmp/test3.py(3)foo()
- bar = 7788
(Pdb) continue
pdb.run('test3.foo()')
string(1)module()
(Pdb) step
--Call--
/home/xavier/tmp/test3.py(1)foo()
- def foo():
(Pdb) break # 'break' lists no breakpoints.
(Pdb) break 2
Breakpoint 2 at /home/xavier/tmp/test3.py:2
(Pdb) break # 'break' lists two breakpoints.
Num Type Disp Enb Where
1 breakpoint keep yes at /home/xavier/tmp/test3.py:3
breakpoint already hit 1 time
2 breakpoint keep yes at /home/xavier/tmp/test3.py:2
(Pdb)
On the second debugging session, the first 'break' command lists no
breakpoints, while the second 'break' command lists two breakpoints including
the one set in the first debugging session.
The problem is that the 'breaks' attribute of the Pdb instance is inconsistent
with the 'bplist' and 'bpbynumber' class attributes of the bdb.Breakpoint
class when the second debugging session is started.
--
nosy: +xdegaye
versions: +Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24160
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24195] Add `Executor.filter` to concurrent.futures
Paul Moore added the comment: Just as a note - to test a pure Pthon patch like this, you can apply the patch to your installed Python 3.4 installation, and just run the test using that. There should be no need to build your own Python. python C:\Apps\Python34\Lib\test\test_concurrent_futures.py test_cancel (__main__.FutureTests) ... ok test_cancelled (__main__.FutureTests) ... ok test_done (__main__.FutureTests) ... ok test_done_callback_already_cancelled (__main__.FutureTests) ... ok test_done_callback_already_failed (__main__.FutureTests) ... ok test_done_callback_already_successful (__main__.FutureTests) ... ok [... etc] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24129] Incorrect (misleading) statement in the execution model documentation
levkivskyi added the comment: Since no one proposed alternative ideas, I am submitting my proposal as a patch, with the following wording: A class definition is an executable statement that may use and define names. Free variables follow the normal rules for name resolution, while unbound local variables are looked up in the global namespace. The namespace of the class definition becomes the attribute dictionary of the class. Names defined at the class scope are not visible in methods -- keywords: +patch Added file: http://bugs.python.org/file39383/classdoc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24129 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24013] Improve os.scandir() and DirEntry documentation
STINNER Victor added the comment: 8. Added Availability: Unix, Windows. to scandir docs like listdir and most other os functions have. That's wrong: availability should only be explained when a function is not always available. os.listdir() and os.scandir() are always available. I made the opposite change: I removed the availability information from os.listdir() and many other os functions in the changeset 77ebd3720284. Thanks Ben, I applied your patch (except of the Availability line). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24013 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24187] del statement documentation doesn't mention name binding behaviour
Jon added the comment: Sorry, I think I just misread this section. I was confused by the fact that del binds names like assignment does, so that the following tries to delete a local name and fails: x = 1 def f(): del x f() In fact the documentation does say that there must be global statement in the block for del to delete a global name, so my bad. -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24187 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24130] Remove -fno-common compile option from OS X framework builds?
Ronald Oussoren added the comment: According to [1] common symbols are not allowed in frameworks. I guess that's why we added '-fno-common' to the linker flags. [1] https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkBinding.html#//apple_ref/doc/uid/20002256-BAJICBDD -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22547] Implement an informative `BoundArguments.__repr__`
Serhiy Storchaka added the comment:
May be omit names for positionalarguments?
def foo(a, *args, b=10, **kwargs): pass
...
inspect.signature(foo).bind(1, 2, 3, b=4, c=5)
BoundArguments at 0xb6eee9ec (a=1, args=(2, 3), b=4, kwargs={'c': 5})
I think it would look better as:
BoundArguments (1, 2, 3, b=4, c=5)
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22547
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24195] Add `Executor.filter` to concurrent.futures
Ram Rachum added the comment: Patch with documentation attached. (I don't know how to concatenate patches, so 2.patch contains only the documentation, while 1.patch has the implementation and the tests (but Ethan's patch is better.)) Brian, regarding your simpler implementation based on `Executor.map`: It looks good to me, but I'm not sure if it passes the tests. If it does then I don't mind if that's the implementation that would be used. -- Added file: http://bugs.python.org/file39381/2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24195] Add `Executor.filter` to concurrent.futures
Antoine Pitrou added the comment: This feature looks unnecessary to me as well. Adding features has a non-zero cost in maintenance. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English
Ronald Oussoren added the comment: Dimitry's patch looks good, I added my patch before checking if there already is patch. The only thing that might be cause discussion is when to accept 'UTF-8' as a valid locale name. My patch only accepts in on OSX, while Dimitry's patch accepts it everywwhere. Writing this I'm slightly in favour of Dimitry's approach: I quite often run into problems when using SSH to log in to a Linux box from my OSX laptop (with LC_CTYPE=UTF-8). Almost everything works correctly, except for Python code that uses the locale module (which craps out with the exception in the first message in this issue). IMHO Dimitry's patch should be applied as is. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18378 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24200] Redundant id in informative reprs
New submission from Serhiy Storchaka: import inspect def foo(a, *, b=10): pass ... inspect.signature(foo) Signature at 0xb6e2768c (a, *, b=10) I think the id is not needed in informative repr if you implemented __eq__. Identity doesn't matter if different instances can be equal. The id in the repr only adds a noise. -- components: Library (Lib) messages: 243247 nosy: serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: Redundant id in informative reprs type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24200 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24201] _winreg PyHKEY Type Confusion
New submission from JohnLeitch:
The Python _winreg module suffers from a type confusion vulnerability wherein
pointers can be passed directly in place of PyHKEY instances e.g.
_winreg.QueryValue(0x41414141, )
This behavior is due to the underlying PyHKEY_AsHKEY function of _winreg.c:
BOOL
PyHKEY_AsHKEY(PyObject *ob, HKEY *pHANDLE, BOOL bNoneOK)
{
if (ob == Py_None) {
if (!bNoneOK) {
PyErr_SetString(
PyExc_TypeError,
None is not a valid HKEY in this context);
return FALSE;
}
*pHANDLE = (HKEY)0;
}
else if (PyHKEY_Check(ob)) {
PyHKEYObject *pH = (PyHKEYObject *)ob;
*pHANDLE = pH-hkey;
}
else if (PyInt_Check(ob) || PyLong_Check(ob)) { if ob is an
int/long, this path is taken.
/* We also support integers */
PyErr_Clear();
*pHANDLE = (HKEY)PyLong_AsVoidPtr(ob); ob is casted to a void*
here
if (PyErr_Occurred())
return FALSE;
}
else {
PyErr_SetString(
PyExc_TypeError,
The object is not a PyHKEY object);
return FALSE;
}
return TRUE;
}
When *ob is an integer or long, the function casts it to a void*. This behavior
can be triggered using many of the _winreg functions, such as QueryValue,
QueryValueEx, EnumValue, etc.
0:000 r
eax=41414140 ebx=0027fbc8 ecx= edx= esi=770e351e edi=
eip=74bf9af3 esp=0027f738 ebp=0027f764 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
RPCRT4!NDRCContextBinding+0x13:
74bf9af3 81780498badcfe cmp dword ptr [eax+4],0FEDCBA98h
ds:002b:41414144=
0:000 k
ChildEBP RetAddr
0027f764 74c0390c RPCRT4!NDRCContextBinding+0x13
0027f774 74c86dce RPCRT4!ExplicitBindHandleMgr+0x33
0027fba8 770e625c RPCRT4!NdrClientCall2+0x2ea
0027fbc0 771041e2 ADVAPI32!SafeBaseRegQueryInfoKey+0x24
0027fc04 76eacdca ADVAPI32!RemoteRegQueryInfoKeyWrapper+0x42
0027fcbc 1e0de85c KERNELBASE!LocalOpenPerformanceText+0x1c60
0027fd14 1e0ac6fc python27!PyEnumValue+0x6c [c:\build27\cpython\pc\_winreg.c @
1213]
0027fd58 1e0efabf python27!_PyObject_GenericGetAttrWithDict+0x12c
[c:\build27\cpython\objects\object.c @ 1428]
0027fde8 1e0f27eb python27!PyEval_EvalFrameEx+0x1cdf
[c:\build27\cpython\python\ceval.c @ 2269]
0027fe00 1e0f11b2 python27!compiler_free+0x3b
[c:\build27\cpython\python\compile.c @ 322]
0027fe2c 1e11707a python27!PyEval_EvalCode+0x22
[c:\build27\cpython\python\ceval.c @ 672]
0027fe44 1e1181c5 python27!run_mod+0x2a [c:\build27\cpython\python\pythonrun.c
@ 1371]
0027fe64 1e118760 python27!PyRun_FileExFlags+0x75
[c:\build27\cpython\python\pythonrun.c @ 1358]
0027fea4 1e1190d9 python27!PyRun_SimpleFileExFlags+0x190
[c:\build27\cpython\python\pythonrun.c @ 950]
0027fec0 1e038d35 python27!PyRun_AnyFileExFlags+0x59
[c:\build27\cpython\python\pythonrun.c @ 753]
0027ff3c 1d00116d python27!Py_Main+0x965 [c:\build27\cpython\modules\main.c @
643]
0027ff80 74d57c04 python!__tmainCRTStartup+0x10f
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586]
0027ff94 7741ad1f KERNEL32!BaseThreadInitThunk+0x24
0027ffdc 7741acea ntdll!__RtlUserThreadStart+0x2f
0027ffec ntdll!_RtlUserThreadStart+0x1b
0:000 !analyze -v
***
* *
*Exception Analysis *
* *
***
FAULTING_IP:
RPCRT4!NDRCContextBinding+13
74bf9af3 81780498badcfe cmp dword ptr [eax+4],0FEDCBA98h
EXCEPTION_RECORD: -- (.exr 0x)
ExceptionAddress: 74bf9af3 (RPCRT4!NDRCContextBinding+0x0013)
ExceptionCode: c005 (Access violation)
ExceptionFlags:
NumberParameters: 2
Parameter[0]:
Parameter[1]: 41414144
Attempt to read from address 41414144
CONTEXT: -- (.cxr 0x0;r)
eax=41414140 ebx=0027fbc8 ecx= edx= esi=770e351e edi=
eip=74bf9af3 esp=0027f738 ebp=0027f764 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
RPCRT4!NDRCContextBinding+0x13:
74bf9af3 81780498badcfe cmp dword ptr [eax+4],0FEDCBA98h
ds:002b:41414144=
FAULTING_THREAD: 0274
DEFAULT_BUCKET_ID: INVALID_POINTER_READ
PROCESS_NAME: python.exe
ERROR_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1:
EXCEPTION_PARAMETER2: 41414144
READ_ADDRESS: 41414144
FOLLOWUP_IP:
[issue22547] Implement an informative `BoundArguments.__repr__`
Serhiy Storchaka added the comment: Here is an implementation. -- keywords: +patch Added file: http://bugs.python.org/file39380/BoundArguments_repr_alt.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22547 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23085] update internal libffi copy to 3.2.1
Marc-Andre Lemburg added the comment: issue23042 is fixed now. libffi 3.2.1 apparently has the same issue, so the issue23042 patch would probably have to be reapplied (slightly modified, though). Seeing that libffi has had a major compilation problem breaking it on at least FreeBSD and most probably a lot of other x86 based systems as well, I don't really have much confidence in the libffi maintenance, so the usual latest is the greatest may not be the best approach. Are there any issue *we* have with libffi which an update to 3.2.1 would solve ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English
Changes by Ronald Oussoren ronaldousso...@mac.com: Added file: http://bugs.python.org/file39384/issue-18378-py27.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18378 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English
Changes by Ronald Oussoren ronaldousso...@mac.com: Added file: http://bugs.python.org/file39385/issue-18378-py35.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18378 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15582] Enhance inspect.getdoc to follow inheritance chains
Martin Panter added the comment: getdoc-news.patch suggests some wording to add to What’s New, and also adds a “Changed in version 3.5” note to inspect.getdoc(). BTW I also noticed that the class doc strings are not inherited from object.__doc__, although method doc strings _are_ inherited from object(), such as object.__init__.__doc__. The current documentation suggests that the class doc string “The most base type” should also be inherited. $ cat module.py class SomeClass: '''CLASS DOCSTRING''' def __init__(self): '''METHOD DOCSTRING''' $ ./python -m pydoc module.SomeClass # Doc strings intact [. . .] module.SomeClass = class SomeClass(builtins.object) | CLASS DOCSTRING | | Methods defined here: | | __init__(self) | METHOD DOCSTRING | [. . .] $ ./python -OOm pydoc module.SomeClass # Method inherited, class stripped [. . .] module.SomeClass = class SomeClass(builtins.object) | Methods defined here: | | __init__(self) | Initialize self. See help(type(self)) for accurate signature. | [. . .] I also wonder how well this feature would work when someone tries to override a base method by using a mix-in type class. -- Added file: http://bugs.python.org/file39379/getdoc-news.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15582 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24013] Improve os.scandir() and DirEntry documentation
Roundup Robot added the comment: New changeset e7c7431f91b2 by Victor Stinner in branch 'default': Closes #24013: Improve os.scandir() and DirEntry documentation https://hg.python.org/cpython/rev/e7c7431f91b2 -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24013 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24199] Idle: remove idlelib.idlever.py and its use in About dialog
Serhiy Storchaka added the comment: Are there third-party IDLE plugins? If yes, this change can break them. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24202] Multiprocessing Pool not working for userdefined function
Abhishek Manandhar added the comment: Yes actually it produce no erroe on standalone script. But the script executes without any outputs. not even for numpy function. I used code below in script. import multiprocessing import numpy def f(x): return x*x if __name__ = __main__: p= multiprocessing.Pool(5) print p.map(numpy.sqrt,[1,2,3,4]) print p.map(f,[1,2,3,4]) On May 15, 2015 2:52 PM, Paul Moore rep...@bugs.python.org wrote: Paul Moore added the comment: Multiprocessing works by firing up additional processes. Those processes won't have access to functions defined in the interactive interpreter. Can you reproduce this problem in a standalone script? I suspect not, but if you can please post the script here. Marking as not a bug, but I haven't closed it yet in case a script reproducing the issue can be provided. -- nosy: +paul.moore resolution: - not a bug ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24202 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24202 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24033] Update _test_multiprocessing.py to use script helpers
Changes by Davin Potts pyt...@discontinuity.net: -- stage: - patch review type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24033 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23699] Add a macro to ease writing rich comparisons
Petr Viktorin added the comment: What can I, not a core developer, do to resolve this disagreement? Should I submit a PEP? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24202] Multiprocessing Pool not working for userdefined function
Paul Moore added the comment: Multiprocessing works by firing up additional processes. Those processes won't have access to functions defined in the interactive interpreter. Can you reproduce this problem in a standalone script? I suspect not, but if you can please post the script here. Marking as not a bug, but I haven't closed it yet in case a script reproducing the issue can be provided. -- nosy: +paul.moore resolution: - not a bug ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24202 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24198] please align the platform tag for windows
Paul Moore added the comment: So just to be clear - this proposal would *only* affect the tagged filename used for loading .pyd files? (And in practice, the untagged form is normally used for Windows .pyd files anyway...) -- nosy: +paul.moore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24198 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24202] Multiprocessing Pool not working for userdefined function
New submission from Abhishek Manandhar: I was looking to implement multiprocess pool. It worked fine with the numpy function while with the user defined function it ran into error. import numpy import multiprocessing P = multiprocessing.Pool(5) P.map(numpy.sqrt,range(50)) [0.0, 1.0, 1.4142135623730951, 1.7320508075688772, 2.0, 2.2360679774997898, 2.4494897427831779, 2.6457513110645907, 2.8284271247461903, 3.0, 3.1622776601683795, 3.3166247903553998, 3.4641016151377544, 3.6055512754639891, 3.7416573867739413, 3.872983346207417, 4.0, 4.1231056256176606, 4.2426406871192848, 4.358898943540674, 4.4721359549995796, 4.5825756949558398, 4.6904157598234297, 4.7958315233127191, 4.8989794855663558, 5.0, 5.0990195135927845, 5.196152422706632, 5.2915026221291814, 5.3851648071345037, 5.4772255750516612, 5.5677643628300215, 5.6568542494923806, 5.7445626465380286, 5.8309518948453007, 5.9160797830996161, 6.0, 6.0827625302982193, 6.164414002968976, 6.2449979983983983, 6.324555320336759, 6.4031242374328485, 6.4807406984078604, 6.5574385243020004, 6.6332495807107996, 6.7082039324993694, 6.7823299831252681, 6.8556546004010439, 6.9282032302755088, 7.0] def f(x): return x*x P.map(f, range(50)) Exception in thread Thread-2: Traceback (most recent call last): File C:\Python27\lib\threading.py, line 530, in __bootstrap_inner self.run() File C:\Python27\lib\threading.py, line 483, in run self.__target(*self.__args, **self.__kwargs) File C:\Python27\lib\multiprocessing\pool.py, line 285, in _handle_tasks put(task) TypeError: expected string or Unicode object, NoneType found -- components: Windows messages: 243266 nosy: abheeman, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Multiprocessing Pool not working for userdefined function type: crash versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24202 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24202] Multiprocessing Pool not working for userdefined function
Changes by Davin Potts pyt...@discontinuity.net: -- nosy: +davin type: crash - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24202 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24202] Multiprocessing Pool not working for userdefined function
Paul Moore added the comment:
OK, if it's not reproducible in a standalone script, I'll close this as it's
expected behaviour.
Correcting the typo in your script (__name__ == __main__), I ran it and it
worked as expected on my system:
type multi.py
import multiprocessing
import numpy
def f(x):
return x*x
if __name__ == __main__:
p= multiprocessing.Pool(5)
print(p.map(numpy.sqrt,[1,2,3,4]))
print(p.map(f,[1,2,3,4]))
PS 15:05 {00:00.089} C:\Work\Scratch
py .\multi.py
[1.0, 1.4142135623730951, 1.7320508075688772, 2.0]
[1, 4, 9, 16]
I'm not sure why you weren't getting output, but it doesn't look like a Python
issue.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24202
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24195] Add `Executor.filter` to concurrent.futures
Ethan Furman added the comment: Short History: = (Ram Rachum) What do you think about adding a method: `Executor.filter`? I was using something like this: my_things = [thing for thing in things if some_condition(thing)] But the problem was that `some_condition` took a long time to run waiting on I/O, which is a great candidate for parallelizing with ThreadPoolExecutor. I made it work using `Executor.map` and some improvizing, but it would be nicer if I could do: with concurrent.futures.ThreadPoolExecutor(100) as executor: my_things = executor.filter(some_condition, things) And have the condition run in parallel on all the threads. (Nick Coughlan) I think this is sufficiently tricky to get right that it's worth adding filter() as a parallel to the existing map() API. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24162] [2.7 regression] test_asynchat test failure on i586-linux-gnu
Roundup Robot added the comment: New changeset 7adfc99103d2 by Benjamin Peterson in branch '2.7': deque is not varsized, so using Py_SIZE is nonsensical (closes #24162) https://hg.python.org/cpython/rev/7adfc99103d2 -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24114] ctypes.utils uninitialized variable 'path'
Martin Panter added the comment: I fail to see how this patch does anything. What is the actual error or traceback? Perhaps it is for “paths” (plural)? -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error
STINNER Victor added the comment: You should see the new file in the next 30 minutes. I don't see the new file. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23840 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24064] Make the property doctstring writeable
Roundup Robot added the comment: New changeset 5262dd507ee5 by Raymond Hettinger in branch 'default': Issue #24064: Docuement that oroperty docstrings are now writeable. https://hg.python.org/cpython/rev/5262dd507ee5 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24064 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24204] string.strip() documentation is misleading
R. David Murray added the comment:
Indeed, the sentence that confused you was added because people were
continually confused by the fact that doing:
'foo.boo'.strip('.boo')
would result in 'f' rather than 'foo'.
We would welcome an improvement, but apparently this is very hard to make clear.
Repeating the mississippi example is probably a good idea.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24204
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24205] signature.bind error messages are sub-optimal
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24205 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24205] signature.bind error messages are sub-optimal
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24205 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24192] unexpected system error with pep420 style namespace packages
Changes by Eric Snow ericsnowcurren...@gmail.com: -- assignee: - eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse required arguments displayed under optional arguments
Martin Panter added the comment: Is there any interest in my or Ryan’s patches, which change the default heading away from “optional arguments”? Changing the default is my preferred fix, but if others don’t like it (e.g. compatibility concerns), I am happy to work on a documentation patch according to https://bugs.python.org/issue9694#msg132327. I don’t see how adding an extra help groups API is very helpful though. The problem here is that the default help group headings are wrong (or at least misleading to many people). -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24192] unexpected system error with pep420 style namespace packages
Eric Snow added the comment: Here's a fix. If I don't hear from anyone right away I'll push it in a few hours (or tomorrow morning). -- keywords: +patch stage: - patch review Added file: http://bugs.python.org/file39386/issue24192.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24205] signature.bind error messages are sub-optimal
New submission from R. David Murray:
I have an application where I'm calling a handler function with passed in
arguments. I want to generate an error if the handler is called with the wrong
arguments. I can't just catch TypeError since a TypeError could easily result
from some programming error in the handler, rather than an error in the calling
args. So, doing this seems obvious:
sig = signature(handler)
try:
bound = sig.bind(message, payload, *args, **kw)
except TypeError as exc:
print(Invalid handler call: {}.format(str(exc))
handler(*bound.args, **bound.kwargs)
Now, suppose I have a function like:
def foo(message, payload, anarg, akeyword='bar'):
pass
If I call it directly with an invalid keyword argument I get:
foo(1, 2, 3, badword=7)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: foo() got an unexpected keyword argument 'badword'
However, bind gives me:
sig.bind(1, 2, 3, badword=7)
Traceback (most recent call last):
File stdin, line 1, in module
File /home/rdmurray/python/p35/Lib/inspect.py, line 2818, in bind
return args[0]._bind(args[1:], kwargs)
File /home/rdmurray/python/p35/Lib/inspect.py, line 2809, in _bind
raise TypeError('too many keyword arguments')
TypeError: too many keyword arguments
Similarly, for a missing argument I get:
foo(1, 2)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: foo() missing 1 required positional argument: 'anarg'
While bind gives:
sig.bind(1, 2)
Traceback (most recent call last):
File stdin, line 1, in module
File /home/rdmurray/python/p35/Lib/inspect.py, line 2818, in bind
return args[0]._bind(args[1:], kwargs)
File /home/rdmurray/python/p35/Lib/inspect.py, line 2737, in _bind
raise TypeError(msg) from None
TypeError: 'anarg' parameter lacking default value
So, using this to replace catching the TypeError from incorrectly calling a
function does not work. Nor are the messages in fact accurate. Is there any
chance we could make bind's error handling work like regular function binding?
That's certainly what I expected would happen!
--
components: Library (Lib)
messages: 243287
nosy: r.david.murray, yselivanov
priority: normal
severity: normal
status: open
title: signature.bind error messages are sub-optimal
type: behavior
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24205
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: -haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24192] unexpected system error with pep420 style namespace packages
Changes by Brett Cannon br...@python.org: -- priority: normal - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23699] Add a macro to ease writing rich comparisons
Raymond Hettinger added the comment: You don't need a PEP. If Barry and Marc-Andre want this to go forward, I won't hold it back. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24201] _winreg PyHKEY Type Confusion
eryksun added the comment: wherein pointers can be passed directly in place of PyHKEY instances e.g. _winreg.QueryValue(0x41414141, ) If a debugger is attached you see the first-chance exception for the access violation. Normally the registry function simply returns ERROR_INVALID_HANDLE (6), which gets raised as an OSError in Python. The call took the RPC path because the low bit (1) marks a remote handle, which is actually a pointer to a data structure. RPCRT4!NDRCContextBinding looks for a signature (0xFEDCBA98) to validate this structure. In this case the attempt raised an access violation, which gets handled by raising another exception with the exception code set to ERROR_INVALID_HANDLE. The same exception gets raised if it can't validate the handle. Subsequently this exception is handled by calling RPCRT4!NdrClientMapCommFault to map the code to a return value. For example (x64 ISA): _winreg.QueryInfoKey(0x41414141) (a2c.828): Access violation - code c005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. RPCRT4!NDRCContextBinding+0x4: 07fe`fefca6e4 81790898badcfe cmp dword ptr [rcx+8],0FEDCBA98h ds:`41414148= 0:000 gN (a2c.828): Unknown exception - code 0006 (first chance) Breakpoint 0 hit RPCRT4!NdrClientMapCommFault: 07fe`ff05f010 fff3pushrbx 0:000 kc 8 Call Site RPCRT4!NdrClientMapCommFault RPCRT4!NdrpClientCall3 RPCRT4!NdrClientCall3 ADVAPI32!SafeBaseRegQueryInfoKey ADVAPI32!RemoteRegQueryInfoKeyWrapper kernel32!TlsGetValue ADVAPI32!RegQueryInfoKeyAStub python27!PyQueryInfoKey The exception code is passed in register r8 and gets assigned to the address in r9: 0:000 r r8, r9 r8=0006 r9=0021f1d8 0:000 dd 21f1d8 l1 `0021f1d8 0:000 pt RPCRT4!NdrClientMapCommFault+0x80: 07fe`ff05f080 c3 ret 0:000 dd 21f1d8 l1 `0021f1d8 0006 This return value gets passed back up the call stack: 0:000 gu; pt; r rax rax=0006 0:000 gu; pt; r rax rax=0006 0:000 gu; pt; r rax rax=0006 0:000 gu; pt; r rax rax=0006 0:000 gu; pt; r rax rax=0006 0:000 r rax=0006 rbx=00e1cda0 rcx= rdx= rsi= rdi=1e1027b0 rip=779ba204 rsp=0021f9d8 rbp=00eb61c8 r8=0021f1d8 r9= r10=0021f1d8 r11=0021f8b0 r12=00e1cda0 r13=00807bb0 r14=1e2b3210 r15=00eb7060 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=0206 kernel32!RegQueryInfoKeyA+0x364: `779ba204 c3 ret Until finally getting raised as a Python exception: 0:000 g Traceback (most recent call last): File stdin, line 1, in module WindowsError: [Error 6] The handle is invalid The odds are extremely low that someone will pass in an integer address that's flagged as a remote handle (ends in 1) and is a valid, mapped address that contains the RPC handle signature. Even then, it won't reference an actual proxy handle for a remote registry, so it'll just fail farther along the chain. I'm sure if a feature exists that someone, somewhere depends on it, so I don't see a reason to change this unless there's a real problem here. Is there a specific technical or security problem that you see here? -- nosy: +eryksun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24201 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17305] IDNA2008 encoding missing
Changes by Christian Heimes li...@cheimes.de: -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24201] _winreg PyHKEY Type Confusion
JohnLeitch added the comment: Thank you for taking the time to peruse my report and explain the behavior I observed. My understanding of Windows RPC internals is lacking, and perhaps I jumped the gun upon catching an AV while fuzzing. That said, after poking around to better understand the matter, I discovered a few things: 1) There are code paths where it is possible to trigger an unhandled access violation: 0:000 g (11a0.d54): Access violation - code c005 (!!! second chance !!!) eax=60dad396 ebx= ecx= edx= esi=00a0 edi=00a0 eip=776f1037 esp=0027f790 ebp=0027f80c iopl=0 nv up ei pl nz ac pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010216 ntdll!RtlAllocateHeap+0x17: 776f1037 8b4344 mov eax,dword ptr [ebx+44h] ds:002b:0044=?? ?? 0:000 k ChildEBP RetAddr 0027f80c 75471731 ntdll!RtlAllocateHeap+0x17 0027f82c 75479616 RPCRT4!AllocWrapper+0x2d 0027f840 75479791 RPCRT4!ThreadSelfHelper+0x16 0027f848 754f6b2a RPCRT4!ThreadSelf+0x18 0027fc74 753a5d94 RPCRT4!NdrClientCall2+0x13a 0027fc8c 7539f48b ADVAPI32!BaseRegGetVersion+0x24 0027fce4 7538dfce ADVAPI32!RegDeleteKeyW+0x14aeb 0027fd00 1e0de533 ADVAPI32!RegDeleteKeyA+0x2e 0027fd18 1e0aafd7 python27!PyDeleteKey+0x53 0027fd30 1e0edd10 python27!PyCFunction_Call+0x47 0027fd5c 1e0f017a python27!call_function+0x2b0 0027fdcc 1e0f1150 python27!PyEval_EvalFrameEx+0x239a 0027fe00 1e0f11b2 python27!PyEval_EvalCodeEx+0x690 0027fe2c 1e11707a python27!PyEval_EvalCode+0x22 0027fe44 1e1181c5 python27!run_mod+0x2a 0027fe64 1e118760 python27!PyRun_FileExFlags+0x75 0027fea4 1e1190d9 python27!PyRun_SimpleFileExFlags+0x190 0027fec0 1e038d35 python27!PyRun_AnyFileExFlags+0x59 0027ff3c 1d00116d python27!Py_Main+0x965 0027ff80 75967c04 python!__tmainCRTStartup+0x10f 0027ff94 7770ad1f KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 7770acea ntdll!__RtlUserThreadStart+0x2f 0027ffec ntdll!_RtlUserThreadStart+0x1b 0:000 This doesn't appear to be outright exploitable for anything beyond DoS, but it does crash the process. 2) Assuming attacker control of the hkey parameter to a _winreg call, I believe it would be possible to leverage the RPC signature check to disclose the location of valid memory such as the RPC module itself, thereby bypassing ASLR. import _winreg _winreg.DeleteKey(0x75469AF1, '') Traceback (most recent call last): File pyshell#13, line 1, in module _winreg.DeleteKey(0x75469AF1, '') WindowsError: [Error 6] The handle is invalid _winreg.DeleteKey(0x75469AF3, '') RESTART 0:000 dd 0x75469AF3 75469af3 98047881 0ffedcba 01d9a085 fc45c700 75469b03 fffe 8fe8008b c2a2 9094 75469b13 90909090 fe90 00ff d400 75469b23 00ff fe00 49d901ff 49d92575 75469b33 06f76875 b2e8 8b000161 47c7e845 75469b43 003c 50478900 00a661e9 09be0f00 75469b53 00a649e9 06f76800 8ee8 68000161 75469b63 06e6 016184e8 90909000 499e5190 0:000 !address 0x75469AF3 Usage: Image Base Address: 75451000 End Address:754fa000 Region Size:000a9000 State: 1000MEM_COMMIT Protect:0020PAGE_EXECUTE_READ Type: 0100MEM_IMAGE Allocation Base:7545 Allocation Protect: 0080PAGE_EXECUTE_WRITECOPY Image Path: C:\WINDOWS\SysWOW64\RPCRT4.dll Module Name:RPCRT4 Loaded Image Name: C:\WINDOWS\SYSTEM32\RPCRT4.dll Mapped Image Name: More info: lmv m RPCRT4 More info: !lmi RPCRT4 More info: ln 0x75469af3 More info: !dh 0x7545 3) Finally, I still suspect it may be possible to achieve memory corruption with this bug, but cannot verify without a better understanding of the structures at play and further analysis. The hypothetical attack goes like this: a) The attacker sprays memory with carefully constructed buffers containing the expected magic numbers at the correct offsets. b) Once memory has been sufficiently sprayed, the attacker triggers the bug with an hkey value that is actually an address predicted to be one of the sprayed structures. c) While working with the attacker controlled buffer, RPC inadvertently corrupts memory. Step C is, of course, dependent on what what fields are available in the structure, and what RPC does with them. Unfortunately I can't find any relevant documentation or code, but in my testing I was able to force different code paths. Some look fruitful, but determining whether they're reachable would be costly time-wise, and it's a bit of a moot point because we're talking about Microsoft's internal implementation, which could change at any point, altering exploitability. Given that, I'd say it's best to err on the side of caution, and assume corruption is possible with the right primitives. --
[issue23184] Unused imports, variables, file in IDLE
Changes by Terry J. Reedy tjre...@udel.edu: -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23184 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23184] Unused imports, variables, file in IDLE
Roundup Robot added the comment: New changeset 8875d7c6a99d by Terry Jan Reedy in branch '2.7': Issue #23184: idle tests, remove unused names and imports. https://hg.python.org/cpython/rev/8875d7c6a99d New changeset 526ce81f700d by Terry Jan Reedy in branch '3.4': Issue #23184: idle tests, remove unused names and imports. https://hg.python.org/cpython/rev/526ce81f700d New changeset 2a56eb5c08cc by Terry Jan Reedy in branch 'default': Merge 3.4 #23184: idle tests, remove unused names and imports. https://hg.python.org/cpython/rev/2a56eb5c08cc -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23184 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23184] Unused imports, variables, file in IDLE
Roundup Robot added the comment: New changeset d50d661a08f5 by Terry Jan Reedy in branch '2.7': Issue #23184: idlelib, remove more unused names and imports. https://hg.python.org/cpython/rev/d50d661a08f5 New changeset 777569dd4bca by Terry Jan Reedy in branch '3.4': Issue #23184: idlelib, remove more unused names and imports. https://hg.python.org/cpython/rev/777569dd4bca New changeset 6c424b06320b by Terry Jan Reedy in branch 'default': Merge with 3.4 Issue #23184: idlelib, remove more unused names and imports. https://hg.python.org/cpython/rev/6c424b06320b -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23184 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24192] unexpected system error with pep420 style namespace packages
Changes by Eric Snow ericsnowcurren...@gmail.com: -- resolution: - fixed stage: patch review - resolved status: open - pending type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24192] unexpected system error with pep420 style namespace packages
Roundup Robot added the comment: New changeset 46b2c99121f5 by Eric Snow in branch 'default': Issue #24192: Fix namespace package imports. https://hg.python.org/cpython/rev/46b2c99121f5 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19915] int.bit_at(n) - Accessing a single bit in O(1)
anon added the comment: I'm struggling to get time for this. I hope someone else can take responsibility. Sorry :-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24200] Redundant id in informative reprs
Roundup Robot added the comment: New changeset d72d31f4b69a by Yury Selivanov in branch 'default': inspect: Remove 0x... IDs from Signature objects' __repr__ https://hg.python.org/cpython/rev/d72d31f4b69a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24200 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24195] Add `Executor.filter` to concurrent.futures
Ethan Furman added the comment: That comment was from an email by Nick, not to Nick. But now I've added him. ;) -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24200] Redundant id in informative reprs
Roundup Robot added the comment: New changeset f23d0a4278aa by Yury Selivanov in branch 'default': Issue 24200: Fix broken unittest. https://hg.python.org/cpython/rev/f23d0a4278aa -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24200 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24200] Redundant id in informative reprs
Changes by Yury Selivanov yseliva...@gmail.com: -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24200 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24204] string.strip() documentation is misleading
New submission from Jim:
This probably applies to all versions with the strip() method, but I'm using
3.4. Section 4.7.1 of the documentation has a poorly worded description/example
for the behaviour of string.strip([chars]).
A casual reading of The chars argument is not a prefix or suffix; rather, all
combinations of its values are stripped lead me to believe this
'0.0'.strip('.')
'0.0'
should be equivalent to the solution I found later
'0.0'.replace('.', '')
'00'
The bit about [chars] requires recursive thinking (are _stripped_) and clouds
the fact that strip() iterates from beginning and end, discarding characters
until it reaches a character that isn't in [chars].
In the example, it's not obvious (or wasn't to me) that the 'm' wasn't removed
from 'example', and the missing periods gave the impression that they had been
removed from the middle of the string instead of iterated to from the ends.
I can't think of a good way to rewrite the description, but perhaps you could
borrow an example from rstrip() and add/replace:
'mississippi'.strip('mip')
'ssiss'
The glaring existence of that 'i' in the middle, when all others have been
removed makes the limitation clear.
'hello world'.strip()
'hello world'
Makes another good example.
Just trying to save someone else 20 minutes of confusion.
--
assignee: docs@python
components: Documentation
messages: 243283
nosy: PhoenixofMT, docs@python
priority: normal
severity: normal
status: open
title: string.strip() documentation is misleading
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24204
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22547] Implement an informative `BoundArguments.__repr__`
Yury Selivanov added the comment: Actually, I like the current repr (minus the object ID, I'll update the code). The thing about BoundArguments is that '.arguments' is the main property. You use it to add more stuff to *args **kwargs, or to add/remove positional/keyword arguments. Seeing a flattened call signature in the repr won't help you with debugging. Perhaps, we can implement __str__ using your approach. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22547 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24200] Redundant id in informative reprs
Yury Selivanov added the comment: Agree. Let's remove them. I'll update the code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24200 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24195] Add `Executor.filter` to concurrent.futures
Antoine Pitrou added the comment: (Nick Coughlan) Nick Coghlan isn't currently on this issue. Unless you were talking about another, separate Nick Coughlan that I don't know of? :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24195] Add `Executor.filter` to concurrent.futures
Antoine Pitrou added the comment: But to answer your argument: I think this is sufficiently tricky to get right that it's worth adding filter() as a parallel to the existing map() API. Tricky to get right is not a good criterion. The question is whether it's useful or not. Only the OP has had that need AFAIK. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24203] Depreciate threading.Thread.isDaemon etc
New submission from anon: In threading.Thread isDaemon, setDaemon, getName, setName are not needed since 2.6 (preferring directly changing daemon or name instead). They should probably be depreciated in 3.5 and removed later. isAlive has already been removed. -- messages: 243277 nosy: anon priority: normal severity: normal status: open title: Depreciate threading.Thread.isDaemon etc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24203 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24204] string.strip() documentation is misleading
Mark Lawrence added the comment: https://docs.python.org/3/library/stdtypes.html#str.strip first sentence Return a copy of the string with the leading and trailing characters removed. How can that be reworded to make it clearer? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24204 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
