[issue12389] typo in urllib: missing space after dot at sentence end
New submission from Vladimir Rutsky : There is a typo in urllib module documentation: missing space after dot at sentence end. Please see attached path for details. -- assignee: docs@python components: Documentation files: urllib-typo-space-after-dot.patch keywords: patch messages: 138838 nosy: docs@python, rutsky priority: normal severity: normal status: open title: typo in urllib: missing space after dot at sentence end versions: Python 2.7 Added file: http://bugs.python.org/file22425/urllib-typo-space-after-dot.patch ___ Python tracker <http://bugs.python.org/issue12389> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11902] typo in argparse doc's: "action.."
New submission from Vladimir Rutsky : There is a typo in argparse module documentation: "The ``nargs`` keyword argument associates a different number of command-line arguments with a single action.." (two dots at end). Patch based on official http://svn.python.org/projects/python/branches/py3k/ repository, but typo is also noted in Python 2.7 documentation. -- assignee: docs@python components: Documentation files: argparse_typo_action_dot_dot.patch keywords: patch messages: 134237 nosy: docs@python, rutsky priority: normal severity: normal status: open title: typo in argparse doc's: "action.." versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file21751/argparse_typo_action_dot_dot.patch ___ Python tracker <http://bugs.python.org/issue11902> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11904] incorrect reStructuredText formatting in argparse module
New submission from Vladimir Rutsky : In Python 2.7 and 3 branch at http://svn.python.org/projects/python/branches/py3k/ file Doc/library/argparse.rst has incorrectly formatted list at line 648: > * ``'store'`` - This just stores the argument's value. This is the default >action. For example:: Second line must be indented according to first line. Next item at line 656 has invalid indentation too. -- assignee: docs@python components: Documentation messages: 134240 nosy: docs@python, rutsky priority: normal severity: normal status: open title: incorrect reStructuredText formatting in argparse module versions: Python 2.7, Python 3.4 ___ Python tracker <http://bugs.python.org/issue11904> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11905] typo in argparse doc's: missing dot at end of sentence
New submission from Vladimir Rutsky : There is missed dot at end of sentence in argparse module documentation. Please see attached patch for details. Patch based on official http://svn.python.org/projects/python/branches/py3k/ repository, but typo is also noted in Python 2.7 documentation. -- assignee: docs@python components: Documentation files: argparse_typo_missing_dot.patch keywords: patch messages: 134241 nosy: docs@python, rutsky priority: normal severity: normal status: open title: typo in argparse doc's: missing dot at end of sentence versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file21752/argparse_typo_missing_dot.patch ___ Python tracker <http://bugs.python.org/issue11905> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10846] typo in threading doc's: "size of the resource size"
New submission from Vladimir Rutsky : I think there is a typo in threading documentation: > In any situation where the size of the resource size is fixed, > you should use a bounded semaphore. - "size of the resource size", see attached patch for proposed fix. (Based on official http://svn.python.org/projects/python/branches/py3k/ repository.) -- assignee: d...@python components: Documentation files: threading_typo_size_of_size.patch keywords: patch messages: 125580 nosy: d...@python, rutsky priority: normal severity: normal status: open title: typo in threading doc's: "size of the resource size" versions: Python 3.3 Added file: http://bugs.python.org/file20293/threading_typo_size_of_size.patch ___ Python tracker <http://bugs.python.org/issue10846> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
New submission from Vladimir Rutsky : This is code from recent trace.py (http://svn.python.org/view/python/branches/release27-maint/Lib/trace.py?view=markup): trace.py:169: # Ignore a file when it contains one of the ignorable paths for d in self._dirs: # The '+ os.sep' is to ensure that d is a parent directory, # as compared to cases like: # d = "/usr/local" # filename = "/usr/local.py" # or # d = "/usr/local.py" # filename = "/usr/local.py" if filename.startswith(d + os.sep): self._ignore[modulename] = 1 return 1 Directories comparison like "filename.startswith(d + os.sep)" works incorrect on case-insensitive filesystems (such as NTFS on Windows). This leads to confusing results on Windows: python trace.py --ignore-dir='$prefix' -t test.py or python trace.py --ignore-dir C:\Python26\Lib -t test.py shows all calls from standard library, but this one doesn't: python trace.py --ignore-dir=c:\python26\lib -t test.py See attached test files and log for details. -- components: Library (Lib) files: test.py messages: 126101 nosy: vrutsky priority: normal severity: normal status: open title: trace module compares directories as strings (--ignore-dir) versions: Python 2.7 Added file: http://bugs.python.org/file20368/test.py ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Changes by Vladimir Rutsky : Added file: http://bugs.python.org/file20369/test.cmd ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Changes by Vladimir Rutsky : Added file: http://bugs.python.org/file20370/test.out ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Vladimir Rutsky added the comment: Workaround for people on Windows who don't wan't to modify trace.py: to get clean trace of only your project calls add to ignore list python path with mix of character cases. For me worked out this string: python -m trace --ignore-dir=c:\python26\lib;C:\python26\lib;C:\Python26\Lib -t main.py -- ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Vladimir Rutsky added the comment: SilentGhost, thanks for the patch! I can confirm, that adding os.path.normcase fixes issues with different cases of files. I believe there also may be issue with FAT's long file name mangling, like "C:\PROGRA~1\python26\" instead of "C:\Program Files\python26\". But never experienced such issue with Python. -- ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Vladimir Rutsky added the comment: Sorry I was wrong - patch don't fix original issue. Case should be normalized not only for directories provided through --ignore-dir, but also for directories obtained from __file__. In my tests on Windows Ignore.names(self, filename, modulename) receives `filename''s argument like: C:\Python26\Lib\site-packages\shapely\__init__.pyc Attaching patch fixes this issue for me (for Python 2.7 from http://svn.python.org/projects/python/branches/release27-maint, patch attached by SilentGhost is for 3.X I think). -- nosy: +SilentGhost Added file: http://bugs.python.org/file20452/trace_ignore_case_fix.patch ___ Python tracker <http://bugs.python.org/issue10896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()
Changes by Vladimir Rutsky : -- nosy: +rutsky ___ Python tracker <http://bugs.python.org/issue13857> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16303] typo in error message in pstats.py
New submission from Vladimir Rutsky: Please see attached patch for details. -- files: quote_typo.patch keywords: patch messages: 173594 nosy: vrutsky priority: normal severity: normal status: open title: typo in error message in pstats.py versions: Python 2.7 Added file: http://bugs.python.org/file27672/quote_typo.patch ___ Python tracker <http://bugs.python.org/issue16303> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16304] re: Match Objects always have a boolean value of True
New submission from Vladimir Rutsky: re module documentation says: Match Objects always have a boolean value of :const:`True`, so that you can test whether e.g. :func:`match` resulted in a match with a simple if statement. which is confusing - matched objects have boolean value True, doesn't matched - False. -- assignee: docs@python components: Documentation messages: 173595 nosy: docs@python, vrutsky priority: normal severity: normal status: open title: re: Match Objects always have a boolean value of True versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue16304> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex
New submission from Vladimir Rutsky: It would be nice if Python will be able to access variables with C99 complex types through ctypes module. -- components: ctypes messages: 179378 nosy: rutsky priority: normal severity: normal status: open title: Add support for C99 complex type (_Complex) as ctypes.c_complex type: enhancement ___ Python tracker <http://bugs.python.org/issue16899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex
Vladimir Rutsky added the comment:
Yes, I managed to pass and operate with matrices of complex numbers to pure C
and Fortran programs by using Numpy and their ctype adapters (only for whole
matrices, they don't provide c_complex type; in general see
http://www.scipy.org/Cookbook/Ctypes for details).
I suppose pure python solution that suggested in provided by you link works too:
class Complex64(Structure):
_fields_ = [("real", c_float), ("imag", c_float)]
But I'm unsure is this is expected behavior or luck, and on some platform this
code will not work due to different complex numbers internal representation.
Any way this should be implemented in libffi first, and then in ctypes, so this
feature request should be postponed, IMO.
--
___
Python tracker
<http://bugs.python.org/issue16899>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18243] mktime_tz documentation out-of-date
Changes by Vladimir Rutsky : -- nosy: +rutsky ___ Python tracker <http://bugs.python.org/issue18243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20573] "built-in repr()" function link on the repr module documentation is incorrect
New submission from Vladimir Rutsky: http://docs.python.org/2/library/repr.html page contains several links on built-in function `repr()` (search for "built-in repr()" on page), but links goes to `Repr.repr()` functions of `Repr` module instead of http://docs.python.org/library/functions.html#repr This is reverse situation to bug described in http://bugs.python.org/issue14489 -- messages: 210748 nosy: rutsky priority: normal severity: normal status: open title: "built-in repr()" function link on the repr module documentation is incorrect versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue20573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20643] Strange dot in documentation (after generator.close)
New submission from Vladimir Rutsky: In 3.4 docs after generator.close() description there is strange dot: http://docs.python.org/3.4/reference/expressions.html#generator.close Looks like it's due to following code in Doc/reference/expressions.rst:452: .. class:: . This line should be removed. -- assignee: docs@python components: Documentation messages: 211364 nosy: docs@python, rutsky priority: normal severity: normal status: open title: Strange dot in documentation (after generator.close) versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue20643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Changes by Vladimir Rutsky : -- nosy: +vrutsky ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1744382] Read Write lock
Changes by Vladimir Rutsky : -- nosy: +rutsky ___ Python tracker <http://bugs.python.org/issue1744382> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17356] Invalid link to repr() built-in function description
New submission from Vladimir Rutsky: References to built-in function repr() links to repr module (http://docs.python.org/2/library/repr.html#module-repr), but must link to description in http://docs.python.org/2/library/functions.html. It can be at least in http://docs.python.org/2/library/functions.html (link in table at page top). -- assignee: docs@python components: Documentation messages: 183538 nosy: docs@python, vrutsky priority: normal severity: normal status: open title: Invalid link to repr() built-in function description type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue17356> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25647] Return of asyncio.coroutine from asyncio.coroutine don't work in with enabled debug
New submission from Vladimir Rutsky: Return of @asyncio.coroutine-wrapped coroutine object from @asyncio.coroutine-wrapped coroutine fails if asyncio debug is enabled. Consider following example: @asyncio.coroutine def outer_coro(): @asyncio.coroutine def inner_coro(): return 1 return g() result = loop.run_until_complete(outer_coro()) If debug is disabled result will be 1, if debug is enabled, result will be CoroWrapper object. This issue is discussed on asyncio mailing list: https://groups.google.com/forum/?fromgroups#!topic/python-tulip/YFfFxftxxDc Complete example to reproduce this problem is here: https://gist.github.com/rutsky/c72be2edeb1c8256d680 Attaching patch for Python 3.4 branch that fixes this issue and add test for this bug. This issue is not reproduced in Python 3.5, because CoroWrapper is awaitable in Python 3.5 (and in Python 3.4 CoroWrapper is not future or generator). -- components: asyncio files: fix_return_of_coro_from_coro.diff keywords: patch messages: 254799 nosy: gvanrossum, haypo, vrutsky, yselivanov priority: normal severity: normal status: open title: Return of asyncio.coroutine from asyncio.coroutine don't work in with enabled debug versions: Python 3.4 Added file: http://bugs.python.org/file41063/fix_return_of_coro_from_coro.diff ___ Python tracker <http://bugs.python.org/issue25647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25647] Return of asyncio.coroutine from asyncio.coroutine doesn't work in with enabled debug
Changes by Vladimir Rutsky : -- title: Return of asyncio.coroutine from asyncio.coroutine don't work in with enabled debug -> Return of asyncio.coroutine from asyncio.coroutine doesn't work in with enabled debug ___ Python tracker <http://bugs.python.org/issue25647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25647] Return of asyncio.coroutine from asyncio.coroutine doesn't work with enabled asyncio debug
Changes by Vladimir Rutsky : -- title: Return of asyncio.coroutine from asyncio.coroutine doesn't work in with enabled debug -> Return of asyncio.coroutine from asyncio.coroutine doesn't work with enabled asyncio debug ___ Python tracker <http://bugs.python.org/issue25647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25648] asyncio.coroutine fails if asyncio debug mode is enabled and wrapped function don't have "__name__" attribute
New submission from Vladimir Rutsky: In Python 3.4.3 with enabled asyncio debug a function is wrapped using the following code in @asyncio.coroutine: @functools.wraps(func) def wrapper(*args, **kwds): w = CoroWrapper(coro(*args, **kwds), func) if w._source_traceback: del w._source_traceback[-1] w.__name__ = func.__name__ if hasattr(func, '__qualname__'): w.__qualname__ = func.__qualname__ w.__doc__ = func.__doc__ return w The unconditional access to "__name__" and "__doc__" attributes may fail in some circumstances. As this case looks strange and unrealistic I met it in a real application that used mocking in tests. The code there was something like the following: def f(): return "f result" mocked_f = Mock(wraps=f) coro_func = asyncio.coroutine(mocked_f) print(loop.run_until_complete(coro_func())) mocked_f.assert_called_once_with() Here is complete example: https://gist.github.com/rutsky/65cee7728135b05d49c3 This issue is fixed in 95964:957478e95b26 changeset during adding support of async/await syntax, so it is not reproduced in Python 3.5 or 3.4 head, but still reproducible in latest released version of Python 3.4 branch: 3.4.3. So until 3.4.4 is released this issue still may be considered as not fixed. -- components: asyncio messages: 254800 nosy: gvanrossum, haypo, vrutsky, yselivanov priority: normal severity: normal status: open title: asyncio.coroutine fails if asyncio debug mode is enabled and wrapped function don't have "__name__" attribute versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue25648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26908] "1and 0" evaluated a zero, instead of SyntaxError
New submission from Vladimir Rutsky: Looks like there is no need to place space separators after numbers: $ python3.5 -c "print(1and 0)" 0 $ python3.5 -c "print([1for i in range(1)])" [1] Not sure is this a bug or a feature, but I would expect that this should be SyntaxError, same as here: $ python3.5 -c "1 and0" File "", line 1 1 and0 ^ SyntaxError: invalid syntax If this is a feature, can anyone give reasoning for it? -- messages: 264654 nosy: rutsky priority: normal severity: normal status: open title: "1and 0" evaluated a zero, instead of SyntaxError versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue26908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13610] On Python parsing numbers.
Changes by Vladimir Rutsky : -- nosy: +rutsky ___ Python tracker <http://bugs.python.org/issue13610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28319] typo in lzma module documentation
New submission from Vladimir Rutsky: "Specifying custom filter chains" section contains: > It only supports a single The delta filter supports only one option, dist. Probably should be just: > The delta filter supports only one option, dist. -- assignee: docs@python components: Documentation messages: 277765 nosy: docs@python, vrutsky priority: normal severity: normal status: open title: typo in lzma module documentation versions: Python 3.5, Python 3.7 ___ Python tracker <http://bugs.python.org/issue28319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
