[issue22085] Drop support of Tk 8.3
Serhiy Storchaka added the comment:
Oh, I forgot about this difference. Of course we can convert input arguments to
match new syntax, but trace vinfo and trace info variable return different
results:
% trace add variable foo {read write} {tracer foo}
% trace info variable foo
{{read write} {tracer foo}}
% trace vinfo foo
{rw {tracer foo}}
We should add new methods for new trace commands.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22085
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11429] ctypes is highly eclectic in its raw-memory support
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11429 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21580] PhotoImage(data=...) apparently has to be UTF-8 or Base-64 encoded
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21580 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22085] Drop support of Tk 8.3
Serhiy Storchaka added the comment: Yet one incompatibility is that callbacks set but old command are called with last argument one of 'r', 'w' or 'u', but callbacks set but old command are called with last argument one of 'read', 'write' or 'unset' (or 'array'). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21308] PEP 466: backport ssl changes
Arnaud Fontaine added the comment: Would it be possible to also backport the changes to httplib.py to support TLS SNI as many libraries (including setuptools) relies on this module to download files and some servers reject clients not supporting TLS SNI (such as cloud.github.com)? I have added a patch for Python 2.7.8. Thanks for working on the backports of SSL changes! -- nosy: +arnau Added file: http://bugs.python.org/file36174/tls_sni_httplib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21308 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11955] 3.3 : test_argparse.py fails 'make test'
Mark Lawrence added the comment: @Ezio will you be following this up, specifically msg193970 ? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21308] PEP 466: backport ssl changes
Nick Coghlan added the comment: Hi Arnaud, such a change is out of scope for PEP 466. To minimise the scale of the changes in a maintenance release, it was deliberately limited to provide the core infrastructure, so at least third party libraries like requests can support SNI in Python 2, without touching every networking module in the Python 2 standard library. However, you're welcome to write a follow up PEP suggesting expanding the scope of the changes out to at least offering SNI support in other standard library modules. While I can't promise such a proposal would be approved, I do agree the question is worth asking. The risk of that change can then be independently assessed vs advising users that need SNI support in Python 2 to install a third party module like requests. (The bootstrapping problem is likely to be addressed by backporting the relevant parts of PEP 453, although that project too is in need of a volunteer to write the enhancement proposal). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21308 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22113] memoryview and struct.pack_into
New submission from Clayton Stangeland: I expect struct.pack_into to work for a memoryview. Currently struct.pack_into throws an exception. import struct buf = bytearray(10) struct.pack_into(B, buf, 0, 99) buf[0] 99 view = memoryview(buf) view.readonly False struct.pack_into(B, view, 0, 88) Traceback (most recent call last): File input, line 1, in module TypeError: expected a writeable buffer object view[0:1] = 'a' view[0] 'a' buf[0] 97 chr(buf[0]) 'a' The memoryview is writeable and from what I can tell from the documentation it implements the buffer interface, but struct.pack_into will not use it. -- files: struct_pack_into.py messages: 224386 nosy: stangelandcl priority: normal severity: normal status: open title: memoryview and struct.pack_into type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file36175/struct_pack_into.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22113 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22113] memoryview and struct.pack_into
Stefan Krah added the comment: This works in Python 3.3+. It is a bug in 2.7, so we have to wait for someone motivated enough to work on an outdated Python version. -- components: +Interpreter Core nosy: +skrah stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22113 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15986] memoryview: expose 'buf' attribute
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22112] '_UnixSelectorEventLoop' object has no attribute 'create_task'
STINNER Victor added the comment: This has been fixed in 3.4.2, but shows up in the 3.4.1 documentation. Well, I didn't want to change Python 3.4.1 documentation, but it looks like https://docs.python.org/3.4/ is updated after each commit into the 3.4 branch. For example, new asyncio functions added in 3.4.2 are already documented: https://docs.python.org/3.4/library/asyncio-eventloop.html#asyncio.BaseEventLoop.create_task I changeed all examples to use create_task() instaed of async() or the Task contructor: changeset: 91609:66f06fbf8a2f branch: 3.4 user:Victor Stinner victor.stin...@gmail.com date:Tue Jul 08 12:39:10 2014 +0200 files: Doc/library/asyncio-dev.rst Doc/library/asyncio-eventloop.rst Doc/library/asyncio-stream.r description: Update asyncio documentation - Document the new create_task() method - Hide the Task class: point to the create_task() method for interoperability - Rewrite the documentation of the Task class - Document the Pending task destroyed - Update output in debug mode of examples in the dev section - Replace Task() with create_task() in examples Maybe I should revert this change in the 3.4 branch, but mention that Python 3.4.2 and 3.5 have a new create_task() which is now the recommanded way to schedule a coroutine (to create a task object). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15986] memoryview: expose 'buf' attribute
New submission from Josh Rosenberg: To do what? -- nosy: +josh.rosenberg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22043] Use a monotonic clock to compute timeouts
STINNER Victor added the comment: pymonotonic.patch is large and difficult to review. I prefer to split it into two parts: - pytimespec.patch: Change pytime.h to use _PyTimeSpec structure (nanosecond resolution) instead of _PyTime_timeval structure (microsecond resolution) - pymonotonic-2.patch: Add _PyTimeSpec_monotonic() and _PyTimeSpec_monotonic_info() -- Added file: http://bugs.python.org/file36176/pytimespec.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22043] Use a monotonic clock to compute timeouts
Changes by STINNER Victor victor.stin...@gmail.com: Added file: http://bugs.python.org/file36177/pymonotonic-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12312] is ok
Missy Gomrz added the comment: Re: is ol missy orr -- nosy: +Missy.Gomrz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12312 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22043] Use a monotonic clock to compute timeouts
STINNER Victor added the comment: pytimespec.patch removes *private* functions which were exposed in the stable ABI: - _PyTime_gettimeofday() - _PyTime_gettimeofday_info() It also removes private macros: - _PyTime_ADD_SECONDS() - _PyTime_INTERVAL() In pymonotonic.patch, I reused the same name but I didn't notice that they were part of the stable ABI. In pymonotonic-2.patch, I changed names so the dynamic loader will not load a module and the compiler will complain that symbols are missing. Replaced/renamed functions: - _PyTime_gettimeofday() = _PyTimeSpec_get_time() - _PyTime_gettimeofday_info() = _PyTimeSpec_get_time_info() - _PyTime_ADD_SECONDS() = _PyTimeSpec_add_sec() - _PyTime_INTERVAL() = _PyTimeSpec_interval_sec() I aslo added new functions: - _PyTimeSpec_add_us() - _PyTimeSpec_interval_us() On overflow, _PyTimeSpec_add_sec() and _PyTimeSpec_add_us() sets the timestamp to the maximum value instead of returning an undefined value. I prefer functions over macros because I want to return an error on overflow (even if it's not used). _PyTimeSpec_interval_us() also returns the maximum value in case of overflow. _PyTimeSpec_interval_sec() should maybe take a mandatory round parameter instead of always rounding up. I added _PyTime_unit_t for _threadmodule.c because acquire_timed() has a PY_TIMEOUT_T type which can be a long long. Maybe acquire_timed() can return an error if the timeout is too large, or loop? I would prefer to avoid this custom _PyTime_unit_t type. I should maybe add unit tests for _PyTimeSpec_add_*() and _PyTimeSpec_interval_*() functions, as I did for _PyLong_FromTime_t(), _PyTime_ObjectToTimeval(), etc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22043] Use a monotonic clock to compute timeouts
STINNER Victor added the comment: Oh, pymonotonic-2.patch didn't get its review link because it depends on pytimespec.patch which is not merged yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15986] memoryview: expose 'buf' attribute
Martin Panter added the comment: This issue was linked from https://mail.python.org/pipermail/python-dev/2012-September/121781.html. I was looking for ways to pass read-only memory views into “ctypes” without copying memory, and came across that thread. Assuming this “buf” attribute points to the memory of the memory view, it could then be passed to “ctypes.c_void_p” or “_CData.from_address”. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11427] ctypes from_buffer no longer accepts bytes
Martin Panter added the comment: For the record, I have been (ab?)using the “c_char_p” type to get the address of immutable byte strings without copying memory: from ctypes import * data = b123\x00abc pubyte = cast(c_char_p(data), POINTER(c_ubyte)) address = addressof(pubyte.contents) string_at(address, 7) b'123\x00abc' # 2nd instance has same address, rather than memory copy: ... cast(c_char_p(data), c_void_p).value == address True In to the documentation, “c_char_p” is only defined for zero-terminated strings, but it seems to also work for strings with embedded zero bytes. However it does not work for “bytearray” objects (“from_buffer” should work instead), nor memory views. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11427 ___ ___ 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
Drekin added the comment: I looked to the sourcecode and found the following. First, the codepath of how interactive loop gets its input follows: Python/pythonrun.c:PyRun_InteractiveLoopFlags Python/pythonrun.c:PyRun_InteractiveOneObject Python/pythonrun.c:PyParser_ASTFromFileObject Parse/parsetok.c:PyParser_ParseFileObject Parse/parsetok.c:parsetok Parse/tokenizer.c:PyTokenizer_Get Parse/tokenizer.c:tok_get Parse/tokenizer.c:tok_nextc Parser/myreadline.c:PyOS_Readline OR Parse/tokenizer.c:decoding_fgets PyRun_InteractiveOneObject tries to get the input encoding via sys.stdin.encoding. The encoding is then passed along and finally stored in a tokenizer object. It is tok_nextc function that gets the input. If the prompt is not NULL it gets the data via PyOS_Readline and uses the encoding to recode it to UTF-8. This is unfortunate since the encoding, which originates in sys.stdin.encoding, can have nothing to do with the data returned by PyOS_Readline. Αlso note that there is hardcoded stdin argument to PyOS_Readline, but it probably holds tok-fp == stdin so it doesn't matter. If the prompt in tok_nextc is NULL then the data are gotten by decoding_fgets function, which either use fp_readl tok-decoding_readline or Objects/fileobject.c:Py_UniversalNewlineFgets depending on tokenizer state. tok-decoding_readline handler may be set to io.open(isisOOO, fileno(tok-fp), …) (I have no idea what isisOOO might be). PyOS_Readline function either calls PyOS_StdioReadline or the function pointed to by PyOS_ReadlineFunctionPointer which is by default again PyOS_StdioReadline, but usually is set to support GNU readline by the code in Modules/readline.c. PyOS_StdioReadline function uses my_fgets which calls fgets. Now what input() function does. input is implemented as Python/bltinmodule.c:builtin_input. It tests if we are on tty by comparing sys.stdin.fileno() to fileno(stdin) and testing isatty. Note that this may not be enough – if I inslall a custom sys.stdin but let it have standard fileno then the test may succeed. If we are tty then PyOS_Readline is used (and again together with sys.std*.encoding), if we aren't then Objects/fileobject.c:PyFile_WriteObject sys.stdout.write (for prompt) and :PyFile_GetLine sys.stdin.readline are used. As we can see, the API is rather FILE* based. The only places where sys.std* objects are used are in one branch of builtin_input, and when getting the encoding used in tokenizer. Could it be possible to configure the tokenizer so it uses sys.stdin.readline for input, and also rewrite builtin_input to allways use sys.std*? Then it would be sys.stdin.buffer.raw.read* methods' responsibility to decide whether to use GNU readline or whatever PyOS_Readline uses or something else (e.g. ReadConsoleW on Windows tty), and also check for Ctrl-C afterwards. -- ___ 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
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: Sorry for formating in the previous message. Repeating… I looked to the sourcecode and found the following. First, the codepath of how interactive loop gets its input follows: Python/pythonrun.c:PyRun_InteractiveLoopFlags Python/pythonrun.c:PyRun_InteractiveOneObject Python/pythonrun.c:PyParser_ASTFromFileObject Parse/parsetok.c:PyParser_ParseFileObject Parse/parsetok.c:parsetok Parse/tokenizer.c:PyTokenizer_Get Parse/tokenizer.c:tok_get Parse/tokenizer.c:tok_nextc Parser/myreadline.c:PyOS_Readline OR Parse/tokenizer.c:decoding_fgets PyRun_InteractiveOneObject tries to get the input encoding via sys.stdin.encoding. The encoding is then passed along and finally stored in a tokenizer object. It is tok_nextc function that gets the input. If the prompt is not NULL it gets the data via PyOS_Readline and uses the encoding to recode it to UTF-8. This is unfortunate since the encoding, which originates in sys.stdin.encoding, can have nothing to do with the data returned by PyOS_Readline. Αlso note that there is hardcoded stdin argument to PyOS_Readline, but it probably holds tok-fp == stdin so it doesn't matter. If the prompt in tok_nextc is NULL then the data are gotten by decoding_fgets function, which either use fp_readl tok-decoding_readline or Objects/fileobject.c:Py_UniversalNewlineFgets depending on tokenizer state. tok-decoding_readline handler may be set to io.open(isisOOO, fileno(tok-fp), …) (I have no idea what isisOOO might be). PyOS_Readline function either calls PyOS_StdioReadline or the function pointed to by PyOS_ReadlineFunctionPointer which is by default again PyOS_StdioReadline, but usually is set to support GNU readline by the code in Modules/readline.c. PyOS_StdioReadline function uses my_fgets which calls fgets. Now what input() function does. input is implemented as Python/bltinmodule.c:builtin_input. It tests if we are on tty by comparing sys.stdin.fileno() to fileno(stdin) and testing isatty. Note that this may not be enough – if I inslall a custom sys.stdin but let it have standard fileno then the test may succeed. If we are tty then PyOS_Readline is used (and again together with sys.std*.encoding), if we aren't then Objects/fileobject.c:PyFile_WriteObject sys.stdout.write (for prompt) and :PyFile_GetLine sys.stdin.readline are used. As we can see, the API is rather FILE* based. The only places where sys.std* objects are used are in one branch of builtin_input, and when getting the encoding used in tokenizer. Could it be possible to configure the tokenizer so it uses sys.stdin.readline for input, and also rewrite builtin_input to allways use sys.std*? Then it would be sys.stdin.buffer.raw.read* methods' responsibility to decide whether to use GNU readline or whatever PyOS_Readline uses or something else (e.g. ReadConsoleW on Windows tty), and also check for Ctrl-C afterwards. -- ___ 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
[issue22114] You cannot call communicate() safely after receiving EAGAIN
New submission from Amrith Kumar:
Environment:
- Linux (Ubuntu 14.04 LTS, x64) running Python 2.7.
- Code uses eventlet.green.subprocess
Code establishes subprocess as:
subprocess.Popen(command,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE, ...)
It then calls communicate()
communicate() throws EAGAIN
The code calls communicate() again
This fails with ValueError: I/O operation on closed file
This exception comes from eventlet/greenio.py because an operation (flush) has
been attempted on a closed file.
The complete explanation of this failure is this.
When communicate() is called in this way (WITH NO INPUT but with all three
handles stdin, stdout, stderr), code in communicate() bypasses the 1 handle
optimization and goes directly to _communicate()
_communicate() will first send any input on stdin along, and flush and close
stdin().
From that point forward, if anything to do with stderr and stdout returns
EAGAIN, an attempt to call communicate() again will fail because stdin has now
been closed().
This is because the code in _communicate() preemptively closes stdin if there
is no input but does not reset stdin.
def _communicate(self, input):
if self.stdin:
# Flush stdio buffer. This might block, if the user has
# been writing to .stdin in an uncontrolled fashion.
self.stdin.flush()
if not input:
self.stdin.close()
The fix for this is relatively straightforward (conceptually).
def _communicate(self, input):
if self.stdin:
# Flush stdio buffer. This might block, if the user has
# been writing to .stdin in an uncontrolled fashion.
self.stdin.flush()
if not input:
self.stdin.close()
self.stdin = None # This should take care of it.
However, a partial workaround from the client perspective is this.
1. If you have no input, set stdin to None
2. If you do have input and you get EAGAIN, you cannot safely retry because
your input may have already been completely or partially sent to the
subprocess; you have to assume failure.
Backtrace:
Traceback (most recent call last):
File
/opt/stack/trove/trove/tests/unittests/guestagent/test_mongodb_manager.py,
line 58, in test_prepare_from_backup
self._prepare_dynamic(backup_id='backup_id_123abc')
File
/opt/stack/trove/trove/tests/unittests/guestagent/test_mongodb_manager.py,
line 91, in _prepare_dynamic
backup_info=backup_info)
File trove/guestagent/datastore/mongodb/manager.py, line 66, in
prepare
operating_system.update_owner('mongodb', 'mongodb', mount_point)
File trove/guestagent/common/operating_system.py, line 109, in
update_owner
run_as_root=True, root_helper=sudo)
File trove/common/utils.py, line 278, in execute_with_timeout
return execute(*args, **kwargs)
File trove/openstack/common/processutils.py, line 186, in execute
result = obj.communicate()
File /usr/lib/python2.7/subprocess.py, line 799, in communicate
return self._communicate(input)
File /usr/lib/python2.7/subprocess.py, line 1396, in _communicate
self.stdin.flush()
File
/opt/stack/trove/.tox/py27/local/lib/python2.7/site-packages/eventlet/greenio.py,
line 419, in _operationOnClosedFile
raise ValueError(I/O operation on closed file)
ValueError: I/O operation on closed file
--
components: IO
messages: 224398
nosy: amrith
priority: normal
severity: normal
status: open
title: You cannot call communicate() safely after receiving EAGAIN
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22114
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving EAGAIN
Amrith Kumar added the comment: I'll supply a patch for this proposed change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving EAGAIN
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22108] python c api wchar_t*/char* passing contradiction
Martin v. Löwis added the comment: Jonas, why do you say that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22108 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17371] Mismatch between Python 3.3 build environment and distutils compiler support
Martin v. Löwis added the comment: Installing VS 2010 express was indeed the right solution. -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17371 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C properly
Drekin added the comment: Shouldn't there be a Ctrl-C check in Modules/_io/fileio.c:fileio_read* functions? I think some of these are called by standard sys.stdin.readline(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18597 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22101] collections.abc.Set doesn't provide copy() method
Akira Li added the comment: I don't think this is needed nor do I think that it is a good idea to have a copy() method in the ABCs because they know so little about their concrete underlying class (perhaps the backing store in the filesystem or a database). Besides, a user already has workable alternatives such as creating a new instance and applying |= to populate it. because they know so little about their concrete underlying class FYI, the patch demonstrates how to implement copy() for *any* MutableSet: def copy(self): return self._from_iterable(self) _from_iterable() default implementation is cls(self) i.e., the copy() method may be also efficient by default e.g., it may return the object itself for immutable types. --- The issue is closed so the rest can be ignored. In general, we don't do API expansions without motivating use cases to guide the design. The reason to add Set.copy() is the same one as for set.copy() i.e., add the equivalent of L[:] to mutable containers that don't support slicing as the documentation excerpt in msg224255 explicitly says (copy() doesn't modify its object so it can be added to immutable type). General purpose language should provide an ability to copy a container. In practice, people spell this operation as CustomSet(s) thus hardcoding the type and ruining the flexibility provided by s.copy() duck-typing (or copy.copy()). The same could be said about MutableMapping (separate issue) e.g., merge a, b dictionaries assuming no .copy() method: d = dict(a) d.update(b) vs. the same with .copy(): d = a.copy() d.update(b) The latter may also work for a custom dict. The former is hardcoded to produce a dict e.g., you have to reimplement it (and all the surrounding code) for OrderedDict, SortedDict, Splay tree -based dict, etc. Luckily projects such as blist, banyan that implement custom container types do provide copy() method. I don't see why we should make it harder to correctly implement/use custom set/dict types. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22101 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22111] Improve imaplib testsuite.
Milan Oberkirch added the comment: AntoinePitrou: Thanks for the review! I made the suggested changes and could not resist refactoring the hole thing (since I plan to spend some time on that file I wanted it to be readable and pep conform). -- Added file: http://bugs.python.org/file36178/imaplib_testV2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22111 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving EAGAIN
R. David Murray added the comment: I believe our recent thinking in recent times has been to handle EAGAIN in the higher level interfaces such as subprocess, not expose them to the caller. Does python3 have the same problem? I isn't clear that you have provided enough information to reproduce this. Any chance you could reproduce it without using eventlet? -- components: +Library (Lib) -IO nosy: +gps, r.david.murray stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22115] Add new methods to trace Tkinter variables
New submission from Serhiy Storchaka: Command used to monitor Tcl variable access (trace variable, trace vdelete, trace vinfo) are deprecated and will likely be removed in a future version of Tcl. Replacements (trace add variable, trace remove variable, trace info variable) use slightly different syntax (operations are specified as a list of words array, read, write and unset instead of a string containing characters a, r, w and u). Therefore we need new set of methods. Proposed preliminary patch adds trace_add, trace_remove and trace_info methods to the Variable class. It will be changed after applying issue22068 patch. Tests for old methods will be backported to older Python versions. -- components: Tkinter files: tkinter_trace_variable_2.patch keywords: patch messages: 224407 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Add new methods to trace Tkinter variables type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36179/tkinter_trace_variable_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22115 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22108] python c api wchar_t*/char* passing contradiction
Zachary Ware added the comment: See also issue20466 (which has a patch for this, but I cannot speak for its effectiveness). I'd be in favor of closing that issue and this one as duplicates of #18395, and noting in #18395 that the embedding example must be updated before that issue is closed. -- nosy: +zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22108 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22085] Drop support of Tk 8.3
Serhiy Storchaka added the comment: I close this issue because don't want to change topic yet once (and one feature per issue). Separate issue22115 was opened for adding new trace methods. -- resolution: - fixed stage: needs patch - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +benjamin.peterson, dw, hynek, kmike, python-dev, scoder, skrah, stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15381 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15986] memoryview: expose 'buf' attribute
Antoine Pitrou added the comment: ctypes could grow a way to access the Py_buffer API instead. -- nosy: +amaury.forgeotdarc, belopolsky, meador.inge, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO
Serhiy Storchaka added the comment: Synchronized with tip. Unfortunately there are no common points with recent issue22003 changes so they should be reverted (except tests). -- versions: +Python 3.5 -Python 3.4 Added file: http://bugs.python.org/file36180/bytesio_resized_bytes-4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15381 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving EAGAIN
Antoine Pitrou added the comment: This sounds like an issue specific to eventlet. There's no reason for the standard communicate() call to raise EAGAIN, since the created pipes are blocking. That said, if the fix is that trivial, I wouldn't be opposed to see it enter the stdlib (assuming it doesn't break anything). -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving EAGAIN
STINNER Victor added the comment: Instead of just catching EAGAIN, you can catch BlockingIOError. In Python 2.7, it means catching: (EAGAIN, EALREADY, EINPROGRESS, EWOULDBLOCK) errors. I made a similar change in asyncore recently: --- changeset: 91833:d422062d7d36 branch: 2.7 parent: 91830:841cdb6145e9 user:Victor Stinner victor.stin...@gmail.com date:Thu Jul 24 19:15:00 2014 +0200 files: Doc/library/asyncore.rst Lib/asynchat.py Lib/test/test_asynchat.py Misc/NEWS description: Issue #16133: The asynchat.async_chat.handle_read() method now ignores socket.error() exceptions with blocking I/O errors: EAGAIN, EALREADY, EINPROGRESS, or EWOULDBLOCK. Initial patch written by Xavier de Gaye. --- This issue is another reason to not use eventlet with monkey-patching :-) It's time to switch to asyncio (trollius for Python 2)! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15986] memoryview: expose 'buf' attribute
David Beazley added the comment: There are other kinds of libraries that might want to access the .buf attribute. For example, the llvmpy extension. Exposing it would be useful. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22111] Improve imaplib testsuite.
Antoine Pitrou added the comment: Thank you, Milan. The latest patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22111 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15986] memoryview: expose 'buf' attribute
Antoine Pitrou added the comment: Ha, llvmpy... Yes, it could be useful. It's dangerous too, especially since the buffer isn't necessarily contiguous. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15986] memoryview: expose 'buf' attribute
David Beazley added the comment: Well, a lot of things in this big bad world are dangerous. Don't see how this is any more dangerous than all of the peril that tools like ctypes and llvmpy already provide. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15986] memoryview: expose 'buf' attribute
David Beazley added the comment: One of the other goals of memoryviews is to make memory access less hacky. To that end, it would be nice to have the .buf attribute available given that all of the other attributes are already there. I don't see why people should need to do some even more hacky hack thing on top of hacks just to expose the pointer (which they'll figure out how to do anyway if they actually need to use it for something). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15986] memoryview: expose 'buf' attribute
Antoine Pitrou added the comment: Le 31/07/2014 11:24, David Beazley a écrit : Well, a lot of things in this big bad world are dangerous. Don't see how this is any more dangerous than all of the peril that tools like ctypes and llvmpy already provide. The point of the buffer API is to make memory access *less* dangerous than with the perilous tools, though. Otherwise we might as well decide that Python crashes because C crashes :-) (as for llvmpy, I think its implementation deserves to die) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving EAGAIN
Amrith Kumar added the comment: I see three comments, one from r.david.murray, one from haypo and one from pitrou. I'll try and address all three. r.david.murray: The code in question is in https://github.com/openstack/oslo-incubator/blob/master/openstack/common/processutils.py#L177-L189 note that we're catching EAGAIN and EINTR. I have not been able to isolate this down to a simple repro without the rest of this paraphernalia but I'm trying. So, we are 'catching' EAGAIN or EINTR here and we're trying to handle it to the best of our ability. However, if the underlying layer is not setup to handle a retry, our best efforts will be fruitless. That is what is happening here. The reason for this code (ignoring the retry of 20) was put in place exactly because a call to communicate() received an EAGAIN. The issue therefore is that in order for the higher level to properly handle this, communicate() should be setup to handle a second call, which it currently is not. haypo and pitrou: that may be true; I'm not competent to comment on that. But, as pointed out in earlier comment (and modulo this may be eventlet specific), just catching more exceptions isn't the answer. if the descriptor is closed, the thing that communicate/_communicate() call should be able to handle that situation. And this bug illustrates that at least eventlet doesn't handle that. However, I submit to you that this is NOT an eventlet issue. Here's why. The failure here is that a flush call is being attempted on a closed descriptor. I believe that the implementation of flush (in eventlet) is legitimately throwing an exception indicating that the state machine was violated (cannot flush on closed descriptor). The close() was invoked by subprocess.py after it finished doing what it thought it had to do with stdin on the first invocation. therefore I believe it must be the responsibility of subprocess.py to make sure that when invoked again, it doesn't step on itself. Either that, or subprocess.py's communicate() implementation should indicate that it can only be called once, capture all exceptions that would point a user to retry (such as EAGAIN and EINTR) and mask them and return some EFATAL. -- components: +IO -Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving EAGAIN
STINNER Victor added the comment: However, I submit to you that this is NOT an eventlet issue. (...) capture all exceptions that would point a user to retry (such as EAGAIN and EINTR) and mask them and return some EFATAL. You cannot get EAGAIN on a blocking file descriptor and subprocess uses blocking file descriptors. It looks like eventlet monkey patching makes file descriptors non-blocking. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11427] ctypes from_buffer no longer accepts bytes
eryksun added the comment:
cast calls ctypes._cast(obj, obj, typ). _cast is a ctypes function pointer
defined as follows:
_cast = PYFUNCTYPE(py_object,
c_void_p, py_object, py_object)(_cast_addr)
Since cast makes an FFI call that converts the first arg to c_void_p, you can
directly cast bytes to a pointer type:
from ctypes import *
data = b'123\x00abc'
ptr = cast(data, c_void_p)
string_at is defined similarly using c_void_p for the first arg:
_string_at = PYFUNCTYPE(py_object, c_void_p, c_int)(_string_at_addr)
string_at(ptr, 8)
b'123\x00abc\x00'
Get around the from_buffer mutability requirement by casting to an array (i.e.
to an array pointer followed by a dereference):
arr = cast(data, POINTER(c_char * len(data)))[0]
arr[:]
b'123\x00abc'
Then use byref to pass an offset into the array:
from ctypes.util import find_library
printf = CDLL(find_library('c')).printf
printf(b'%s\n', byref(arr, 4))
abc
4
Since this doesn't copy the buffer, take care to ensure the function call won't
modify the contents.
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11427
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD.
Shiz added the comment: After some further investigation it seems the which-clause fails when given a relative path. Since we should expect $HOSTPYTHON to be present in the first place, I modified the patch a bit to special-case the $HOSTPYTHON check, and fall back on the other interpreters as checked before. -- Added file: http://bugs.python.org/file36181/Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection-v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22100 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving an exception (EINTR or EAGAIN)
Changes by Amrith Kumar amr...@tesora.com: -- title: You cannot call communicate() safely after receiving EAGAIN - You cannot call communicate() safely after receiving an exception (EINTR or EAGAIN) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving an exception (EINTR or EAGAIN)
Amrith Kumar added the comment: haypo; no argument from me. I just updated the description to make it more exact. I may have received EINTR or EAGAIN. In either event, I need to debug some more and try and do a clean repro and then figure out a proper fix. In the meanwhile, I proposed a fix for the openstack code; if you are so inclined, please take a look. https://review.openstack.org/#/c/110933/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18402] Finding perl64
Steve Dower added the comment: At one point the version of OpenSSL on svn.python.org did not have the correct makefiles for a 64-bit Windows build, but this was resolved. You also don't need 64-bit Perl to generate these files, and the file has been renamed to prepare_ssl.py and appears to only be used for creating the makefiles for checking into SVN (perhaps it should move to Tools?). It's a trivial patch, but considering I don't even know who runs the file, I'm not going to go and mess with it. Zach and/or Tim presumably know. -- nosy: +tim.golden, zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18402 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving an exception (EINTR or EAGAIN)
R. David Murray added the comment: By the definition of the (blocking) communicate API, communicate can only be called once (it feeds in all the input, and reads all the output). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22114] You cannot call communicate() safely after receiving an exception (EINTR or EAGAIN)
Amrith Kumar added the comment: r.david.murray, I guess the issue we have is that something (hypothesis: eventlet) is causing the blocking API to communicate() to throw an EAGAIN. This (https://bugs.launchpad.net/nova/+bug/1271331) is the bug that was fixed a while ago in OpenStack that introduced the notion of calling communicate() multiple times. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22114 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c
Zachary Ware added the comment: The patch applies and compiles cleanly, and I finally tracked down what was causing the errors I reported yesterday: os_utime_impl was changed to use Py_RETURN_NONE instead of just setting return_value = Py_None, so Windows skipped the exit routine and left an open handle on any call to os.utime. Commented on the bad line on Rietveld. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20170 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22112] '_UnixSelectorEventLoop' object has no attribute 'create_task'
Guido van Rossum added the comment: asyncio has an explicit exemption from the general rule that bugfixes should not add new features. This is because of the provisional status of the PEP. We'll stop doing this once 3.5 is out. I don't know what's up with the online docs. On Thu, Jul 31, 2014 at 9:51 AM, Daniel Greenfeld rep...@bugs.python.org wrote: Daniel Greenfeld added the comment: First, if there is documentation that says, 3.4.1, doesn't it make sense that the documentation should only be for 3.4.1? Which means that this create_task documentation should be reverted in the 3.4.1 documentation to match the 3.4.1 specification. Second and most respectfully, why is a feature being added in 3.4.2? I thought this kind of release (3.4.1 to 3.4.2) was for bug fixes and security issues, not new features. Unless create_task was in the original 3.4 specification, I argue that create_task belongs in 3.5. In it's place, a recipe of running tasks in parallel fashion per gvanrossum's suggestion of asyncio.async() could be added. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22112 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22101] collections.abc.Set doesn't provide copy() method
Guido van Rossum added the comment: You need to learn when to give up. :-) I wasn't the one who added a copy() method to other containers. I personally despise almost all uses of copying (including the entire copy module, both deep and shallow copy functionality). I much prefer to write e.g. list(x) over x.copy() -- when I say list(x) I know the type of the result. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22101 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22112] '_UnixSelectorEventLoop' object has no attribute 'create_task'
Daniel Greenfeld added the comment: First, if there is documentation that says, 3.4.1, doesn't it make sense that the documentation should only be for 3.4.1? Which means that this create_task documentation should be reverted in the 3.4.1 documentation to match the 3.4.1 specification. Second and most respectfully, why is a feature being added in 3.4.2? I thought this kind of release (3.4.1 to 3.4.2) was for bug fixes and security issues, not new features. Unless create_task was in the original 3.4 specification, I argue that create_task belongs in 3.5. In it's place, a recipe of running tasks in parallel fashion per gvanrossum's suggestion of asyncio.async() could be added. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22116] Weak reference support for C function objects
New submission from Antoine Pitrou: Currently, it is not possible to take a weakref to a PyCFunction object. However, those objects already have full GC support, so it wouldn't be silly to add weakref support to them. (this came in the context of numba, which generates such C functions on-the-fly) -- components: Interpreter Core messages: 224432 nosy: pitrou priority: normal severity: normal status: open title: Weak reference support for C function objects type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22116 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22110] enable extra compilation warnings
Charles-François Natali added the comment: Antoine Pitrou added the comment: Enabling the warnings may be a good incitation for other people to fix them ;) That was my intention... Can I push it, and let warnings be fixed on a case-by-case basis? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22110 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15862] IDLE not working when due to wrong Hard Drive point of os.path.expanduser
Changes by Serhiy Storchaka storch...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15862 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19923] OSError: [Errno 512] Unknown error 512 in test_multiprocessing
Charles-François Natali added the comment: Closing, since it's likely a kernel bug. -- resolution: - third party stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19923 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19062] problems with pyshell to get userdir
Changes by Serhiy Storchaka storch...@gmail.com: -- components: +Windows stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19062 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15152] test_subprocess failures on awfully slow builtbots
Charles-François Natali added the comment: Closing, I haven't seen this in a while. -- resolution: - out of date stage: needs patch - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15152 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18142] Tests fail on Mageia Linux Cauldron x86-64 with some configure flags
Mark Lawrence added the comment: Is there anything we can do here, do we close it as out of date or what? -- nosy: +BreamoreBoy type: - behavior versions: +Python 3.4, Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18142 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1702036] Make Turtle thread-safe so it does not crash
Lita Cho added the comment: Hey! So I have been investigating this bug, but I wanted to know is the issue the fact that korka wants to create multiple turtles or do you really want to use multiple threads with Turtle? I feel like this crash is due to Tkinter not being thread safe and I am not sure how turtle can go about working around this other than creating a scheduler within turtle. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1702036 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1702036] Make Turtle thread-safe so it does not crash
Lita Cho added the comment: I also want to note that you can create duplicate turtles by using clone, and I am not sure why you would use multiple inheritance to draw more than 1 turtle running around. I didn't think turtle was meant to be used this way. In order to draw multiple turtles, I would use the clone method. Is this to draw turtles running at the same time? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1702036 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17085] test_socket crashes the whole test suite
Mark Lawrence added the comment: Is this still an issue with Python 2.7.8? (I don't have 2.7 or linux to test on) -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20540] Python 3.3/3.4 regression in multiprocessing manager ?
Serhiy Storchaka added the comment: What would you say about multi_nagle_simplify.patch, Antoine? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20540 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21860] Correct FileIO docstrings
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: docs@python - haypo stage: needs patch - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21860 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17923] test glob with trailing slash fail
Mark Lawrence added the comment: Couldn't part of the patch be simplified to:- if basename or os.path.isdir(dirname): yield pathname or have I misread it? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17923 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18004] test_list.test_overflow crashes Win64
Mark Lawrence added the comment: What if anything needs to be done here? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18004 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18188] ERROR: test_no_optimize_flag on Mageia Linux Cauldron x86-64 with certain configure flags
Mark Lawrence added the comment: Is this still a problem with later versions of Python on this platform? -- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18188 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17085] test_socket crashes the whole test suite
Charles-François Natali added the comment: Thanks for the reminder Mark. Yes, it is probably still an issue with the latest 2.7 release. There were actually two issues: - send send()/sendall() call didn't block because the test doesn't write enough data: we have since added a SOCK_MAX_SIZE constant to test_support just for that purpose, and the test has been updated, so it should now block (and succeed). - the crash occurs because the test doesn't reset the alarm (with alarm(0)) upon exit, so if the alarm didn't go off during the test, it comes later when the original signal handler has been reset, and the default handler just exits. To sum up, the first point is already fixed, and for the second point, here's a patch. Note that 3.4 and default aren't affected, because the alarm is properly reset. -- keywords: +patch nosy: +neologix Added file: http://bugs.python.org/file36182/reset_sigalrm_handler.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22108] python c api wchar_t*/char* passing contradiction
Jonas Jelten added the comment: Martin, i think the most intuitive and easiest way for working with strings in C are just char arrays. Starting with the main() argv being char*, probably most programmers just go with char* and all the encoding just works. This is because contact with encoding is only needed for the user input software (xorg, keyboard input) and user output (- your terminal emulator, the gui, ...). No matter what stuff your program receives, the encoding only matters for the actual output display software to select the correct visual representation. Requiring a conversion to wide chars just increases the interface complexity and adds really unneeded data transformations that are completely obsolete with UTF-8. What I'd really like to see in CPython is that the internal storage (and the way it's exposed in the C-API) is just raw bytes (= char*). This allows super-easy integration in C projects that probably all just use char as their string type (see the doc example mentioned earlier). PEP 393 states: (..) the specification chooses UTF-8 as the recommended way of exposing strings to C code. And for that, I think using char instead of wchar_t is a better solution for interface developers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22108 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22110] enable extra compilation warnings
Antoine Pitrou added the comment: Le 31/07/2014 13:51, Charles-François Natali a écrit : Enabling the warnings may be a good incitation for other people to fix them ;) That was my intention... Can I push it, and let warnings be fixed on a case-by-case basis? +1 from me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22110 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22116] Weak reference support for C function objects
Changes by Antoine Pitrou pit...@free.fr: -- keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22116 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21859] Add Python implementation of FileIO
Serhiy Storchaka added the comment: Next iteration of the patch addressed Victor's and Akira's comments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21859 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21859] Add Python implementation of FileIO
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file36183/pyio_fileio_5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21859 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11429] ctypes is highly eclectic in its raw-memory support
eryksun added the comment:
Extending byref to support bytes and str objects sounds reasonable.
Here's another workaround to pass a bytes object with an offset:
from ctypes import *
from ctypes.util import find_library
class offset:
def __init__(self, arg, offset):
self.arg = arg
self.offset = offset
class my_char_p(c_char_p):
@classmethod
def from_param(cls, arg):
if isinstance(arg, offset):
t = cast(arg.arg, POINTER(c_char * 0))[0]
carg = byref(t, arg.offset)
else:
carg = super().from_param(arg)
return carg
atoi = CDLL(find_library('c')).atoi
atoi.argtypes = [my_char_p]
atoi(b'12345')
12345
atoi(offset(b'12345', 1))
2345
atoi(offset(b'12345', 3))
45
You can also convert bytearray, memoryview, and array.array objects from_param.
If the object's buffer is writable you can use a ctypes type's from_buffer
method to create the C arg. This takes an optional offset argument. Otherwise
use from_buffer_copy or cast.
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11429
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22111] Improve imaplib testsuite.
Roundup Robot added the comment: New changeset 6b2cafab7a9f by Antoine Pitrou in branch 'default': Issue #22111: Assorted cleanups in test_imaplib. Patch by Milan Oberkirch. http://hg.python.org/cpython/rev/6b2cafab7a9f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22111 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22111] Improve imaplib testsuite.
Antoine Pitrou added the comment: This is now pushed. -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22111 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20540] Python 3.3/3.4 regression in multiprocessing manager ?
Roundup Robot added the comment: New changeset 20fd13242a45 by Antoine Pitrou in branch 'default': Simplify code in multiprocessing.Connection.send_bytes(). http://hg.python.org/cpython/rev/20fd13242a45 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20540 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks
Dan O'Reilly added the comment: I've attached an updated patch based on your review comments; there's now a unit test with a non-default chunksize, the chunking algorithm is more readable, and the same code path is used no matter what chunksize is provided. I've also updated the test script to match the implementation changes. -- Added file: http://bugs.python.org/file36184/map_chunksize_with_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks
Changes by Dan O'Reilly oreil...@gmail.com: Removed file: http://bugs.python.org/file36065/test_mult.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks
Changes by Dan O'Reilly oreil...@gmail.com: Added file: http://bugs.python.org/file36185/test_mult.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
New submission from STINNER Victor: To prepare Python to add support of monotonic clock in pytime.h, I propose to rewrite pytime.h to use a new _PyTimeSpec structure which has a resolution of 1 nanosecond on only work on integers. Currently, pytime.h uses a _PyTime_timeval structure which has a solution of 1 microsecond and works internally on floating point numbers. Computing the difference between two timestamps may loose precision. The tv_nsec field of _PyTimeSpec must be in the range [0; 9], even for negative numbers. For example, -1 ns is stored as (-1, 9). This property makes the code more complex, especially to round correctly. The new API is based on the idea that all timestamps must be stored as _PyTimeSpec. Convert a value into a _PyTimeSpec: - _PyTimeSpec_from_double(): C double - _PyTimeSpec_from_object(): Python int or float object - you can also fill directly the tv_sec and tv_nsec fields Convert a _PyTimeSpec timestamp into a value: - _PyTimeSpec_to_time_t(): C time_t - _PyTimeSpec_to_timeval(): C timeval (tv_sec, tv_usec), but ot directly the structure because the exact structure is different depending on the OS and OS version - _PyTimeSpec_ms(): C long, number of milliseconds Operations on _PyTimeSpec: - _PyTimeSpec_add(): a+b - _PyTimeSpec_sub(): a-b I removed high-level functions like _PyTime_ObjectToTimeval(): you should now combine _PyTimeSpec_from_object() with _PyTimeSpec_to_timeval(). I did this to not multiply the number of functions, because I want to test all functions in unit tests and have a short API. I tried to enhance detecton of overflow. I didn't review carefuly my patch yet. I'm not sure that all calls check for error and handle exceptions correctly. Only the following functions raise an exception on error: - _PyTimeSpec_from_object() - _PyTimeSpec_to_time_t() - _PyTimeSpec_to_timeval() Other functions sets the minimum/maximum value in case of underflow/overflow. So even if you don't check for errors, the behaviour on overflow should be acceptable. The new _PyTimeSpec_Init() function checks that the system clock works, so _PyTimeSpec_get_time() and _PyTimeSpec_get_time_info() don't need to check for error. In fact, these functions call Py_FatalError() on error, but it should never happen. This idea was proposed in the issue #22043 to check if the monotonic clock is working. Maybe we can avoid checking the system clock in _PyTimeSpec_Init() and only check the monotonic clock. I hope that all platforms have a working system clock! The oppoosite would be a huge issue. The patch removes function which are exposed in the stable ABI. Since the functions are private, name starting with (_Py), I consider that it's ok to remove them. The functions are replaced with new functions which a have a new name. I excluded pytime.h from the stable ABI. I don't know why private functions were part of the stable ABI :-/ The patch comes with unit tests for each function. I didn't implement handling of overflow and underflow in _PyTimeSpec_add() and _PyTimeSpec_sub() yet. But I implemented detection for overflow for the simple case. See also: - Issue #22043: Use a monotonic clock to compute timeouts. - PEP 410: Use decimal.Decimal type for timestamps (rejected) -- files: timespec.patch keywords: patch messages: 224452 nosy: haypo priority: normal severity: normal status: open title: Rewrite pytime.h to work on nanoseconds versions: Python 3.4 Added file: http://bugs.python.org/file36186/timespec.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22117 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
Changes by Antoine Pitrou pit...@free.fr: -- type: - enhancement versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22117 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +belopolsky, tim.peters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22117 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh
Antoine Pitrou added the comment: Why not simply use $SHELL? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16255 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18651] test failures on KFreeBSD
Mark Lawrence added the comment: A different patch is still needed for 3.4. -- nosy: +BreamoreBoy type: - behavior versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18651 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11429] ctypes is highly eclectic in its raw-memory support
Martin Panter added the comment: Interesting that “cast” accepts a byte string. If this is intended behaviour, it would be good to document that. Currently it says it takes “an object that can be interpreted as a pointer”. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11429 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22043] Use a monotonic clock to compute timeouts
STINNER Victor added the comment: pytimespec.patch become too large, I splitted this patch into a new issue: issue #22117. If this issue is rejected, I will rewrite pymonotonic-2.patch to use the _PyTime_timeval structure. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Mark Lawrence added the comment: Is there any possibility of getting this into 3.5? If it helps I've always got time on my hands so if nothing else I could do testing on Windows 8.1. -- nosy: +BreamoreBoy, zach.ware versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7897 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7944] Use the 'with' statement in conjunction with 'open' throughout test modules
Mark Lawrence added the comment: Following on from msg185817 I'd suggest this is closed. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20056] Got deprecation warning when running test_shutil.py on Windows NT 6
Mark Lawrence added the comment: The deprecation warnings are coming from the various os calls so are nothing to do with test_shutil. I think this can be closed as not a bug. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20056 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7944] Use the 'with' statement in conjunction with 'open' throughout test modules
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7897 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
STINNER Victor added the comment: Oh, I forgot to mention that the patch of the issue #22043 also changes _PyTimeSpec_get_time() to use clock_gettime(CLOCK_REALTIME) which has a resolution of 1 nanosecond. _PyTimeSpec_get_time() already uses GetSystemTimeAsFileTime() which has a resolution of 100 nanosecond. See also the issue #19007 precise time.time() under Windows 8: use GetSystemTimePreciseAsFileTime. I'm talking about the resolution of the C structure. The effive resolution can be much worse than that. For example, the resolution measured in Python of clock_gettime(CLOCK_REALTIME) is closer to 160 nanoseconds (on my laptop) than 1 nanoescond. See the Python Resolution column the second table of: http://legacy.python.org/dev/peps/pep-0418/#system-time -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22117 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
STINNER Victor added the comment: The effective* resolution -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22117 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22108] python c api wchar_t*/char* passing contradiction
STINNER Victor added the comment: What I'd really like to see in CPython is that the internal storage (and the way it's exposed in the C-API) is just raw bytes (= char*). Python is portable, we care of Windows. On Windows, wchar_t* is the native type for strings (ex: command line, environment variables). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22108 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
