[issue13450] fix ''.format_map test

New submission from akira <4kir4...@gmail.com>: It seems that some assertions in Lib/test/test_unicode.py:UnicodeTest.test_format_map do not implement their intent e.g., self.assertRaises(TypeError, '{'.format_map) self.assertRaises(TypeError

[issue13450] add assertions to implement the intent in ''.format_map test

Changes by akira <4kir4...@gmail.com>: -- title: fix ''.format_map test -> add assertions to implement the intent in ''.format_map test ___ Python tracker <h

[issue13450] add assertions to implement the intent in ''.format_map test

Changes by akira <4kir4...@gmail.com>: Removed file: http://bugs.python.org/file23747/correct-assertions-in-test_format_map.patch ___ Python tracker <http://bugs.python.org/i

[issue13450] add assertions to implement the intent in ''.format_map test

Changes by akira <4kir4...@gmail.com>: Added file: http://bugs.python.org/file23748/correct-assertions-in-test_format_map.patch ___ Python tracker <http://bugs.python.org/i

[issue13450] add assertions to implement the intent in ''.format_map test

akira <4kir4...@gmail.com> added the comment: TypeError tests can check that an implementation raises a correct exception type i.e., it doesn't raise ValueError prematurely on invalid format_string without checking that there is mapping argument. METH_O does it for CPython. I

[issue13496] bisect module: Overflow at index computation

akira <4kir4...@gmail.com> added the comment: Related bug in Java: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html Do not consider any change as trivial: http://www.solipsys.co.uk/new/BinarySearchReconsidered.html (the author ran "binary sea

[issue13643] 'ascii' is a bad filesystem default encoding

Changes by akira <4kir4...@gmail.com>: -- nosy: +akira ___ Python tracker <http://bugs.python.org/issue13643> ___ ___ Python-bugs-list mailing list Unsubs

[issue9959] int(math.log(4,2)) == 1 instead of 2

New submission from akira <4kir4...@gmail.com>: $ python3.1 -c'import math; f = math.log(4,2); print(int(f), f.as_integer_ratio())' 2 (2, 1) $ python3.2 -c'import math; f = math.log(4,2); print(int(f), f.as_integer_ratio())' 1 (9007199254740991, 4503599627370496)

[issue9959] int(math.log(4,2)) == 1 instead of 2

akira <4kir4...@gmail.com> added the comment: > No, it's not really a bug: math.log(x, 2) isn't an atomic operation: It is not a bug, but values of math.log(4) differs between 3.1 and 3.2 i.e., math.log(4.0) in 3.2 returns value that is consistent with math.log(4) in 3.1 but

[issue9959] int(math.log(4,2)) == 1 instead of 2

Changes by akira <4kir4...@gmail.com>: Added file: http://bugs.python.org/file19031/test_log_power_two.py ___ Python tracker <http://bugs.python.org/issue9959> ___ __

[issue9959] int(math.log(4,2)) == 1 instead of 2

Changes by akira <4kir4...@gmail.com>: -- type: behavior -> feature request ___ Python tracker <http://bugs.python.org/issue9959> ___ ___ Python-bugs-li

[issue11330] logging doesn't support format flags for asctime keyword, but the docs use them

New submission from akira <4kir4...@gmail.com>: Since Python 3.2 logging package doesn't support formatting flags for the `asctime` keyword, but the documentation uses them. For example in Doc/library/logging.rst: FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(messa

[issue11331] unused line in the logging-cookbook example

New submission from akira <4kir4...@gmail.com>: The line with `LoggerAdapter` is not used in http://docs.python.org/dev/howto/logging-cookbook.html#using-filters-to-impart-contextual-information Here's a patch for Doc/howto/logging-cookbook.rst: doc-logging-cookbook-unused-line-r

[issue984870] curses: getmaxyx() breaks when the window shrinks

akira <4kir4...@gmail.com> added the comment: The test produces a traceback while shrinking a window (increasing the window size works ok): Traceback (most recent call last): File "screen-resize-bug-curses.py", line 22, in curses.wrapper(main) File "/.../python

[issue11952] typo in multiprocessing documentation: __main__ method should be replaced by __main__ module

New submission from akira <4kir4...@gmail.com>: s/method/module/: Functionality within this package requires that the ``__main__`` method be importable by the children. -- assignee: docs@python components: Documentation messages: 134724 nosy: akira, docs@python priority:

[issue9509] argparse FileType raises ugly exception for missing file

akira <4kir4...@gmail.com> added the comment: Simplified the patch and added test for a non-existent file in issue9509.patch The test `py3k/python -m test.regrtest test_argparse` fails without the patch and succeeds with it. The docs in Doc/library/argparse.rst and Lib/argparse.py don&

[issue9509] argparse FileType raises ugly exception for missing file

akira <4kir4...@gmail.com> added the comment: I've added tests for readonly files. SilentGhost's patch doesn't handle this case. -- Added file: http://bugs.python.org/file19806/test_argparse.diff ___ Python tracker <http://b

[issue9509] argparse FileType raises ugly exception for missing file

akira <4kir4...@gmail.com> added the comment: Attached patch for argparse.py (argparse.diff -- without tests, see tests in test_argparse.diff) where ValueError is raises in FileType.__call__ and additional details printed on ArgumentError -- Added file: http://bugs.pyth

[issue9509] argparse FileType raises ugly exception for missing file

akira <4kir4...@gmail.com> added the comment: updated patch on http://codereview.appspot.com/3251041/ -- ___ Python tracker <http://bugs.python.org/

[issue9509] argparse FileType raises ugly exception for missing file

akira <4kir4...@gmail.com> added the comment: "no such file or directory '%s'" is misleading if you are trying to open a readonly file for writing. The message might be replace by: "can't open '%s'" --

[issue8528] typo in argparse documentation

New submission from akira <4kir4...@gmail.com>: `messges` should be replaced by `messages` on http://docs.python.org/dev/library/argparse.html#upgrading-optparse-code page. -- assignee: d...@python components: Documentation messages: 104144 nosy: akira, d...@python severity:

[issue8709] mention explicitly Windows support for os.devnull

New submission from akira <4kir4...@gmail.com>: Currently it is not obvious that os.devnull works on Windows. -- assignee: d...@python components: Documentation files: doc-os-devnull-windows-r81160.diff keywords: patch messages: 105688 nosy: akira, d...@python priority: normal se

[issue10278] add time.wallclock() method

Changes by akira <4kir4...@gmail.com>: -- nosy: +akira ___ Python tracker <http://bugs.python.org/issue10278> ___ ___ Python-bugs-list mailing list Unsubs

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

Changes by akira <4kir4...@gmail.com>: -- nosy: +akira ___ Python tracker <http://bugs.python.org/issue1602> ___ ___ Python-bugs-list mailing list Unsubs

[issue16029] pickle.dumps(xrange(sys.maxsize)) produces xrange(0)

New submission from akira: >>> import sys >>> from pickle import dumps, loads >>> r = xrange(sys.maxsize) >>> len(r) == sys.maxsize True >>> pr = loads(dumps(r)) >>> len(pr) == len(r) False >>> pr xrange(0) >&g

[issue19264] subprocess.Popen doesn't support unicode on Windows

akira added the comment: I've checked the source code for 3.4; `subprocess` uses `_winapi.CreateProcess` on Windows [1] that in turn uses `CreateProcessW` [2]. CreateProcessA is not used. `Popen` should already support Unicode on Windows though I don't see explicit tests for

[issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC

akira added the comment: Antoine, I haven't received the e-mail notification. I've replied to the comments on Rietveld. Here's the updated patch with the corresponding changes. -- Added file: http://bugs.python.org/file34594/ssl_cert_time_to_se

[issue21041] pathlib.PurePath.parents rejects negative indexes

New submission from akira: `pathlib.PurePath.parents` is a sequence [1] but it rejects negative indexes: >>> from pathlib import PurePath >>> PurePath('a/b/c').parents[-2] Traceback (most recent call last): ... IndexError: -2 Sequences in Python interpret

[issue21041] pathlib.PurePath.parents rejects negative indexes

Changes by akira <4kir4...@gmail.com>: -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue21041> ___ ___ Python-bugs-list mailing l

[issue1191964] asynchronous Subprocess

akira added the comment: > Also, Richard Oudkerk's claims above about not needing to use fcntl to swap > flags is not correct. It's necessary to not block on reading, even if select > is used. Select just guarantees that there is at least 1 byte or a closed > handle, n

[issue1191964] asynchronous Subprocess

akira added the comment: Could `read_nonblocking()`, `write_nonblocking()` raise OSError(EAGAIN) (it could be named `ResourceTemporarilyUnavailableError`) if read/write would block? It would allow to distinguish EOF (permanent condition) from "read/write would block" (temporarily

[issue21041] pathlib.PurePath.parents rejects negative indexes

akira added the comment: >From https://docs.python.org/3/glossary.html#term-sequence > An iterable which supports efficient element access using integer indices via > the __getitem__() special method and defines a __len__() method that returns > the length of the sequence. .pa

[issue21182] json.loads errors out on valid JSON

akira added the comment: You need to escape backslashes inside a Python string literal or use raw-string literals: >>> import json >>> json.loads(r'["[\"Residential | Furniture | Cabinets\",\"119.99\"]"]') [u'["Res

[issue21194] json.dumps with ensure_ascii=False doesn't escape control characters

akira added the comment: json.dumps works correctly in this case. Both json/application rfc [1] and ecma json standard [2] say: > All characters may be placed within the quotation marks, except for the > characters that must be escaped: quotation mark (U+0022), reverse solidus >

[issue21177] ValueError: byte must be in range(0, 256)

akira added the comment: "byte must be in range [0, 256)" - it hints at the builtin `range()` -- the intuition works for those who knows what `range()` does - it uses the standard math notation for half-open intervals [1] -- no Python knowledge required (among other things) - i

[issue21267] mktime_tz may return wrong result for past dates before Python 2.7.4

New submission from akira: >>> from email.utils import mktime_tz, parsedate_tz >>> mktime_tz(parsedate_tz('Thu, 1 Jan 1970 00:00:00 GMT')) 3600.0 It must returns `0` instead of `3600.0` assuming POSIX timestamp. UTC offsets in 1970 and today are different from

[issue21267] mktime_tz may return wrong result for past dates before Python 2.7.4

Changes by akira <4kir4...@gmail.com>: -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue21267> ___ __

[issue18243] mktime_tz documentation out-of-date

akira added the comment: I've added the documentation patch with the outdated remark removed from mktime_tz docs. -- keywords: +patch nosy: +akira type: -> behavior versions: +Python 3.2, Python 3.5 Added file: http://bugs.python.org/file34929/mktime_tz-d

[issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux

Changes by akira <4kir4...@gmail.com>: -- nosy: +akira ___ Python tracker <http://bugs.python.org/issue21302> ___ ___ Python-bugs-list mailing list Unsubsc

[issue17552] socket.sendfile()

akira added the comment: Should socket.sendfile() always return number of bytes sent because file.tell() may be changed by something else that uses the same file descriptor? What happens if the file grows? Instead of returning `(was_os_sendfile_used, os_sendfile_error)`, you could specify

[issue17552] socket.sendfile()

akira added the comment: > I really don't like the use_fallback argument .. I initially also thought so. But I've suggested the parameter to replace `(was_os_sendfile_used, os_sendfile_error)` returned value as a *trade off* between a slight complexity in the interface vs. allow

[issue21332] subprocess bufsize=1 docs are misleading

Changes by akira <4kir4...@gmail.com>: -- nosy: +akira ___ Python tracker <http://bugs.python.org/issue21332> ___ ___ Python-bugs-list mailing list Unsubsc

[issue17552] socket.sendfile()

akira added the comment: use_fallback parameter is mostly a debugging tool. If it helps to avoid the indecision; I would side with neologix' remarks and also suggest to drop the use_fallback parameter. It seems the patch assumes *offset == nbytes_sent* that is false in general e.g., if o

[issue21347] Don't use a list argument together with shell=True in subprocess' docs

New submission from akira: *Popen(["something"], shell=True)* works but it is similar to *Popen(["something", "arg"], shell=True)* that passes "arg" to /bin/sh on POSIX systems instead of "something". It is best to always use a string if `s

[issue17552] socket.sendfile()

akira added the comment: count and blocksize are completely different. *count* specifies how many bytes at most socket.sendfile should sent overall. It may change the result i.e., it may not be necessary that the file is read until EOF. It has the same meaning as *nbytes* parameter for

[issue17552] socket.sendfile()

akira added the comment: > I'm confused. Why is "blocksize" necessary at all? My guess, it may be used to implement socket.send()-based fallback. Its meaning could be the same as *length* parameter in shutil.copyfileobj The fallback is useful if os.sendfile doesn't exis

[issue21353] document Popen.args attribute

New submission from akira: It is convenient to have Popen.args available. Especially when dealing with multiple processes e.g., to log failures mentioning the command that was used to spawn the child process. subprocess module itself uses it while raising CalledProcessError or TimeoutExpired

[issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC

akira added the comment: Here's a new patch with a simplified ssl.cert_time_to_seconds() implementation that brings strptime() back. The behaviour is changed: - accept both %e and %d strftime formats for days as strptime-based implementation did before - return an integer instead of a

[issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC

akira added the comment: Replace IndexError with ValueError in the patch because tuple.index raises ValueError. -- Added file: http://bugs.python.org/file35051/ssl_cert_time_to_seconds-ps5.patch ___ Python tracker <http://bugs.python.org/issue19

[issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC

akira added the comment: I've updated the patch: - fixed the code example in the documentation to use int instead of float result - removed assertion on the int returned type (float won't lose precision for the practical dates but guaranteeing an integer would be nice) - reworded

[issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC

akira added the comment: Antoine, thank you for reviewing. I appreciate the patience. -- ___ Python tracker <http://bugs.python.org/issue19940> ___ ___ Python-bug

[issue21332] subprocess bufsize=1 docs are misleading

akira added the comment: It looks like a bug in the subprocess module e.g., if child process does: sys.stdout.write(sys.stdin.readline()) sys.stdout.flush() and the parent: p.stdin.write(line) #NOTE: no flush line = p.stdout.readline() then a deadlock may happen with bufsize=1

[issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation

New submission from akira: related: msg217596 (bufsize=1 is broken if subprocess module uses Python io) TextIOWrapper.write behavior: _pyio.py [1]: if self._line_buffering and (haslf or "\r" in s): self.flush() textio.c [2]: if (self->write_through)

[issue21332] subprocess bufsize=1 docs are misleading

akira added the comment: Related issue #21396 -- ___ Python tracker <http://bugs.python.org/issue21332> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21332] subprocess bufsize=1 docs are misleading

akira added the comment: I've changed test_newlines to work also with Python io implementation. I've updated the patch. Note: tests use 10 seconds timeouts: I don't know how long it should take to read back a line from a subprocess so that the timeout would indic

[issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation

akira added the comment: I've uploaded the patch that makes C implementation behave according to the docs like Python implementation with the corresponding tests. Issue #21332 is a dependency for this issue: subprocess' test_universal_newlines needs to be updated to work with Pyth

[issue21332] subprocess bufsize=1 docs are misleading

akira added the comment: yes, line_buffering=(bufsize == 1) is necessary to support the current Python io implementation or if C implementation is fixed to avoid buffer.flush() on every write with write_through=True -- otherwise bufsize is not respected in text mode (it would always mean

[issue21332] subprocess bufsize=1 docs are misleading

akira added the comment: to be clear: the test itself doesn't use threads, `python -mtest -j0` runs tests using multiple *processes*, not threads. There is no issue. If the test were to run in the presence of multiple threads then the issue would be the *explicit* p.stdin.close() in the

[issue21347] Don't use a list argument together with shell=True in subprocess' docs

akira added the comment: I've checked the same documentation patch applies to both default (3.5) and 2.7 branches. There are no more instances of the misleading usage left (after applying the patch). -- ___ Python tracker <http://bugs.py

[issue20866] segfailt with os.popen and SIGPIPE

akira added the comment: I can't reproduce it on Ubuntu 12.04 with Python 2.7.3, 2.7.6, 3.2, tip -- no segfault. It prints the expected output on both Python 2 and 3: (standard input) io-error "(standard input)" is printed by grep due to --files-with-match option io-err

[issue20866] segfailt with os.popen and SIGPIPE

akira added the comment: Victor, where can you reproduce it (OS, python version, what C lib)? I don't receive segfault, only sigpipe (see msg217818 ). Here's gdb backtrace after the signal: Program received signal SIGPIPE, Broken pipe. 0x771e1040 in __write_nocancel () at

[issue21437] document that asyncio.ProactorEventLoop doesn't support SSL

New submission from akira: In Lib/asyncio/proactor_events.py:419 [1]: def _start_serving(self, protocol_factory, sock, ssl=None, server=None): if ssl: raise ValueError('IocpEventLoop is incompatible with SSL.') [1]: http://hg.python.org/cpython/file/4f26430b03fd/L

[issue21444] __len__ can't return big numbers

akira added the comment: If `len()` signature can't be changed to return Python int objects (unlimited) then the OverflowError may contain the actual `.length` property instead (based on msg66459 by Antoine Pitrou) operator.length(): def length(sized): ""&

[issue21332] subprocess bufsize=1 docs are misleading

akira added the comment: I've updated the patch to remove changes to test_universal_newlines test that was fixed in revision 37d0c41ed8ad that closes #21396 issue -- Added file: http://bugs.python.org/file35189/subprocess-line-buffering-issue21332-ps4.

[issue21464] fnmatch module uses regular expression with undefined result to perform matching

akira added the comment: I don't see (?x) flag and it is not introduced by `res` regular expression that is constructed within translate() function in Lib/fnmatch.py >>> import fnmatch >>> fnmatch.translate('a b') 'a

[issue21332] subprocess bufsize=1 docs are misleading

akira added the comment: I've asked about thread-safety of tests on python-dev mailing list: https://mail.python.org/pipermail/python-dev/2014-May/134523.html -- ___ Python tracker <http://bugs.python.org/is

[issue21471] subprocess line-buffering only works in universal newlines mode

akira added the comment: Until the current patch for issue #21332 is committed; bufsize=1 is equivalent to bufsize=-1 in both binary and text mode. You are correct the patch in #21332 fixes only the text mode (universal_newlines=True) -- it also updates the documentation to mention that

[issue21485] remove unnecesary .flush() calls in the asyncio subprocess code example

New submission from akira: The current code example contains [1]: print("Python failed with exit code %s:" % exitcode) sys.stdout.flush() sys.stdout.buffer.flush() sys.stdout.buffer.write(stdout) sys.stdout.buffer.flush() that looks bizarre. Either a comment

[issue17909] Autodetecting JSON encoding

akira added the comment: Both json standard (ECMA-404) [1] and the new json rfc 7159 [2] do not mention the encoding detection. [1] http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf [2] https://tools.ietf.org/html/rfc7159#section-8.1 >From the rfc: > JSON text SH

[issue6445] Add check parameter to subprocess.Popen.communicate

akira added the comment: subprocess.check_output() could be used in "communicate() + check process exit status" one-liners. It returns child process output (stdout) and raises an exception if the returncode is not zero. It is available since Python 2.7 (3.1) If you don't want to

[issue21543] json library fails to serialize objects such as datetime

akira added the comment: json module already allows you to customize the serialization: see *default* parameter for json.dumps [1] [1] https://docs.python.org/3/library/json.html#json.dump -- nosy: +akira ___ Python tracker <http://bugs.python.

[issue21542] pprint doesn't work well for counters, sometimes shows them like a dict

akira added the comment: If it fits on a line then it seems Counter's repr is used: >>> pprint(Counter({i:i*i for i in range(10)})) Counter({9: 81, 8: 64, 7: 49, 6: 36, 5: 25, 4: 16, 3: 9, 2: 4, 1: 1, 0: 0}) Otherwise It is shown as a dict (Counter is a dict subclass) if it

[issue7434] general pprint rewrite

akira added the comment: Related issue #21542: pprint support for multiline collections.Counter -- nosy: +akira ___ Python tracker <http://bugs.python.org/issue7

[issue21332] subprocess bufsize=1 docs are misleading

akira added the comment: > The short answer is: no, you don't have to make you thread thread > safe, as long as it can reliably run even in the presence of > background threads (like the tkinter threads Victor mentions). https://mail.python.org/pipermail/python-dev/2014-May/1

[issue1191964] asynchronous Subprocess

akira added the comment: > Does anyone have questions, comments, or concerns about the patch? It seems the current API doesn't distinguish between BlockingIOError (temporary error), BrokenPipeError (permanent error) and EOF (permanent non-error condition) -- everything is treated as EO

[issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit

akira added the comment: > getrlimit and setrlimit are not exposed in the os module; you must use ctypes > or an extension module to call them from Python: There is `resource` module: >>> import resource >>> resource.getrlimit(resource.RLIMIT_NOFILE) (1024

[issue1191964] asynchronous Subprocess

akira added the comment: > First, with the use of Overlapped IO on Windows, BlockingIOError should never > come up, and we don't even handle that exception. Is it correct that the way to distinguish between "would block" and EOF is Popen.poll()? Is it possible to dete

[issue9770] curses.isblank function doesn't match ctype.h

akira added the comment: I've fixed isblank to accept tab instead of backspace and added tests for character classification functions from curses.ascii module that have corresponding analogs in ctype.h. They've uncovered issues in isblank, iscntrl, and ispunct functions. Open questi

[issue16409] urlretrieve regression: first call returns block size as 0

akira added the comment: Summary: It is a new behavior. There is no need to change either code or docs. Though docs could be clarified to be more explicit. The behavior has been introduced only in 3.3 in revision 53715804dc71 [1] from issue 10050 [2] It knownly breaks backward

[issue10050] urllib.request still has old 2.x urllib primitives

akira added the comment: Related issue 16409 -- nosy: +akira ___ Python tracker <http://bugs.python.org/issue10050> ___ ___ Python-bugs-list mailing list Unsub

[issue1490929] urllib.retrieve's reporthook called with non-helpful value

akira added the comment: Related issue 16409 -- nosy: +akira ___ Python tracker <http://bugs.python.org/issue1490929> ___ ___ Python-bugs-list mailing list Unsub

[issue16409] urlretrieve regression: first call returns block size as 0

akira added the comment: The summary assumes that issue 10050 is valid i.e., urlretrieve is reimplemented using new urlopen and 2.x FancyURLopener is deprecated. It might not be so [1]. In this case the summary is incorrect. Old implementation is available as: opener = FancyURLopener

[issue12750] datetime.strftime('%s') should respect tzinfo

akira added the comment: *If* the support for %s strftime format code is added then it should keep backward compatibility on Linux, OSX: it should produce an integer string with the correct rounding. Currently, datetime.strftime delegates to a platform strftime(3) for format specifiers that are

[issue12750] datetime.strftime('%s') should respect tzinfo

akira added the comment: > I suspect that in the absence of %z, the most useful option would be to > return naive datetime in the local timezone, but that can be added later. Naive datetime in the local timezone may lose information that is contained in the input timestamp: >>

[issue21873] Tuple comparisons with NaNs are broken

akira added the comment: Is the issue that: >>> (1, float('nan')) == (1, float('nan')) False but >>> nan = float('nan') >>> (1, nan) == (1, nan) True ? `nan != nan` therefore it might be expected that `(a, nan) != (a, nan

[issue21873] Tuple comparisons with NaNs are broken

akira added the comment: btw, pypy3 (986752d005bb) is broken: >>>> (1, float('nan')) == (1, float('nan')) True -- ___ Python tracker &l

[issue21873] Tuple comparisons with NaNs are broken

akira added the comment: > Python containers are allowed to let identity-imply-equality (the reflesive > property of equality). Is it documented somewhere? > Dicts, lists, tuples, deques, sets, and frozensets all work this way. Is it CPython specific

[issue21873] Tuple comparisons with NaNs are broken

akira added the comment: It is about equality. `float('nan') != float('nan')` unlike `0 == 0`. >From msg221603: > If not equal, the sequences are ordered the same as their first differing > elements. The result of the expression: `(a, whatever) < (b, whatev

[issue21873] Tuple comparisons with NaNs are broken

akira added the comment: > (a, b) < (c, d) is more like: if a != c: return a < c ... except CPython behaves (undocumented?) as: b < d if a is c or a == c else a < c the difference is in the presence of `is` operator (identity comparison instead of `__eq__`). `nan is nan` t

[issue12750] datetime.strftime('%s') should respect tzinfo

akira added the comment: > Can you explain why math.floor rather than builtin round is the correct > function to use? To avoid breaking existing scripts that use `.strftime('%s')` on Linux, OSX, see msg221385: >>> from datetime import datetime, timezone >>&g

[issue12750] datetime.strftime('%s') should respect tzinfo

akira added the comment: > ``%s`` format code behaviour was undefined and incidental. strftime('%s') is not portable but it *is* supported on some platforms i.e., it is *not* undefined and it is *not* incidental on these platforms. datetime.strftime *delegates* to the platform st

[issue8631] subprocess.Popen.communicate(...) hangs on Windows

akira added the comment: > ID>>> s.check_output("pyflakes c:\programs\python34\lib\turtle.py") > hangs indefinitely, no output It might be unrelated to the issue but "\t" is a tab; a raw-string literal should be used instead: >>> from subproc

[issue21041] pathlib.PurePath.parents rejects negative indexes

akira added the comment: > Aren't negative indexes well defined in Python? yes. I've provided the link to Python docs [1] in msg214642 that explicitly defines the behavior: > If i or j is negative, the index is relative to the end of the string: > len(s) + i or len(s)

[issue1191964] add non-blocking read and write methods to subprocess.Popen

akira added the comment: STINNER Victor writes: > >> I have implemented and would continue to lean towards continuing to > hide BrokenPipeError on the additional API endpoints. > > FYI asyncio.Process.communicate() ignores BrokenPipeError and > Connecti

[issue9770] curses.ascii.isblank() function is broken. It confuses backspace (BS 0x08) with tab (0x09)

akira added the comment: I've made the title more explicit: "curses.isblank function doesn't match ctype.h" -> "curses.ascii.isblank() function is broken. It confuses backspace (BS 0x08) with tab (0x09)" If a core developer could review the open questions fro

[issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC

New submission from akira: cert_time_to_seconds() uses `time.mktime()` [1] to convert utc time tuple to seconds since epoch. `mktime()` works with local time. It should use `calendar.timegm()` analog instead. Example from the docs [2] is seven hours off (it shows utc offset of the local

[issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC

akira added the comment: gudge, There is also an issue with the current strptime format [1] (`"%b %d %H:%M:%S %Y GMT"`). It is locale-dependent and it may fail if a non-English locale is in effect. I don't know whether I should open a new issue on this or are you going

[issue20029] asyncio.SubprocessProtocol is missing

New submission from akira: `SubprocessProtocol` is documented to be accessible as `asyncio.SubprocessProtocol` [1] but it is not included in `asyncio.protocols.__all__` [2] that leads to `AttributeError`: python3.4 -c "import asyncio; asyncio.SubprocessProtocol" Trace

[issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC

akira added the comment: gudge, have you seen http://bugs.python.org/msg205860 (the locale issue)? If you can't fix it; say so, I'll open another issue after this issue is fixed. -- ___ Python tracker <http://bugs.python.o

[issue19940] ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC

akira added the comment: The point of the locale issue is that "notBefore", "notAfter" strings do not change if your locale changes. You don't need a new regex for each locale. I've attached ssl_cert_time_seconds.py file that contains example cert_time_to_sec

  1   2   3   4   5   >