[issue21082] _get_masked_mode in os.makedirs() is a serious security problem
New submission from Ryan Lortie: http://bugs.python.org/file19849/mkdirs.tr.diff introduced a patch with this code in it: +def _get_masked_mode(mode): +mask = umask(0) +umask(mask) +return mode ~mask This changes the umask of the entire process. If another thread manages to create a file between those two calls then it will be world read/writable, regardless of the original umask of the process. This is not theoretical: I discovered this bug by observing it happen. -- components: Library (Lib) messages: 215020 nosy: desrt priority: normal severity: normal status: open title: _get_masked_mode in os.makedirs() is a serious security problem type: security versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21074] Too aggressive constant folding
Steve Holden added the comment: Is a fix really required? Are we really supposed to protect programmers from their own folly by second-guessing when constant folding might be required and when it might not? How is hte interpreter supposed to know the function isn't called? The simple solution to this problem is available in Python: simply declare a manifest constant and use that instead: UNCALLED_SIZE = 2**32 def uncalled(): x = b'x' * UNCALLED_SIZE I'd recommend closing this issue (though I'm glad that people are concerned with optimization, I don't think that an optimizer should be too concerned with those rare cases when their optimization doesn't optimize. But I'm not going to close it: wiser heads than mine are required. -- nosy: +holdenweb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] _get_masked_mode in os.makedirs() is a serious security problem
Ned Deily added the comment: The issue associated with the patch in question is Issue9299. Adding possibly affected releases and release managers for evaluation. -- keywords: +security_issue nosy: +georg.brandl, larry, ned.deily priority: normal - high versions: +Python 3.2, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21074] Too aggressive constant folding
STINNER Victor added the comment: Is a fix really required? Yes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] _get_masked_mode in os.makedirs() is a serious security problem
Georg Brandl added the comment: yes, this seems bad enough for inclusion in security releases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] _get_masked_mode in os.makedirs() is a serious security problem
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] _get_masked_mode in os.makedirs() is a serious security problem
STINNER Victor added the comment: http://bugs.python.org/file19849/mkdirs.tr.diff This patch comes from issue #9299: changeset 89cda0833ba6 made in Python 3.2 beta 1. The change was not backported to Python 2.7. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs() is not thread-safe: umask is set temporary to 0, serious security problem
Changes by STINNER Victor victor.stin...@gmail.com: -- title: _get_masked_mode in os.makedirs() is a serious security problem - os.makedirs() is not thread-safe: umask is set temporary to 0, serious security problem ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
Changes by STINNER Victor victor.stin...@gmail.com: -- title: os.makedirs() is not thread-safe: umask is set temporary to 0, serious security problem - os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
STINNER Victor added the comment: The shell command umask calls umask(022) to get the current umask, and then call umask() with result of the first call. 022 is the default umask, it's probably safer to call umask(0o22) in _get_masked_mode() instead of umask(0). Attached patch makes this change. If you change something, it should be backported to 3.2, 3.3 and 3.4, because I agree that it affects the security. -- keywords: +patch Added file: http://bugs.python.org/file34649/get_masked_mode.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
Antoine Pitrou added the comment: I think the behaviour that an error is raised if the permissions are not the same is a nuisance that does not correspond to actual use cases (*). People who care about permissions so much that they expect an error can do the check themselves, or call chmod(). (*) and I got similar errors several times when running setup.py, only I didn't know it was because of that feature -- nosy: +pitrou, terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
Antoine Pitrou added the comment: (note that Victor's patch is of course not an actual fix, only a mitigation; if someone is relying on a stricter umask they will still be vulnerable to this) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19977] Use surrogateescape error handler for sys.stdin and sys.stdout on UNIX for the C locale
Nick Coghlan added the comment: This seems to be working on the buildbots for 3.5 now (buildbot failures appear to be due to other issues). However, I'd still like to discuss the idea of backporting this to 3.4.1. From a Fedora point of view, it's still *very* easy to flip an environment into POSIX mode, so even if the system is appropriately configured to use UTF-8 everywhere, Python 3.4 may still blow up if a script or application ends up running under the POSIX locale. That has long made Toshio nervous about the migration of core services to Python 3 (https://fedoraproject.org/wiki/Changes/Python_3_as_Default), and his concerns make sense to me, as that migration covers little things like the installer, package manager, post-image install initialisation, etc. I'm not sure the Fedora team can deliver on the Users shouldn't notice any changes, except that packages in minimal buildroot and on LiveCD will be python3-, not python-. aspect of the change proposal without this behavioural tweak in the 3.4 series as well. Note that this *isn't* a blocker for the migration - if it was, it would be mentioned in the Fedora proposal. However, I think there's a risk to the Fedora user experience if the status quo remains in place for the life of Python 3.4, and I'd hate for the first encounter Fedora users have with Python 3 to be inexplicable tracebacks from components that have been migrated. -- versions: +Python 3.4 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21074] Too aggressive constant folding
INADA Naoki added the comment: For example. I want to write test like this: @unittest.skip(This test requires huge memory) def test_largebuf(): client = self.create_client() data = b'x' * (2**32 - 1) client.send(data) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17829] csv.Sniffer.snif doesn't set up the dialect properly for a csv created with dialect=csv.excel_tab and containing quote () char
Antoon Pardon added the comment: I included a patch (against 2.7) that seems to make the test work. The patch prohibits the delim group to match a space. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17829 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21081] missing vietnamese codec TCVN 5712:1993 in Python
Marc-Andre Lemburg added the comment: Some comments: * Please provide some background information how widely the encoding is used. I get less than 1000 hits in Google when looking for TCVN 5712:1993. Now, the encoding was a standard in Vietnam, but it has been updated in 1999 to TCVN 5712:1999. There's also an encoding called VSCII. * In the file you write kind of TCVN 5712:1993 VN3 with CP1252 additions. This won't work, since we can only accept codecs which are based on set standards. It would be better to provide a link to an official Unicode character set mapping table and then use the gencodec.py script on this table. * For Vietnamese, Python already provides cp1258 - how much is this encoding used in comparison to e.g. TCVN 5712:1993 ? Resources: * Vietnamese encodings: http://www.panl10n.net/english/outputs/Survey/Vietnamese.pdf * East Asian encodings: http://www.unicode.org/iuc/iuc15/tb1/slides.pdf -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21081 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21081] missing vietnamese codec TCVN 5712:1993 in Python
Marc-Andre Lemburg added the comment: Retargeting to 3.5, since all other releases don't allow addition of new features. -- versions: +Python 3.5 -Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21081 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
STINNER Victor added the comment: I think the behaviour that an error is raised if the permissions are not the same is a nuisance that does not correspond to actual use cases (*). I was also surprised that makedirs() checks for the exact permission. We can probably document that makedirs(exists_ok=True) leaves the directory permission unchanged if the directory already exist, and that an explicit chmod() may be needed to ensure that permissions are the expected permissions. If the check on permissions is removed, an enhancement would be to return a flag to indicate if at least one directory of the path already existed. So the caller can avoid calling chmod() if all directories of the path had to be created. Something like: if makedirs(a/b, mod=0o755, exists_ok=True): os.chmod(a, 0o755) os.chmod(a/b, 0o755) # else a and b were created with the permission 0o755 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21074] Too aggressive constant folding
STINNER Victor added the comment: For example. I want to write test like this: @unittest.skip(This test requires huge memory) There is @test.support.bigmemtest(size=_2G, memuse=1) decorator which is more convinient than the skip decorators. See Lib/test/test_bigmem.py. You can use tracemalloc to get the memory peak: tracemalloc.get_traced_memory()[1] is the peak. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21083] Add get_content_disposition() to email.message.Message
New submission from Brandon Rhodes: Content-Disposition is an optional header field. In its absence, the MUA may use whatever presentation method it deems suitable. — RFC 2183 The email.message.Message class should gain a get_content_disposition() method with the three possible return values 'inline', 'attachment', and None so that email clients can easily distinguish between the three states described in the RFC. See also the discussion at http://bugs.python.org/issue21079 -- components: email messages: 215036 nosy: barry, brandon-rhodes, r.david.murray priority: normal severity: normal status: open title: Add get_content_disposition() to email.message.Message type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21083 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21079] EmailMessage.is_attachment == False if filename is present
Brandon Rhodes added the comment: Thanks — done! http://bugs.python.org/issue21083 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21079 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21084] IDLE can't deal with characters above the range (U+0000-U+FFFF)
New submission from wjssz: When open a file with characters above the range (U+-U+), IDLE quit without any report. For example, open this file \Lib\test\test_re.py The below is Traceback info, the last line tells the reason. I just hope IDLE say something before quit, so we can know what happend. I have checked Python 3.3.5 and 3.4.0, they have the same problem. I didn't find a 3.5 build, so I can't test this problem under 3.5. = Exception in Tkinter callback Traceback (most recent call last): File C:\Python33\lib\tkinter\__init__.py, line 1489, in __call__ return self.func(*args) File C:\Python33\lib\idlelib\IOBinding.py, line 186, in open flist.open(filename) File C:\Python33\lib\idlelib\FileList.py, line 36, in open edit = self.EditorWindow(self, filename, key) File C:\Python33\lib\idlelib\PyShell.py, line 126, in __init__ EditorWindow.__init__(self, *args) File C:\Python33\lib\idlelib\EditorWindow.py, line 288, in __init__ if io.loadfile(filename): File C:\Python33\lib\idlelib\IOBinding.py, line 236, in loadfile self.text.insert(1.0, chars) File C:\Python33\lib\idlelib\Percolator.py, line 25, in insert self.top.insert(index, chars, tags) File C:\Python33\lib\idlelib\UndoDelegator.py, line 81, in insert self.addcmd(InsertCommand(index, chars, tags)) File C:\Python33\lib\idlelib\UndoDelegator.py, line 116, in addcmd cmd.do(self.delegate) File C:\Python33\lib\idlelib\UndoDelegator.py, line 219, in do text.insert(self.index1, self.chars, self.tags) File C:\Python33\lib\idlelib\ColorDelegator.py, line 85, in insert self.delegate.insert(index, chars, tags) File C:\Python33\lib\idlelib\WidgetRedirector.py, line 104, in __call__ return self.tk_call(self.orig_and_operation + args) _tkinter.TclError: character U+1d518 is above the range (U+-U+) allowed by Tcl -- components: IDLE messages: 215038 nosy: wjssz priority: normal severity: normal status: open title: IDLE can't deal with characters above the range (U+-U+) type: crash versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21084 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21084] IDLE can't deal with characters above the range (U+0000-U+FFFF)
wjssz added the comment: When open a file with characters above the range (U+-U+), IDLE quit without any report. For example, open this file C:\Python33\lib\test\test_re.py The below is Traceback info, the last line tells the reason. I just hope IDLE say something before quit, so we can know what happend. I have checked Python 3.3.5 and 3.4.0, they have the same problem. I didn't find a 3.5 build, so I can't test this problem under 3.5. = Exception in Tkinter callback Traceback (most recent call last): File C:\Python33\lib\tkinter\__init__.py, line 1489, in __call__ return self.func(*args) File C:\Python33\lib\idlelib\IOBinding.py, line 186, in open flist.open(filename) File C:\Python33\lib\idlelib\FileList.py, line 36, in open edit = self.EditorWindow(self, filename, key) File C:\Python33\lib\idlelib\PyShell.py, line 126, in __init__ EditorWindow.__init__(self, *args) File C:\Python33\lib\idlelib\EditorWindow.py, line 288, in __init__ if io.loadfile(filename): File C:\Python33\lib\idlelib\IOBinding.py, line 236, in loadfile self.text.insert(1.0, chars) File C:\Python33\lib\idlelib\Percolator.py, line 25, in insert self.top.insert(index, chars, tags) File C:\Python33\lib\idlelib\UndoDelegator.py, line 81, in insert self.addcmd(InsertCommand(index, chars, tags)) File C:\Python33\lib\idlelib\UndoDelegator.py, line 116, in addcmd cmd.do(self.delegate) File C:\Python33\lib\idlelib\UndoDelegator.py, line 219, in do text.insert(self.index1, self.chars, self.tags) File C:\Python33\lib\idlelib\ColorDelegator.py, line 85, in insert self.delegate.insert(index, chars, tags) File C:\Python33\lib\idlelib\WidgetRedirector.py, line 104, in __call__ return self.tk_call(self.orig_and_operation + args) _tkinter.TclError: character U+1d518 is above the range (U+-U+) allowed by Tcl -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21084 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21084] IDLE can't deal with characters above the range (U+0000-U+FFFF)
Ezio Melotti added the comment: See #13153. -- nosy: +ezio.melotti, serhiy.storchaka resolution: - duplicate status: open - pending type: crash - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21084 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21081] missing vietnamese codec TCVN 5712:1993 in Python
Jean Christophe André added the comment: * Please provide some background information how widely the encoding is used. I get less than 1000 hits in Google when looking for TCVN 5712:1993. Here is the background for the need for this encoding. The recent laws[0] in Vietnam have set TCVN 6909:2001 (Unicode based) as the standard encoding everybody should use. Still, there was more than 30 old Vietnamese encodings that were used for tenths of years before that, with some of them being still used (it takes times for people to accept the change and for technicians to do what's required to change technology). Among them, TCVN 5712:1993 was (is) mostly used in the North of Vietnam and VNI (a private company encoding) in the South of Vietnam. Worse than that, these old encodings use the C0 bank to store some Vietnamese letters (especially the 'ư', one of the most used in this language), which has the very unpleasant consequence to let some software (like OpenOffice/LibreOffice) being unable to render the texts correctly, even when using the correct fonts. Since this was a showstopper for Free Software adoption in Vietnam, I decided at that time to create a tool[1][2] to help in converting from these old encodings to Unicode. The project was then endorsed by the Ministry of Sciences and Technology of Vietnam, which asked me to make further developments[3]. Even if these old encodings are, hopefully, not the widest used in Vietnam now, there are still tons/plenty of old documents (sorry, I can't be more precise on the volume of administrative or private documents) that need to be read/modified or, best, converted to Unicode; and here is where the encodings are needed. Now every time some Vietnamese people (and Laotian people, I'll come back on this in another bug report) want to use OpenOffice/LibreOffice and still be able to open their old documents, they have to install this Python extension for this. I foresee there will be not only plain documents to convert but also databases and other kind of data storage. And here is where Python has a great occasion to become the tool of choice. [0] http://thuvienphapluat.vn/archive/Quyet-dinh-72-2002-QD-TTg-thong-nhat-dung-bo-ma-ky-tu-chu-Viet-TCVN-6909-2001-trao-doi-thong-tin-dien-tu-giua-to-chuc-dang-nha-nuoc-vb49528.aspx [1] http://wiki.hanoilug.org/projects:ovniconv [2] http://extensions.services.openoffice.org/project/ovniconv [3] http://extensions.services.openoffice.org/en/project/b2uconverter Now, the encoding was a standard in Vietnam, but it has been updated in 1999 to TCVN 5712:1999. I have to admit I missed this one. It may explain the differences I saw when I reversed engineered the TCVN encoding through the study the documents Vietnamese users provided to me. I will check this one and come back with more details. There's also an encoding called VSCII. VSCII is the same as TCVN 5712:1993. This page contains interesting information about these encodings: http://www.informatik.uni-leipzig.de/~duc/software/misc/tcvn.txt * In the file you write kind of TCVN 5712:1993 VN3 with CP1252 additions. This won't work, since we can only accept codecs which are based on set standards. I can understand that and I'll do my best to check if it's really based on one of the TCVN standards, be it 5712:1993 or 5712:1999. Still, after years of usage, I know perfectly that it's exactly the encoding we need (for the North part of Vietnam at least). It would be better to provide a link to an official Unicode character set mapping table and then use the gencodec.py script on this table. I saw a reference to this processing tool in the Python provided encodings and tried to find a Unicode mapping table at the Unicode website but failed up to now. I'll try harder. * For Vietnamese, Python already provides cp1258 - how much is this encoding used in comparison to e.g. TCVN 5712:1993 ? To be efficient at typing Vietnamese, you need a keyboard input software (Vietkey and Unikey being the most used). Microsoft tried to create dedicated Vietnamese encoding (cp1258) and keyboard, but I never saw or heard about its adoption at any place. Knowing the way Vietnamese users use their computer, I would say it probably has never been in real use. * Vietnamese encodings: http://www.panl10n.net/english/outputs/Survey/Vietnamese.pdf In this sentence you can see the most used old encodings in Vietnam: “On the Linux platform, fonts based on Unicode [6], TCVN, VNI and VPS [7] encodings can be adequately used to input Vietnamese text.” This is not only the most used on Linux (in fact, on Linux we have to use Unicode, mostly because of the problem I explained before) but also on Windows. I don't know the situation for Mac OS or other OS though. My goal is to add these encodings into Python, to help Vietnam make its steps into Unicode. * East Asian encodings: http://www.unicode.org/iuc/iuc15/tb1/slides.pdf This
[issue21076] Turn signal.SIG* constants into enums
Giampaolo Rodola' added the comment:
(replying here 'cause rietveld keeps giving me an exception when I submit a
reply)
On 2014/03/28 00:49:47, haypo wrote:
http://bugs.python.org/review/21076/diff/11457/Lib/signal.py
File Lib/signal.py (right):
http://bugs.python.org/review/21076/diff/11457/Lib/signal.py#newcode7
Lib/signal.py:7: if name.isupper()
You can probably remove this test.
http://bugs.python.org/review/21076/diff/11457/Lib/signal.py#newcode8
Lib/signal.py:8: and (name.startswith('SIG') and not name.startswith('SIG_'))
Why do you ignore SIG_DFL, SIG_IGN, SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK? It
may
also be interesting to provide enums for them. They are just integers (0, 1 or
2) on my Linux.
I guess it makes sense.
I'm now realizing that the patch as-is is incomplete as the other get APIs
(signal.getsignal() and others) still return integers: they should be
overridden in order to convert integers into enums, similarly to
http://hg.python.org/cpython/file/d8659dbebfd1/Lib/socket.py#l262
I will do that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21076
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21081] missing vietnamese codec TCVN 5712:1993 in Python
Marc-Andre Lemburg added the comment: Thanks for your answers. I think the best way forward would be to some up with an official encoding map of the TCVN 5712:1999 encoding, translate that into a format that gencodec.py can use and then add the generated codec to Python 3.5. We can then add the reference to the original encoding map to the generated file. This is how we've added a couple of other encodings for which there were no official Unicode mapping files as well. Please also provide a patch for the documentation and sign the Python contrib form: https://www.python.org/psf/contrib/contrib-form/ Thanks, -- Marc-Andre Lemburg eGenix.com -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21081 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Brett Cannon added the comment: New version based on Eric's review. -- Added file: http://bugs.python.org/file34650/no_frozen__file__.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Brett Cannon added the comment: It actually does break backwards-compatibility as an attribute will disappear on frozen modules for anyone who uses the imp API. While the chances of actually breaking someone's code is very small, there is still a chance. But I'm only -0 on backporting so other core devs could convince me that I'm being overly cautious. -- versions: -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
Changes by Remi Pointel pyt...@xiri.fr: -- nosy: +rpointel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20895 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Boštjan Mejak added the comment: I would say go for it. I don't think anyone's code would break. Anyway, if people see that something in the new version of Python breaks their code, they down-grade; otherwise they read the changelog and fix their code accordingly. So no worries here. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21085] compile error Python3.3 on Cygwin
New submission from dellair jie: Folks, Is Cygwin supported by Python? We met the following error when compiling Python 3.3.2 on Cygwin 1.7.17: gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include-DPy_BUILD_CORE -o Modules/main.o Modules/main.c Modules/main.c:17:0: warning: PATH_MAX redefined /usr/include/limits.h:336:0: note: this is the location of the previous definition Modules/main.c: In function ‘Py_Main’: Modules/main.c:561:5: warning: implicit declaration of function ‘_setmode’ gcc -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include-DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include-DPy_BUILD_CORE -c ./Modules/_threadmodule.c -o Modules/_threadmodule.o gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include-DPy_BUILD_CORE -c ./Modules/signalmodule.c -o Modules/signalmodule.o ./Modules/signalmodule.c: In function ‘fill_siginfo’: ./Modules/signalmodule.c:745:5: error: ‘siginfo_t’ has no member named ‘si_band’ Makefile:1501: recipe for target `Modules/signalmodule.o' failed make: *** [Modules/signalmodule.o] Error 1 Any lights would be appreciated. Thanks, -- components: Build messages: 215050 nosy: dellair.jie priority: normal severity: normal status: open title: compile error Python3.3 on Cygwin versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
Changes by Benjamin Peterson benja...@python.org: -- priority: high - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21076] Turn signal.SIG* constants into enums
Giampaolo Rodola' added the comment: New patch in attachment provides 3 enum containers and overrides all the necessary signal module APIs so that they interoperate with enums on both get and set. I decided *not* to rename signamodule.c to _signamodule.c in this patch so that it is easier to review (I will do the renaming as a second step). -- Added file: http://bugs.python.org/file34653/signals3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
Andreas Schwab added the comment: 342 tests OK. 2 tests altered the execution environment: test_site test_warnings 33 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu test_dbm_ndbm test_devpoll test_idle test_ioctl test_kqueue test_msilib test_ossaudiodev test_pep277 test_readline test_smtpnet test_socketserver test_sqlite test_ssl test_startfile test_tcl test_timeout test_tk test_ttk_guionly test_ttk_textonly test_unicode_file test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21086] Source with # -*- coding: ASCII -*- and UNIX EOL (\n) results in SyntaxError
Changes by Morten Z morten...@gmail.com: Added file: http://bugs.python.org/file34652/hello_win.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21086 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20163] ValueError: time data does not match format
dellair jie added the comment: We've found a workaround to handle the timestr manually. Thanks, -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21085] compile error Python3.3 on Cygwin
dellair jie added the comment: Victor, I did do ./configure, without any parameters. Should I use it with --without-signal-module option? Will all signals be disabled if this option is specified? From Python document, it mentions Windows support the following signals: signal.SIGINT, signal.SIGTERM, signal.SIGABRT, signal.SIGFPE, signal.SIGILL, signal.SIGSEGV The following are found in pyconfig.h.in 804 /* Define to 1 if you have the `sigtimedwait' function. */ 805 #undef HAVE_SIGTIMEDWAIT 810 /* Define to 1 if you have the `sigwaitinfo' function. */ 811 #undef HAVE_SIGWAITINFO Br, Li -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21085] compile error Python3.3 on Cygwin
STINNER Victor added the comment: ./Modules/signalmodule.c:745:5: error: ‘siginfo_t’ has no member named ‘si_band’ This code is conditional, it is surrounded by: #if defined(HAVE_SIGWAITINFO) || defined(HAVE_SIGTIMEDWAIT) Does Windows support sigwaitinfo() or sigtimedwait()? I would be surprised. You used configure? Check pyconfig.h for these two constants. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21085] compile error Python3.3 on Cygwin
R. David Murray added the comment: cygwin is not officially supported. We do accept patches that improve cygwin support when they are narrowly targted and well motivated. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19915] int.bit_at(n) - Accessing a single bit in O(1)
anon added the comment: From what I can tell it's fairly easy to just add bits_at to int. Indeed something like a mutable int type might be nice but that's really outside the scope of this. And adding bits_at to int would still be desirable anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21081] missing vietnamese codec TCVN 5712:1993 in Python
Jean Christophe André added the comment: I will prepare the official encoding map(s) based on the standard(s). I'll also have to check which encoding correspond to my current encoding map, since this is the one useful in real life. Please also provide a patch for the documentation I currently have no idea how to do this. Could you point me to a documentation sample or template please? and sign the Python contrib form: https://www.python.org/psf/contrib/contrib-form/ I did it yesterday. The form tells it can take days to be integrated, but I did receive the signed document as a confirmation. Thanks for your concern, J.C. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21081 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Eric Snow added the comment: Latest patch LGTM. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Eric Snow added the comment: As I've thought about it, I've gone from -0 to +1 on applying this to both 3.4 and 3.5. The bug and fix should impact very little* code. In fact, I doubt anyone would have noticed if Nick hadn't. :) It would be nice to have this right in 3.4. * Effectively this is limited to consumers of imp.init_frozen(), PyImport_ImportFrozenModule(), and PyImport_ImportFrozenModule(). That includes importing frozen importlib and Py_FrozenMain(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Boštjan Mejak added the comment: This patch can easily be incorporated into Python 3.4.1. It doesn't break backwards compatibility. -- nosy: +Zvezdoslovec versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18823] Idle: use pipes instead of sockets to talk with user subprocess
Terry J. Reedy added the comment: In the thread that started here https://mail.python.org/pipermail/python-dev/2014-March/133492.html in this message. https://mail.python.org/pipermail/python-dev/2014-March/133671.html Josiah Carlson posted a pastebin link about how to actually use the pipes. Guido recommended that the he post a revised version to a new issue, as a patch to subprocess, but I am uploading it here to make sure it does not get lost. -- Added file: http://bugs.python.org/file34654/Carlson.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21087] imp.frozen_init() incorrectly removes module during reload
New submission from Eric Snow: While reviewing code[1] for issue 20942, I noticed that when someone uses imp.frozen_init[2], the module is removed from sys.modules in some error cases. However, this should not be done when the module already exists (e.g. reload). As Brett pointed out in his reply to my comment in the review, frozen modules really shouldn't be reloaded, so this isn't something we necessarily need to worry about. I.E. it's a rare corner case. I brought it up because there's a comment in PyImport_ExecCodeModuleObject() implying a reload-related use-case. We have 3 options: 1. don't worry about it (imp.frozen_init() is deprecated, etc.), 2. stop calling remove_module() in the reload case (i.e. be accommodating), 3. disallow reloading frozen modules (and remove that comment from import.c). I'll shy away from #3 (consenting adults, etc.). If someone felt like it they could work on #2, but keep in mind that there may be other reload-unfriendly code in this code path that would need adjusting if we wanted to really accommodate the use case. I'm not convinced it's worth the trouble. If anyone else agrees, feel free to close this issue. [1] http://bugs.python.org/review/20942/#msg4 [2] really, anything that directly or indirectly uses PyImport_ExecCodeModuleObject() (or module_dict_for_exec() from #20942) is impacted. In addition to imp.frozen_init(), that includes PyImport_ImportFrozenModule and PyImport_ImportFrozenModuleObject -- components: Library (Lib) messages: 215063 nosy: brett.cannon, eric.snow, ncoghlan priority: low severity: normal stage: test needed status: open title: imp.frozen_init() incorrectly removes module during reload type: behavior versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21087 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21087] imp.frozen_init() incorrectly removes module during reload
Eric Snow added the comment: The only concrete example I can think of that would be impacted is using PJE's lazy loader on a frozen module, and even that is unlikely to trigger the error case. -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21087 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Boštjan Mejak added the comment: I'm setting Python 3.4 to also be affected by this issue. Thank you, Brett, for making the patch. I hope this gets commited soon. -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20924] openssl init 100% CPU utilization
Roman O. Vlasov added the comment:
To reproduce the 100% CPU load problem, we used a simple python TLS client on
separate linux PC with Traffic control utility (tc):
tc qdisc change dev eth0 root netem delay 5000ms
After in-depth analyzing, we realized that _ssl.c behaves differently depening
on socket.timeout:
1) sock.timeout set to None, that is equivalent to s-socket_timeout==-1 in
_ssl.c produces 100% CPU load if client works on bad long delay channel.
The problem is this case is that the do{} loop runs in PySSL_SSLdo_handshake()
calling check_socket_and_wait_for_timeout() which immediatly returns
SOCKET_IS_BLOCKING because s-sock_timeout==-1.
2) sock.timeout set to 0 (non-blocking) makes _ssl.c immediatly return with
error:
_ssl.c: The operation did not complete
3) socket.timeout set to any positive value makes _ssl.c wait socket on select
(producing no CPU load).
By default, accept() returns blocking socket with timeout set to None (1st case)
Below are some code details:
Our server class is inherited from asyncore.dispatcher.
In __init__ it executes the following statements (ripped),
creating listening socket, accepting client connection and then doing
wrap_socket:
---
asyncore.py:
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setblocking(0)
sock.setsockopt(
socket.SOL_SOCKET,
socket.SO_REUSEADDR,
socket.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR) | 1
)
sock.bind(self.server_address)
sock.listen(5)
asyncore.loop(...)
select.select(...) # wait for client connection
# Here client connects
conn, addr = sock.accept()
# conn.gettimeout() returns None which means blocking socket
ssl_sock = ssl.wrap_socket(
conn
, server_side = server_side
, certfile = certfile
, cert_reqs = cert_reqs
, ssl_version=ssl.PROTOCOL_SSLv3
)
File C:\Python27\Lib\ssl.py, line 399, in wrap_socket
File C:\Python27\Lib\ssl.py, line 152, in __init__
self.do_handshake()
File C:\Python27\Lib\ssl.py, line 315, in do_handshake
self._sslobj.do_handshake()
_ssl.c:
PySSL_SSLdo_handshake():
// wants to read more data from socket
if (err == SSL_ERROR_WANT_READ) {
sockstate =
check_socket_and_wait_for_timeout(self-Socket, 0);
...
check_socket_and_wait_for_timeout():
/* Nothing to do unless we're in timeout mode (not
non-blocking) */
if (s-sock_timeout 0.0)
return SOCKET_IS_BLOCKING; // -- this is
1st case producing 100% CPU load
else if (s-sock_timeout == 0.0)
return SOCKET_IS_NONBLOCKING; // -- this is 2nd case
returning error immediatly
We think that anyone who follows standard Python documentation
(http://docs.python.org/2/library/ssl.html#server-side-operation) will get the
same result if using client with delay1000ms
--
nosy: +rv
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20924
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20924] openssl init 100% CPU utilization
Antoine Pitrou added the comment: How come OpenSSL returns SSL_ERROR_WANT_READ if the socket is blocking? Perhaps Windows returns a non-blocking socket for accept()? Have you tried with Python 3? -- nosy: +giampaolo.rodola type: resource usage - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20924 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18823] Idle: use pipes instead of sockets to talk with user subprocess
Terry J. Reedy added the comment: https://mail.python.org/pipermail/python-dev/2014-March/133641.html from Victor Stinner gives example code using asyncio -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21068] Make ssl.PROTOCOL_* an enum
Antoine Pitrou added the comment: Possibly it should be done for all ssl APIs returning a constant. Are there others? There's SSLContext.verify_mode, but it simply mirrors the configuration chosen by the user. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21076] Turn signal.SIG* constants into enums
Giampaolo Rodola' added the comment: Updated patch following Victor's suggestions is in attachment. -- Added file: http://bugs.python.org/file34655/signals4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19714] Add tests for importlib.machinery.WindowsRegistryFinder
Eric Snow added the comment: Martin: are you okay with Claudiu's latest patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19714 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21088] curses addch() argument position reverses in Python3.4.0
New submission from Masayuki Yamamoto: There is a test code that is RB characters display on screen. I expected displaying R to right, and displaying B to bottom. It was run as expected in Python 2.7.3 and 3.2.3 on Cygwin. But they were displayed reverse in Python 3.4.0. And when addch() arguments reversed, they were displayed in expected positions. import curses def test(stdscr): stdscr.addch(0, 5, b'R') stdscr.addch(5, 0, b'B') stdscr.refresh() stdscr.getch() curses.wrapper(test) Please make sure of issues, and fix it. Thanks. -- components: Library (Lib) messages: 215074 nosy: masamoto priority: normal severity: normal status: open title: curses addch() argument position reverses in Python3.4.0 type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21089] macro SET_SYS_FROM_STRING_BORROW doesn't get unset
New submission from Eric Snow: In Python/sysmodule.c (_PySys_Init), the SET_SYS_FROM_STRING_BORROW macro is created right next to SET_SYS_FROM_STRING. However, while SET_SYS_FROM_STRING is unset at the end of _PySys_Init, SET_SYS_FROM_STRING_BORROW is not unset. I expect that it should be. #endif #undef SET_SYS_FROM_STRING +#undef SET_SYS_FROM_STRING_BORROW if (PyErr_Occurred()) -- messages: 215075 nosy: brett.cannon, eric.snow priority: low severity: normal stage: needs patch status: open title: macro SET_SYS_FROM_STRING_BORROW doesn't get unset versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21089 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21086] Source with # -*- coding: ASCII -*- and UNIX EOL (\n) results in SyntaxError
R. David Murray added the comment: Hmm. This might be related to issue 20731? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21086 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21086] Source with # -*- coding: ASCII -*- and UNIX EOL (\n) results in SyntaxError
Morten Z added the comment: Yes, sounds like a duplicate of http://bugs.python.org/issue20731 But with the fix applied 2014-03-01, is the bug expected to be in 3.4 released 2014-03-17 ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21086 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21088] curses addch() argument position reverses in Python3.4.0
Ned Deily added the comment: It looks like the arguments were inadvertently swapped during the conversion to Argument Clinic. The Library Reference doc says: window.addch(y, x, ch[, attr]) but the Argument Clinic docstring for 3.4.0 says: Help on built-in function addch: addch(...) method of _curses.curses window instance addch([x, y,] ch, [attr]) Paint character ch at (y, x) with attributes attr. x X-coordinate. y Y-coordinate. ch Character to add. attr Attributes for the character. Paint character ch at (y, x) with attributes attr, overwriting any character previously painted at that location. By default, the character position and attributes are the current settings for the window object. Perhaps we should check for others? -- nosy: +larry, ned.deily priority: normal - release blocker stage: - needs patch versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21088] curses addch() argument position reverses in Python3.4.0
Changes by Ned Deily n...@acm.org: -- keywords: +3.4regression ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21088] curses addch() argument position reverses in Python3.4.0
Larry Hastings added the comment: That's my fault. That conversion was done at a time when there were a lot fewer eyes looking at AC. It should obviously be fixed, and a test added to the regression test suite. It'd also be nice if running the curses test didn't make reading the result impossible. Running python -m test -u curses test_curses leaves my terminal window cleared, with no text to scroll back to, and the result of the regression test gone. Redirecting the test to a file fails because curses complains stdio isn't a tty. (I specifically ran the curses regression test suite several times during the development of 3.4 and I don't recall it ever complaining, so I'm assuming there is no test for this function. But it's possible there is a test, but the irritating behavior of test_curses means it's impossible to see the result.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19697] Document the possible values for __main__.__spec__
Eric Snow added the comment: Here's a basic patch. It introduces __main__ in import.rst and then identifies the cases where __spec__ is set to None or otherwise. There are a few :ref: links to labels on other pages that I had trouble with. I'll address those when I put up a new draft after feedback. Any suggestions on making them work would be helpful. :) -- keywords: +patch Added file: http://bugs.python.org/file34656/issue19697-basic.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19697 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
Changes by koobs koobs.free...@gmail.com: -- nosy: +koobs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19711] add test for changed portions after reloading a namespace package
Eric Snow added the comment: A related addition (Lib/test/test_importlib/test_api.py - test_reload_namespace_changed): changeset: 86819:88c3a1a3c2ff3c3ab3f2bd77f0d5d5e5c1b37afa parent: 86816:13a05ed33cf7 user:Eric Snow ericsnowcurren...@gmail.com date:Thu Oct 31 22:22:15 2013 -0600 summary: Issue #19413: Restore pre-3.3 reload() semantics of re-finding modules. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19711 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15968] Incorporate Tcl/Tk/Tix into the Windows build process
Terry J. Reedy added the comment: I just pulled and recompiled and got makefile error messages that I do not remember seeing: 13EXEC : error : ..\..\tix-8.4.3.4 doesn't exist. 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: IF EXIST ..\..\tcltk\lib\tix8.4.3\tix84g.dll ( 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: echo Tix is already built and available. 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: exit /b 0 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: ) 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: IF NOT EXIST ..\..\tix-8.4.3.4 ( 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: echo error: ..\..\tix-8.4.3.4 doesn't exist. 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: exit 1 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: ) 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: IF Win32 EQU Win32 set TclMachine=IX86 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: IF Win32 EQU x64 set TclMachine=AMD64 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: IF Debug EQU Debug ( 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: set TixDebug=1 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: ) ELSE ( 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: set TixDebug=0 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: ) 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: cd ..\..\tix-8.4.3.4\win 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: nmake -f python.mak MACHINE=%TclMachine% DEBUG=%TixDebug% TCL_DIR=F:\Python\dev\5\py35\PCbuild\..\..\tcl-8.6.1.0 TK_DIR=F:\Python\dev\5\py35\PCbuild\..\..\tk-8.6.1.0 all nmake -f python.mak MACHINE=%TclMachine% DEBUG=%TixDebug% TCL_DIR=F:\Python\dev\5\py35\PCbuild\..\..\tcl-8.6.1.0 TK_DIR=F:\Python\dev\5\py35\PCbuild\..\..\tk-8.6.1.0 INSTALL_DIR=F:\Python\dev\5\py35\PCbuild\..\..\tcltk install 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: exited with code 1. I also got 6 failures instead of the usual 3 or 4. On the other hand, import idlelib.idle worked and the test_idle work both alone and when running everything. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21074] Too aggressive constant folding
Raymond Hettinger added the comment: Special cases aren't special enough to break the rules. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21074] Too aggressive constant folding
Raymond Hettinger added the comment: FWIW, I concur with Steve Holden and recommend closing this. It would be ashamed to hack-up constant-folding to handle an arcane case of an uncalled function that does space intensive constant operation. -- assignee: - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21014] `1` = `True`; for tutorial docs
Terry J. Reedy added the comment: Raymond, what I think you meant is that in 2.x, 'True' is a builtin name that can be shadowed by a user assignment True = 'not true' whereas in 3.x it is a keyword name like None that cannot be changed (None = 'some' fails even in 2.7). I checked and the patch is needed in 3.4 and (I presume) 3.5. -- nosy: +terry.reedy versions: +Python 3.4, Python 3.5 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9299] os.makedirs(): Add a keyword argument to suppress File exists exception
Guido van Rossum added the comment: For anyone watching this still, the fix introduced in this issue caused a security vulnerability, see http://bugs.python.org/issue21082 . -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21090] File read silently stops after EIO I/O error
New submission from ivank: I intentionally corrupted a zpool to induce an I/O error in a file, in this case, /usr/lib/x86_64-linux-gnu/gconv/IBM1390.so # ls -l /usr/lib/x86_64-linux-gnu/gconv/IBM1390.so -rw-r--r-- 1 root root 231,496 2014-03-24 06:26 /usr/lib/x86_64-linux-gnu/gconv/IBM1390.so # cat /usr/lib/x86_64-linux-gnu/gconv/IBM1390.so /dev/null cat: /usr/lib/x86_64-linux-gnu/gconv/IBM1390.so: Input/output error When I read the file, Python 3.3.5 and 3.4.0 check for EIO and raise an exception: open(/usr/lib/x86_64-linux-gnu/gconv/IBM1390.so, rb).read() Traceback (most recent call last): File stdin, line 1, in module OSError: [Errno 5] Input/output error but Python 2.7.6 does not: # python2 Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type help, copyright, credits or license for more information. x = open(/usr/lib/x86_64-linux-gnu/gconv/IBM1390.so, rb).read() len(x) 131072 -- components: IO messages: 215085 nosy: ivank priority: normal severity: normal status: open title: File read silently stops after EIO I/O error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21090 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15968] Incorporate Tcl/Tk/Tix into the Windows build process
Zachary Ware added the comment: Terry J. Reedy added the comment: I just pulled and recompiled and got makefile error messages that I do not remember seeing: 13EXEC : error : ..\..\tix-8.4.3.4 doesn't exist. This is the output of this line: snip 7 lines 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: echo error: ..\..\tix-8.4.3.4 doesn't exist. The rest of the messages are due to the following line: 13C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: exit 1 MSbuild just feels the need to output the entire command when it gets a failure at any point in it. The error: ..\..\tix-8.4.3.4 doesn't exist implies that you haven't run Tools/buildbot/external-common.bat since you updated past 8cf384852680. Tix has been included in the Windows installer for quite some time, but had never been pulled in by the external*.bat scripts or mentioned in the build process at all until this issue. As far as I know, Tix is not tested at all currently and nothing in the source tree depends on it. I also got 6 failures instead of the usual 3 or 4. On the other hand, import idlelib.idle worked and the test_idle work both alone and when running everything. test_idle will most likely fail if you run the tkinter tests first (i.e., PCbuild\python_d.exe -m test -uall test_tcl test_tk test_ttk_guionly test_ttk_textonly test_idle). Issue #20035 should fix that (but still needs review). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21082] os.makedirs(exist_ok=True) is not thread-safe: umask is set temporary to 0, serious security problem
Changes by Florent Xicluna florent.xicl...@gmail.com: -- nosy: +flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19871] json module won't parse a float that starts with a decimal point
Steve Holden added the comment: How about: A simple JSON decoder that converts between JSON string representations and Python data structures? -- nosy: +holdenweb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19871 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20098] email policy needs a mangle_from setting
Steve Holden added the comment: This is an easy issue? -- nosy: +holdenweb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20098 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21089] macro SET_SYS_FROM_STRING_BORROW doesn't get unset
Roundup Robot added the comment: New changeset c88a7c38eb0d by Benjamin Peterson in branch '3.4': undefine SET_SYS_FROM_STRING_BORROW after its done being used (closes #21089) http://hg.python.org/cpython/rev/c88a7c38eb0d New changeset c73b71363d4c by Benjamin Peterson in branch 'default': merge 3.4 (#21089) http://hg.python.org/cpython/rev/c73b71363d4c -- nosy: +python-dev resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21089 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Nick Coghlan added the comment: Yeah, as noted in my original comment, +0 for it's just a bug from me, as it was a quirk of the way this particular frozen module is initialised. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1615] PyObject_GenericGetAttr suppresses AttributeErrors in descriptors
Ethan Furman added the comment: Downside to this patch (stoneleaf.01) is that custom AttributeErrors raised in __getattr__ are overridden, which is a pretty severe regression. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1615 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1615] PyObject_GenericGetAttr suppresses AttributeErrors in descriptors
Changes by Ethan Furman et...@stoneleaf.us: Removed file: http://bugs.python.org/file34648/issue1615.stoneleaf.01.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1615 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1615] PyObject_GenericGetAttr suppresses AttributeErrors in descriptors
Changes by Ethan Furman et...@stoneleaf.us: -- Removed message: http://bugs.python.org/msg215091 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1615 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1615] PyObject_GenericGetAttr suppresses AttributeErrors in descriptors
Ethan Furman added the comment: Downside to this patch (stoneleaf.02) is that custom AttributeErrors raised in __getattr__ are overridden, which is a pretty severe regression. (Removed, renamed, and reloaded patch.) -- Added file: http://bugs.python.org/file34657/issue1615.stoneleaf.02.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1615 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19697] Document the possible values for __main__.__spec__
Nick Coghlan added the comment: Looks like a reasonable general structure to me. For label references, you don't want to include the leading underscore - that's part of the label syntax, not the label itself. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19697 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21089] macro SET_SYS_FROM_STRING_BORROW doesn't get unset
Eric Snow added the comment: Thanks, Benjamin. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21089 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose
Nick Coghlan added the comment: Bringing over Barry's suggestion from the current python-ideas thread [1]: @classmethod def fill(cls, length, value=0): # Creates a bytes of given length with given fill value [1] https://mail.python.org/pipermail/python-ideas/2014-March/027305.html -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20895 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21014] `1` = `True`; for tutorial docs
Roundup Robot added the comment: New changeset deb71529aad1 by Raymond Hettinger in branch '3.4': Issue 21014: Use booleans instead of 0 and 1 in examples. http://hg.python.org/cpython/rev/deb71529aad1 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19697] Document the possible values for __main__.__spec__
Eric Snow added the comment: That did the trick, Nick. I swear there's always something I forget about ReST. :) Otherwise do you have any objections to the patch? I imagine there's more we could put in the section (for language spec purposes), but I figure what I have there is good enough for the moment. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19697 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19697] Document the possible values for __main__.__spec__
Nick Coghlan added the comment: is some cases is a typo, but otherwise, yeah, may as well commit this so the website gets updated while we decide what else (if anything) we want to cover. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19697 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21014] `1` = `True`; for tutorial docs
Raymond Hettinger added the comment: Samuel, thanks for the patch. And, Terry, thanks for looking at it. Applied the first two changes to 3.4 and 3.5. Skipped, the third suggested change in introduction.rst. That was not a boolean example, it was just the number 1 in a section about how comments work, so it shouldn't change. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19697] Document the possible values for __main__.__spec__
Roundup Robot added the comment: New changeset 21d8222b667f by Eric Snow in branch 'default': Issue #19697: Document cases where __main__.__spec__ is None. http://hg.python.org/cpython/rev/21d8222b667f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19697 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19697] Document the possible values for __main__.__spec__
Roundup Robot added the comment: New changeset 4972475ae2e7 by Eric Snow in branch '3.4': Issue #19697: Document cases where __main__.__spec__ is None. http://hg.python.org/cpython/rev/4972475ae2e7 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19697 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19697] Document the possible values for __main__.__spec__
Eric Snow added the comment: Wish I had done that in the opposite direction. Anyway, thanks Nick. -- resolution: - fixed stage: test needed - committed/rejected status: open - closed versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19697 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose
Josh Rosenberg added the comment: Why would we need bytes.fill(length, value)? Is b'\xVV' * length (or if value is a variable containing int, bytes((value,)) * length) unreasonable? Similarly, bytearray(b'\xVV) * length or bytearray((value,)) * length is both Pythonic and performant. Most sequences support multiplication so simple stuff like this can be done easily and consistently; why invent a new approach unique to bytes/bytearrays? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20895 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21091] EmailMessage.is_attachment should be a method
New submission from Brandon Rhodes: I love properties and think they should be everywhere. But consistency is more important, so I suspect that EmailMessage.is_attachment should be demoted to a normal method. Why? Because if it remains a property then I am likely to first write: if msg.is_attachment: ... and then later, when doing another bit of email logic, write: if msg.is_multipart: ... Unfortunately this second piece of code will give me no error and will appear to run just fine, because bool(a_method) always returns True without a problem or warning or error. But the result will not be what I expect: the if statement's true block will always run, regardless of whether the message is multipart. Since EmailMessage is still provisional, and since no one can use is_attachment yet anyway because it is broken for nearly all attachments, mightn't we make these two features consistent before calling it official? -- components: email messages: 215104 nosy: barry, brandon-rhodes, r.david.murray priority: normal severity: normal status: open title: EmailMessage.is_attachment should be a method versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21091 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19837] Wire protocol encoding for the JSON module
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19837 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17909] Autodetecting JSON encoding
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10976] json.loads() raises TypeError on bytes object
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10976 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose
R. David Murray added the comment: Also, to me 'fill' implies something is being filled, not that something is being created. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20895 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21092] json serializer implicitly stringifies non-string keys
New submission from Chris Rebert:
Python 3.3.4 (default, Feb 21 2014, 18:00:34)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type help, copyright, credits or license for more information.
from json import dumps
dumps({True: True, False: False, None: None, 42: 42})
'{false: false, true: true, 42: 42, null: null}'
This implicit stringification of non-string dictionary keys does not currently
appear to be documented.
--
assignee: docs@python
components: Documentation
messages: 215105
nosy: cvrebert, docs@python
priority: normal
severity: normal
status: open
title: json serializer implicitly stringifies non-string keys
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21092
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
