[issue21403] cElementTree's Element creation handles attrib argument different from ET
Stefan Behnel added the comment: Works for me in 3.2 and 3.4, fails in 2.7, as reported. I'll leave it to Eli to decide if this should get fixed in 2.7. In Py2, ET and cET were different modules, so this could also be considered a missing feature in cET. Given that it leads to a serialisation failure, though, it shouldn't hurt to change the behaviour. (changing title to something more specific) -- nosy: +scoder title: cElementTree creation of nodes with attributes is bugged - cElementTree's Element creation handles attrib argument different from ET ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21403 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21403] cElementTree's Element creation handles attrib argument different from ET
Stefan Behnel added the comment:
Ah, sorry, actually, it does not work in Py3.2:
import xml.etree.cElementTree as cET
root = cET.Element('root', attrib={'Name':'Root'})
child = cET.SubElement(root, 'child', attrib={'Name':'Child'})
cET.tostring(root)
b'root attrib={\'Name\': \'Root\'}child attrib={\'Name\': \'Child\'}
//root'
That's even worse than in 2.7 as it doesn't raise an exception.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21403
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21403] cElementTree's Element creation handles attrib argument different from ET
Stefan Behnel added the comment: According to issue 1572710, this is not a bug. The attrib argument is supposed to be a positional argument, not a keyword argument. This makes sense, given that arbitrary keyword arguments are accepted for additional XML attributes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21403 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21405] Allow using symbols from Unicode block Superscripts and Subscripts in identifiers
New submission from Roman Inflianskas: It's really useful that python 3 allows me to use some Unicode symbols (as specified in https://docs.python.org/3.4/reference/lexical_analysis.html#identifiers), especially Greek symbols for mathematical programs. But when I write mathematical program with lots of indices I would like to use symbols from block Superscripts and Subscripts (as id_continue), for example: ⁴₂₍₎ I don't see any problems with allowing yet another subset of Unicode symbols. In Julia, for example, I can use them without problems. -- components: Unicode messages: 217681 nosy: ezio.melotti, haypo, rominf priority: normal severity: normal status: open title: Allow using symbols from Unicode block Superscripts and Subscripts in identifiers versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21405 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21351] refcounts not respected at process exit
STINNER Victor added the comment: Never rely on the GC. Avoid cycles by using the weakref module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21351 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 indicate a deadlock. -- Added file: http://bugs.python.org/file35124/subprocess-line-buffering-issue21332-ps2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Python version. For Reference - issue #12591 introduces `write_through` to support subprocess' stdin pipe in text mode with bufsize=0 i.e., TextIOWrapper.buffer is unbuffered (raw) and Python and C implementation behave the same in this particular case. C implementation (pseudo-code):: if self.write_through: flush_text_buffer() buffer.flush() # -- undocumented Python implementation:: if self.write_through: pass # _pyio.TextIOWrapper.write() calls buffer.write() directly behaves according to the current documentation [1]: If *write_through* is ``True``, calls to :meth:`write` are guaranteed not to be buffered: any data written on the :class:`TextIOWrapper` object is immediately handled to its underlying binary *buffer* [1]: hg.python.org/cpython/file/2a56d3896d50/Doc/library/io.rst For reference, here's how subprocess.py uses write_through [2]:: self.stdin = io.open(pipe, 'wb', bufsize) if universal_newlines=True: self.stdin = io.TextIOWrapper(self.stdin, write_through=True, line_buffering=(bufsize == 1)) # -- issue #21332 http://hg.python.org/cpython/rev/9ce8fa0a0899/ - introduce io.TextIOWrapper in subprocess http://hg.python.org/cpython/rev/5cc536fbd7c1 - introduce write_through [2]: http://hg.python.org/cpython/file/2a56d3896d50/Lib/subprocess.py#l849 -- keywords: +patch Added file: http://bugs.python.org/file35125/io-write_through-c-vs-python-issue21396.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21396 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2159] dbmmodule inquiry function is performance prohibitive
Jesús Cea Avión added the comment: OK, you did your homework. I checked PyObject_Is_True() function and I agree. This actually looks like a leak when True/False were added to Python. Python3 is inheriting it :-). OK. I see three issues in the code: a) You are getting a key from the database, and you are not freeing it. So, this code leaks memory. b) You should check database errors too. Documentation says When the end of the database is reached, the dptr member of the key is a null pointer. If an error is detected, the dptr member of the key shall be a null pointer and the error condition of the database shall be set.. Raise an exception with the proper error. Would be nice to test that too, but it is probably nos possible. c) Please, use NULL instead of 0. Thanks for your effort, Eric. -- assignee: - jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21391] PATCH: using the abspath shortcut in Lib/shutil
Yinon Ehrlich added the comment: Use the 'abspath' shortcut instead of 'os.path.abspath' See the attached patch (sorry, forgot to attach before) -- keywords: +patch Added file: http://bugs.python.org/file35126/shutil.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21391 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21405] Allow using symbols from Unicode block Superscripts and Subscripts in identifiers
Steven D'Aprano added the comment: 3.1, 3.2, 3.3 and 3.4 are all in feature-freeze, so this is only an option for 3.5. A very tentative +1 on this feature. But I fear it may need to be discussed on python-ideas first. -- nosy: +steven.daprano type: - enhancement versions: -Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21405 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21391] PATCH: using the abspath shortcut in Lib/shutil
Eric V. Smith added the comment: Wouldn't it be better to switch uses of abspath to be os.path.abspath? os.path is used elsewhere in the file, after all. Brett added from os.path import abspath in http://hg.python.org/cpython/rev/686e5d38be42 but I think that import should be deleted and os.path.abspath used directly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21391 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21391] PATCH: using the abspath shortcut in Lib/shutil
Changes by Eric V. Smith e...@trueblade.com: -- stage: - patch review type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21391 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
Antoine Pitrou added the comment:
Actually, the test hangs after one of the threads crashes:
test__all__ (test.test_poplib.TestPOP3_SSLClass) ... Exception in thread
Thread-23:
Traceback (most recent call last):
File /home/antoine/cpython/default/Lib/threading.py, line 920, in
_bootstrap_inner
self.run()
File /home/antoine/cpython/default/Lib/test/test_poplib.py, line 218, in run
asyncore.loop(timeout=0.1, count=1)
File /home/antoine/cpython/default/Lib/asyncore.py, line 212, in loop
poll_fun(timeout, map)
File /home/antoine/cpython/default/Lib/asyncore.py, line 153, in poll
read(obj)
File /home/antoine/cpython/default/Lib/asyncore.py, line 87, in read
obj.handle_error()
File /home/antoine/cpython/default/Lib/asyncore.py, line 83, in read
obj.handle_read_event()
File /home/antoine/cpython/default/Lib/asyncore.py, line 422, in
handle_read_event
self.handle_accept()
File /home/antoine/cpython/default/Lib/asyncore.py, line 499, in
handle_accept
self.handle_accepted(*pair)
File /home/antoine/cpython/default/Lib/test/test_poplib.py, line 228, in
handle_accepted
self.handler_instance = self.handler(conn)
File /home/antoine/cpython/default/Lib/test/test_poplib.py, line 368, in
__init__
self.push('+OK dummy pop3 server ready. timestamp')
File /home/antoine/cpython/default/Lib/test/test_poplib.py, line 82, in push
asynchat.async_chat.push(self, data.encode(ISO-8859-1) + b'\r\n')
File /home/antoine/cpython/default/Lib/asynchat.py, line 190, in push
self.initiate_send()
File /home/antoine/cpython/default/Lib/asynchat.py, line 243, in
initiate_send
self.handle_error()
File /home/antoine/cpython/default/Lib/asynchat.py, line 241, in
initiate_send
num_sent = self.send(data)
File /home/antoine/cpython/default/Lib/asyncore.py, line 366, in send
result = self.socket.send(data)
File /home/antoine/cpython/default/Lib/ssl.py, line 667, in send
return self._sslobj.write(data)
ssl.SSLWantReadError: The operation did not complete (read) (_ssl.c:1636)
This was due to a simplistic handling of asyncore SSL connections in
test_poplib, which I've fixed by reusing the code from test_ftplib.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21109] tarfile: Traversal attack vulnerability
Lars Gustäbel added the comment: Let me present for discussion a proposal (and a patch with documentation) with an approach that is a little different, but in my opinion the most effective. I hope that it will appeal to all involved. My proposal consists of a new class SafeTarFile, that is a subclass and drop-in replacement for the TarFile class and can be employed whenever the user feels the necessity. It can be used the same way as TarFile, with the difference that SafeTarFile is equipped with a wide range of tests and as soon as it detects anything bad it interrupts the current operation with a SecurityError exception. This way damage is effectively averted, and it is up to the developer to decide whether he rejects the archive altogether (which is the obvious and recommended measure) or he wants to continue to process it in a subsequent step (on his own responsibility). To simplify a few common operations, SafeTarFile has three more methods: analyze(), filter() and is_safe(). These methods will allow access to the archive without SecurityError exceptions being raised. The analyze() method is a kind of low-level iterator that produces each TarInfo object together with a list of warnings (if the member is bad) as a tuple. This gives a developer access to all the information he needs to implement his own more differentiated way of handling bad archives. The filter() method is a convenience method that provides an iterator over all the good members of an archive leaving out all the bad ones. It can be used as an argument to SafeTarFile.extractall() for example. is_safe() is a high-level shortcut method that reduces the result of the analysis to a simple True or False. SafeTarFile has a variety of checks that test e.g. for bad pathnames, bad permissions and duplicate files. Also, to prevent denial-of-service scenarios, it enforces user-defined limits upon the archive, such as a maximum number of files or a maxmimum size of unpacked data. The main advantage of this approach is the higher degree of security. The practice of rewriting paths (e.g. like in Daniel.Garcia's patch) is error-prone, has side-effects and is hard to maintain because of its tendency towards regression. It just adds another layer of complexity to an already complex and delicate problem. SafeTarFile (or whatever it will be called) is backward compatible and easy to maintain, because it is an isolated addition to the tarfile module. It is easily subclassable to add more tests. It can be used as a standalone tool to check for bad archives and possible denial-of-service scenarios. Its analyze() method tells the user exactly what's wrong with the archive instead of keeping it away from him. Instead of silently extracting files to locations they weren't expected to be stored (i.e. after fixing their pathnames), SafeTarFile simply refuses to extract them at all. This way it is far more transparent and understandable to the user what happens. Feedback is welcome. -- assignee: - lars.gustaebel priority: release blocker - normal versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file35127/safetarfile-1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21109 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21406] Some socket constants are not enums
New submission from Antoine Pitrou:
Many constants in the socket module, are not int enums. Examples are
socket.CAN_BCM, socket.BTPROTO_RFCOMM, etc.
For example when creating a bluetooth socket, you may get the following repr():
socket.socket(socket.AF_BLUETOOTH, socket.SOCK_STREAM,
socket.BTPROTO_RFCOMM)
socket.socket fd=3, family=AddressFamily.AF_BLUETOOTH,
type=SocketType.SOCK_STREAM, proto=3, laddr=('00:00:00:00:00:00', 0),
raddr=('00:00:00:00:00:00', 0)
(notice the integer proto)
--
messages: 217691
nosy: barry, eli.bendersky, ethan.furman, neologix, pitrou
priority: low
severity: normal
status: open
title: Some socket constants are not enums
type: enhancement
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21406
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21405] Allow using symbols from Unicode block Superscripts and Subscripts in identifiers
Antoine Pitrou added the comment: I think python-dev or python-ideas should indeed be consulted before. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21405 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21404] Compression level for tarfile/zipfile
Lars Gustäbel added the comment: tarfile.open() actually supports a compress_level argument for gzip and bzip2 and a preset argument for lzma compression. -- nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21404 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21377] PyBytes_Concat could try to concat in-place
Antoine Pitrou added the comment: Thanks! The latest patch looks fine to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21377 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21377] PyBytes_Concat could try to concat in-place
Roundup Robot added the comment: New changeset 4ed1b6c7e2f3 by Antoine Pitrou in branch 'default': Issue #21377: PyBytes_Concat() now tries to concatenate in-place when the first argument has a reference count of 1. http://hg.python.org/cpython/rev/4ed1b6c7e2f3 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21377 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21377] PyBytes_Concat could try to concat in-place
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21377 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21405] Allow using symbols from Unicode block Superscripts and Subscripts in identifiers
Roman Inflianskas added the comment: I'm sorry, I didn't now that bugtracker is not for features discussing. I'll wrote the letter to the python-ideas: https://groups.google.com/forum/#!topic/python-ideas/yjR7j9TSFeE -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21405 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21407] Add function signatures to _decimal
Changes by Stefan Krah stefan-use...@bytereef.org: -- assignee: skrah components: Extension Modules nosy: skrah priority: normal severity: normal status: open title: Add function signatures to _decimal type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21407 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21407] Add function signatures to _decimal
New submission from Roundup Robot: New changeset 40b06a75d1c6 by Stefan Krah in branch 'default': Issue #21407: _decimal now supports function signatures. http://hg.python.org/cpython/rev/40b06a75d1c6 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21407 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21399] inspect and class methods
Stefan Krah added the comment: Okay, thanks. I've used $cls for Decimal.from_float in 40b06a75d1c6, and it appears to work already. Feel free to close the issue (I don't know whether AC emits $cls or if it should). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21399 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21407] Add function signatures to _decimal
Changes by Stefan Krah stefan-use...@bytereef.org: -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21407 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21408] delegation of `!=` to the right-hand side argument is not always done
New submission from Jean-Paul Calderone: $ ~/Projects/cpython/3.4/python -c ' class Foo(object): def __ne__(self, other): return yup def __eq__(self, other): return nope class Bar(object): pass print(object() != Foo(), object() == Foo()) print(Bar() != Foo(), Bar() == Foo()) ' yup nope False nope $ The output I would expect from this is yup nope yup nope That is, even when the type of the left-hand argument is not a base class of the type of the right-hand argument, delegation to the right-hand argument is sensible if the left-hand argument does not implement the comparison. Note that the output also demonstrates that this is already the behavior for `==`. Only `!=` seems to suffer from this issue. -- components: Interpreter Core messages: 217699 nosy: exarkun priority: normal severity: normal status: open title: delegation of `!=` to the right-hand side argument is not always done type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21408] delegation of `!=` to the right-hand side argument is not always done
Benjamin Peterson added the comment: That's because the implicit default __ne__ on Bar returns the opposite of __eq__. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21400] Code coverage documentation is out-of-date.
Changes by Brett Cannon br...@python.org: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons
Brett Cannon added the comment: Unfortunately it's impossible to warn against this in Python 2 since the bytes type is just another name for the str type: str == bytes True type(b'1') type 'str' What we could potentially do, though, is change things such that -3 does what you are after when comparing bytes/str to unicode in Python 2. Unfortunately in that instance it's still a murky question as to whether that will help things more than hurt them as some people explicitly leave strings as-is in both Python 2 and Python 3 for either speed or code simplicity reasons. -- nosy: +brett.cannon title: python2 -3 does not warn about str to bytes conversions and comparisons - python2 -3 does not warn about str/unicode to bytes conversions and comparisons ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21404] Compression level for tarfile/zipfile
Sworddragon added the comment: Could it be that compress_level is not documented? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21404 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21404] Compression level for tarfile/zipfile
Lars Gustäbel added the comment: That's right. But it is there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21404 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21404] Compression level for tarfile/zipfile
Sworddragon added the comment: Then this one is easy: The documentation needs just an update. But then there is still zipfile that doesn't provide (or at least document) a compression level. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21404 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons
Joshua J Cogliati added the comment: Hm. That is a good point. Possibly it could only be done when from __future__ import unicode_literals has been used. For example: python2 -3 Python 2.7.5 snip Type help, copyright, credits or license for more information. type(ba) == type(a) True from __future__ import unicode_literals type(ba) == type(a) False ba == a True ba + a u'aa' After unicode_literals is used, then ba and a have a different type and the same code would be an issue in python3: python3 Python 3.3.2 snip type(ba) == type(a) False ba == a False ba + a Traceback (most recent call last): File stdin, line 1, in module TypeError: can't concat bytes to str -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21403] cElementTree's Element creation handles attrib argument different from ET
Santoso Wijaya added the comment:
There is still a matter of inconsistency between the two implementations and
between 2.7 and 3.x. IMO, the Python-based ElementTree implementation is more
graceful at handling the attrib argument.
The signature of the factory function Element (and SubElement) in the doc is
thus:
class xml.etree.ElementTree.Element(tag, attrib={}, **extra)
which is fair game for the user to use attrib as a keyword argument.
Further, this serialization (in 3.x) does not really make sense, anyway:
cET.tostring(root)
b'root attrib={\'Name\': \'Root\'}child attrib={\'Name\': \'Child\'}
//root'
--
components: +XML
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21403
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21403] cElementTree's Element creation handles attrib argument different from ET
Santoso Wijaya added the comment:
Quoting dabrahams in issue 1572710:
On second thought, I see what effbot is trying to say... but it's still a bug.
Given the way the interface is declared and the behavior of regular python
functions:
Element(tag, attrib={}, **extra)
indicates that I can pass attrib (or tag, for that matter) as a keyword
argument. Nothing in the documentation gives the C implementation permission
to behave differently.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21403
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21403] cElementTree's Element creation handles attrib argument different from ET
Stefan Behnel added the comment: Note that this has been fixed in Py3 already (Py3.3, I guess). The only question is whether the behaviour will be changed in Py2.7. -- components: -XML ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21403 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21403] cElementTree's Element creation handles attrib argument different from ET
Eli Bendersky added the comment: Note that this has been fixed in Py3 already (Py3.3, I guess). The only question is whether the behaviour will be changed in Py2.7. I don't think this issue is acute enough to warrant fixes in 2.7; however, a documentation patch would be welcome. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21403 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21400] Code coverage documentation is out-of-date.
Changes by Antoine Pitrou pit...@free.fr: -- components: +Devguide nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21406] Some socket constants are not enums
Charles-François Natali added the comment: Enum are for, well, enumerated values, so for values within a finite and known range (like days, cards, etc). OTOH, I'm not sure all socket constants could be categorized like this. It makes sense for address families, especially since they're used so much, but when it comes to e.g. SO_REUSEADDR or BTPROTO_RFCOMM, I'm not sure how we could categorize them. Unless would declare them all in a SocketConstant Enum? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21406 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1599254] mailbox: other programs' messages can vanish without trace
David Watson added the comment: On Mon 28 Apr 2014, Jim Jewett wrote: pinging David Watson: What is the status? If I understand correctly, (and I may well not), you have already opened other issues for parts of this, and (only) the final patch is ready for patch (and hopefully) commit review. Is this correct? No, I haven't opened any separate issues (I would be perfectly happy with fixing the original renaming-vs-copying problem and then leaving this issue open to deal with the rest). The patches mailbox-copy-back-2.7.diff and mailbox-tests-2.7-part1-for-copy-back.diff are what I suggest applying for the renaming-vs-copying problem. I haven't looked at the other patches in much detail, but for what it's worth, the tests in mailbox-tests-2.7-part2.diff do pass with mailbox-update-toc-again.diff applied. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1599254 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21406] Some socket constants are not enums
R. David Murray added the comment: This is why we should have had named constants and not Enums :) But no, nothing in the python Enum implementation restricts it to a value *range*. It is really a collection of named constants. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21406 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21406] Some socket constants are not enums
Charles-François Natali added the comment: But no, nothing in the python Enum implementation restricts it to a value *range*. It is really a collection of named constants. I didn't say in the implementation, I said in spirit. Would you describe all possible Unix PIDs are a Enum? Also, the problem is that many such constant can have identical values (because they can be passed at different syscalls/argument offset), and in this case the IntEnum equality isn't wanted: cf@neobox:~/python/hg/default$ cat /tmp/test.py from enum import IntEnum class Const(IntEnum): AF_INET = 1 SO_REUSEADDR = 1 print(Const.AF_INET == Const.SO_REUSEADDR) cf@neobox:~/python/hg/default$ ./python /tmp/test.py True Really? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21406 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21406] Some socket constants are not enums
Antoine Pitrou added the comment: It makes sense for address families, especially since they're used so much, but when it comes to e.g. SO_REUSEADDR or BTPROTO_RFCOMM, Hmm, I was thinking mostly about protocol numbers. All the BTPROTO_* constants should be part of a given enum (BlueToothProtocol?), the CAN_* constants part of another one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21406 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21406] Some socket constants are not enums
Charles-François Natali added the comment: To put it slightly differently: AF_XXX constant actually whome belong to the same namespace, the socket address family namespace. So we put them all in AddressFamily Enum. Now, for many constants defined in system header files, it's not so clear, e.g. BTPROTO_RFCOMM, TIPC_ADDR_ID, SCM_CREDENTIALS: in which Enum would you declare them? I'm not saying it's a bad idea: it actually probably makes sense for e.g. socket-level options (SO_REUSEADDR Co), but it don't see any generic classification scheme that would make sense for all of them. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21406 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21406] Some socket constants are not enums
Antoine Pitrou added the comment: Ah, I missed the fact that the family and type properties are re-computed on the fly; I thought the enum values where stored on the socket object. Then it makes it harder to do the same for proto, since there are family-specific namespaces with colliding values, indeed. socket.IPPROTO_ICMP 1 socket.BTPROTO_HCI 1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21406 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21409] setup.py check - should fail and retrun a non 0 exit code
New submission from Jeff Hinrichs: python setup.py check python setup.py check --restructuredtext both incorrectly warn and don't Fail for things that will cause a failure when uploading to pypi. This is wrong. Additionally, they should return a non 0 exit code so they can be used as part of an CI such as drone.io / travis so the build will show as failing. Currently they do not, and if there are errors that will cause a pypi failure (like an unreadable long description) bad things happen. -- components: Distutils messages: 217719 nosy: dstufft, dundeemt, eric.araujo priority: normal severity: normal status: open title: setup.py check - should fail and retrun a non 0 exit code type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21409 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21409] setup.py check - should fail and retrun a non 0 exit code
Jeff Hinrichs added the comment: example: (dhp)jlh@jlh-d520:~/Projects/dhp/src$ python setup.py check running check (dhp)jlh@jlh-d520:~/Projects/dhp/src$ python setup.py check --restructuredtext running check warning: check: Title underline too short. (line 2) warning: check: Could not finish the parsing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21409 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21410] setup.py check --restructuredtext -- appears to pass if docutils not installed
New submission from Jeff Hinrichs: if you run setup.py check --restructuredtext without docutils installed, it will appear to pass if you add the -s flag, it will error and inform you that docutils is not installed. So nothing is reported and return results are the same as a passing check. $ python setup.py check --restructuredtext running check $ python setup.py check --restructuredtext -s running check error: The docutils package is needed. The not strict version is a little too loose to be of any good. -- components: Distutils messages: 217721 nosy: dstufft, dundeemt, eric.araujo priority: normal severity: normal status: open title: setup.py check --restructuredtext -- appears to pass if docutils not installed versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21410 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21411] Enable Treat Warning as Error on 32-bit Windows
New submission from Zachary Ware: Python 3.4 and 3.5 both compile without warnings on 32-bit Windows, so we should turn on Treat Warning as Error (/WX option to cl.exe). Setting that property in pyproject.props sets it for all projects, and the setting does not affect Makefile projects so warnings from OpenSSL, Tcl, Tk, or Tix will not kill the build. It will need to be explicitly disabled on 64-bit Windows; setting it in x64.props does the trick. One small issue is that /WX does pick up the no profile information warning in the PGUpdate build. I'm unsure whether we should turn off /WX in pgupdate.props, or just force PGUpdate builders to have run something for each PGI'd project. -- components: Build, Windows messages: 217722 nosy: loewis, tim.golden, zach.ware priority: low severity: normal status: open title: Enable Treat Warning as Error on 32-bit Windows type: enhancement versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21411 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] core dump in PyThreadState_Get when built --with-pymalloc
New submission from John Beck: I am porting Python 3.4.0 to Solaris 12. The Makefile I inherited from my predecessor had --without-pymalloc as an option to be passed to configure. Curious why, I removed this line, only to find that after python was built, it core dumped: LD_LIBRARY_PATH=/builds/jbeck/ul-python-3/components/python/python34/build/sparcv9 ./python -E -S -m sysconfig --generate-posix-vars Fatal Python error: PyThreadState_Get: no current thread make[3]: *** [pybuilddir.txt] Abort (core dumped) But if I add the --without-pymalloc line back to my Makefile, everything works fine. Note that although this example was on sparc, the exact same thing occurred on x86. I searched for a similar bug but did not find out; please feel free to close this as a duplicate if there is one that I missed. I also suspect I have not provided enough information, out of a desire not to trigger information overload. But I would be happy to provide whatever specifics might be requested. -- components: Interpreter Core messages: 217723 nosy: jbeck priority: normal severity: normal status: open title: core dump in PyThreadState_Get when built --with-pymalloc type: crash versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] core dump in PyThreadState_Get when built --with-pymalloc
Stefan Krah added the comment: On SPARC/suncc the flags in http://bugs.python.org/issue15963#msg170661 appear to work. Also, we have several Solaris build slaves that don't core dump. Some are offline, but you can click through to the ./configure steps of past builds to see the build flags. http://buildbot.python.org/all/waterfall?category=3.x.stablecategory=3.x.unstable -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21037] add an AddressSanitizer build option
Stefan Krah added the comment: Hmm... perhaps Stefan would like to set something up? Being a correctness tool hipster, of course I already have the latest toy. :) The patch works on Debian 64-bit + clang. I can set up a VM. We may have to react quickly to some of the issues. Then again, anyone can run the tool, so there's no real secrecy anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21037 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21399] inspect and class methods
Yury Selivanov added the comment: Yeah, I'm closing this issue. -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21399 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21408] delegation of `!=` to the right-hand side argument is not always done
Josh Rosenberg added the comment: Why would an subclass of object that doesn't redefine either __eq__ or __ne__ have a different behavior for inequality than object itself? Bar never defined __eq__, so it shouldn't have an implicit __ne__ any more than object itself does... Saying that Bar has an implicit __ne__ that object doesn't is answering how this happens, but it's not a why; is there a reason why this should be the case, or is this a bug (either in spec or in code) that should be fixed? -- nosy: +josh.rosenberg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21037] add an AddressSanitizer build option
Charles-François Natali added the comment: Being a correctness tool hipster, of course I already have the latest toy. :) The patch works on Debian 64-bit + clang. Thanks for testing it. I'll leave a few days more in case anyone has a comment, and I'll commit. I can set up a VM. That would be great. We may have to react quickly to some of the issues. Then again, anyone can run the tool, so there's no real secrecy anyway. Exactly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21037 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21408] delegation of `!=` to the right-hand side argument is not always done
Benjamin Peterson added the comment: The reason ``object() != Foo()`` works is that Foo is a subtype of object(), so the specialized __ne__ of Foo is called immediately without trying object.__ne__. I don't know whether it's a bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21408] delegation of `!=` to the right-hand side argument is not always done
R. David Murray added the comment: I don't think it's a bug. The subclass-goes-first behavior is very intentional. The implicit __ne__ returning the boolean inverse of __eq__ is what fooled me when I looked at it. Or did you mean that following the subclass rule in the case where object is the other class is possibly suspect? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21408] delegation of `!=` to the right-hand side argument is not always done
Benjamin Peterson added the comment: The subclass behavior is a red herring. I meant maybe object.__ne__ should check if the other object has a __ne__ method before falling back on ``not object.__eq__()``. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] core dump in PyThreadState_Get when built --with-pymalloc
Changes by Shawn binarycrusa...@gmail.com: -- nosy: +swalker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21408] delegation of `!=` to the right-hand side argument is not always done
R. David Murray added the comment: Oh, I see. Yes, that would seem more consistent. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] core dump in PyThreadState_Get when built --with-pymalloc
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] core dump in PyThreadState_Get when built --with-pymalloc
Jesús Cea Avión added the comment: What compiler are you using?. I compile fine on Solaris with GCC. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21413] urllib.request.urlopen dies on non-basic/digest auth schemes
New submission from Samwyse: In Python 2.x, this opens an NTLM protected URL: opener = urllib2.build_opener(proxy_handler, auth_NTLM, auth_digest, auth_basic) urllib2.install_opener(opener) response = urllib2.urlopen(url) In Python 3.x, this raises an error: opener = urllib.request.build_opener(proxy_handler, auth_NTLM, auth_digest, auth_basic) urllib.request.install_opener(opener) response = urllib.request.urlopen(url) The error is: ValueError: AbstractDigestAuthHandler does not support the following scheme: 'NTLM' Removing auth_digest from the list of handlers allows the code to work. -- components: Library (Lib) messages: 217734 nosy: samwyse priority: normal severity: normal status: open title: urllib.request.urlopen dies on non-basic/digest auth schemes versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21413 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] core dump in PyThreadState_Get when built --with-pymalloc
John Beck added the comment: Using Oracle Studio 12.3, same as mentioned in http://bugs.python.org/issue15963#msg170661 (as Stefan pointed out). I am using some of those flags but not all of them. I will try the others when I have a chance, then report back. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21408] delegation of `!=` to the right-hand side argument is not always done
Changes by Florent Xicluna florent.xicl...@gmail.com: -- nosy: +flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21399] inspect and class methods
Larry Hastings added the comment: By default AC emits $type for class methods, see dict_fromkeys in Objects/dictobject.c. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21399 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21267] mktime_tz may return wrong result for past dates before Python 2.7.4
R. David Murray added the comment: Since you say the bug is fixed, what do you intend the purpose of this issue to be? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21267 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21267] mktime_tz may return wrong result for past dates before Python 2.7.4
R. David Murray added the comment: Oh, I missed the fact that you had closed it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21267 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21332] subprocess bufsize=1 docs are misleading
Martin Panter added the comment: Perhaps you can avoid the 10 s deadlock timeout and threading in your test by closing the underlying input pipe file descriptor (or raw file object), without flushing it. Also, it seems to me that “line_buffering=True” is redundant with “write_through=True”. I’m not super familiar with the new write-through mode though, so I could be wrong. Perhaps the change in “subprocess.py” may not be needed at least once Issue 21396 is fixed. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21332] subprocess bufsize=1 docs are misleading
Martin Panter added the comment: Sorry, it seems I was wrong on the second point. Looking closer, it seems write-through mode only flushes the TextIOWrapper layer, not the underlying binary file object, whereas line-buffering mode flushes everything to the OS, so the extra line_buffering=True flag would be needed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21396] Python io implementation doesn't flush with write_through=True unlike C implementation
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21396 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9625] argparse: Problem with defaults for variable nargs when using choices
Changes by paul j3 ajipa...@gmail.com: Added file: http://bugs.python.org/file35128/notes.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9625 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21363] io.TextIOWrapper always closes wrapped files
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21363 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21368] Check for systemd locale on startup if current locale is set to POSIX
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21368 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21364] Documentation Recommends Broken Pattern
Martin Panter added the comment: That particular revision isn’t sound so bad; I think the next revision, 78fb7f8cd349, which adds the make_streams_binary() function that replaces the variables is a worry though. This is the kind of code I use when I want to write binary data to stdout: output = sys.stdout.detach() sys.stdout = None # Avoid error message during shutdown, due to output being closed or garbage-collected output.write(...) This raises two issues: 1. Is the practice of setting sys.stdout to None documented or recommended anywhere? If not, could it be, or is there another way to do this? 2. The error message I am avoiding looks more broken than it could be: $ python3 -c 'from sys import stdout; stdout.detach().close()' Exception ignored in: $ The trailing dollar ($) sign just indicates that there was no newline printed. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21364 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 bufsize=0). Note: the current patch for issue #21396 (making C and Python io do the same thing) may break subprocess code with universal_newlines=True that expects (incorrectly) bufsize=0 by default -- as test_universal_newlines had (enabling universal_newlines shouldn't switch from bufsize=-1 to bufsize=0). -- XXX backward compatibility issue! Perhaps you can avoid the 10 s deadlock timeout and threading in your test by closing the underlying input pipe file descriptor (or raw file object), without flushing it. It is a good idea. There could be portability issues with the test: it relies on the fact that os.close doesn't flush already buffered data -- I don't know whether os.close causes flush on Windows (it doesn't on POSIX [1]: the data shall be discarded). [1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html I've uploaded a new patch with the updated tests. Please, review. -- Added file: http://bugs.python.org/file35129/subprocess-line-buffering-issue21332-ps3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6839] zipfile can't extract file
Adam Polkosnik added the comment: Jim, The problems documented here are related to two cases (both apparently arriving from world of windows): 1. two relative paths with inverted slash in one of them (test\test2.txt vs test/test2.txt) 2. relative path vs absolute path (windows\temp\test.txt vs c:\windows\temp\test.txt) The extraction part seems to be doing a good job at writing the files into sane locations. IMHO, there's no point in trying to replace slashes or otherwise normalize, as this would fix the cases where the presence of an inverted slashes should be noted in debug output. By the same token stripping the drive letter from the absolute path part would just deprive us from noticing such intricacies in these special zip files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
