[issue20123] pydoc.synopsis fails to load binary modules
koobs added the comment: koobs-freebsd9 (3.4) buildbot has also been failing for a while on what seems to be this changeset: == ERROR: test_synopsis_sourceless (test.test_pydoc.PydocDocTest) -- Traceback (most recent call last): File /usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/test/test_pydoc.py, line 504, in test_synopsis_sourceless synopsis = pydoc.synopsis(filename) File /usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/pydoc.py, line 238, in synopsis mtime = os.stat(filename).st_mtime FileNotFoundError: [Errno 2] No such file or directory: '/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/__pycache__/os.cpython-34.pyc' Full buildlog is attached. -- Added file: http://bugs.python.org/file34796/koobs-freebsd9-3.4-build57.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20128] Re-enable test_modules_search_builtin() in test_pydoc
koobs added the comment: test_synopsis_sourceless is also failing on koobs-freebsd9 (3.4) and has been for a while. Failing test inlined here, for full buildlog, see msg215997 in #20123 == ERROR: test_synopsis_sourceless (test.test_pydoc.PydocDocTest) -- Traceback (most recent call last): File /usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/test/test_pydoc.py, line 504, in test_synopsis_sourceless synopsis = pydoc.synopsis(filename) File /usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/pydoc.py, line 238, in synopsis mtime = os.stat(filename).st_mtime FileNotFoundError: [Errno 2] No such file or directory: '/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/__pycache__/os.cpython-34.pyc' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20128 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21204] published examples don't work
Martin v. Löwis added the comment: jmaki: not sure what the issue is that you are reporting. I can see three different possible issues. 1. Would you consider putting examples As R. David said: yes, we consider it. If you really wanted to know whether we consider it, we could close the issue as fixed. 2. Please make examples This would be a (near) duplicate of #15939, so I should close this issue as a duplicate. 3. The specific example does not work on Windows. This issue should stay open until it is analysed an possibly fixed. If that is the issue, then it would be helpful if you could report how exactly the example fails. I'd like to see a strict one issue at a time policy in this tracker, so please let us know how you would like us to proceed. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21204 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21158] Windows installer service could not be accessed (Python bug!)
Martin v. Löwis added the comment: Payden Comer, please run msiexec /i msifilename /l*v python.log in a terminal window, and attach the resulting python.log here. R. David: Feel free to copy these instructions; they can be standard in all cases of the installer does not work. As for the actual report: The first issue (python bug.PNG) has a clear explanation: Windows installer does not support simultaneous installation of two MSI files. So while ffmpeg (or whatever the scratched-out name is) is being installed, it refuses to start the Python installation. As for the second problem: Other software authors have put texts on the net on potential causes for this problem. I think going through http://support.affixa.com/kb/236 could be helpful. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21158 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21158] Windows installer service could not be accessed
Changes by Martin v. Löwis mar...@v.loewis.de: -- title: Windows installer service could not be accessed (Python bug!) - Windows installer service could not be accessed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21158 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21202] Naming a file` io.py` causes cryptic error message
Martin v. Löwis added the comment: I think the AttributeError message should improve, and special-case certain common types, in particular modules. E.g. it could read AttributeError: module 'io' has no attribute 'BufferedIOBase' or even AttributeError: module 'io' from 'C:\\Program Files\\Python34\\lib\\io.py' has no attribute 'BufferedIOBase' IIUC, the first version would already have helped the OP, and the second version would have been dead-clear (except that it is a little verbose). -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21202 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Serhiy Storchaka added the comment: I don't think this is a bug. Any text output operation can fail when outputs unencodable string. You should use a stream with proper encoding and/or error handler. -- nosy: +serhiy.storchaka resolution: - invalid stage: needs patch - committed/rejected status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21188] Broken link
Martin v. Löwis added the comment: LtWorf: What copy of the file are you looking at? In http://hg.python.org/cpython/file/84bc6998f760/Modules/gcmodule.c I see different links, and the all work fine. They were changed in http://hg.python.org/cpython/diff/d040a3b63df4/Modules/gcmodule.c Closing the issue as fixed. -- nosy: +loewis resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21188 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17861] put opcode information in one place
Martin v. Löwis added the comment: Please add the file to .hgtouch as well, and verify that make touch works correctly. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17861 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9066] Standard type codes for array.array, same as struct
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +serhiy.storchaka versions: +Python 3.5 -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17345] Portable and extended type specifiers for array module
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +serhiy.storchaka versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17345 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21171] Outdated usage str.encode('rot-13') in rot13 codec
Serhiy Storchaka added the comment: LGTM. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21171 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Martin v. Löwis added the comment: I agree that it is not a bug if the device where the prompt is shown simply does not support the characters; on Unix, this includes cases where the locale does not support the characters. Arfrever: when you say that it fails in Python 3 in a non-UTF-8 locale, which specific locale was that that it failed in? -- nosy: +loewis status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18321] Multivolume support in tarfile module
Eduardo Robles Elvira added the comment: The example I gave is based on the idea that there is a TarVolumeSet class in the tarfile module that implements all the required file-object methods (e.g. read(), write(), seek(), etc.) and acts as if the sequence of volumes is actually one big file. It is passed to tarfile.open() as the fileobj argument. This TarVolumeSet class is supposed to be subclassable to let the user implement her/his own mode of operation. This way the open_volume() method can do whatever the user wants it to do. The TarVolumeSet class might as well have a new_volume() method for writing multivol archives, the example only covered the case of reading a multivol archive. This is not so easy, because for example if you want to move the logic in addfile() that manages volumes to the write() function, you have some issues: * write() will need to take into account blocks (BLOCKSIZE), just to be able to split the volumes correctly. This is something that usually shouldn't belong in a write() function as it has to do to tarfile.. and it can be messy that both layers deal with it (write() splitting volumes, and tarfile adding NUL at the end of a BLOCK..) This can be done I guess, but remember, we split a volume only in the middle of a big file, not in any other case (AFAIK). Hopefully you don't get huge pax headers or anything strange. Usually all other records are either in the begining or just occupy one block, but can we rule this problem out for good? * multivolume logic in write() needs read/write access to the current tarinfo being written (look for tarfile in addfile() funcion in my patch to see why). How do you propose this object should be accessed from write()? BTW, my version of GNU tar refuses to create compressed multiple-volume archives which is why I doubt the usefulness of this feature overall. But it has multivolume support right? Which is what I am proposing here. Also, you can gzip (or encrypt or anything) the volumes after creating the volumes.. [...] because a multivol tarfile is not exactly the same as a normal tarfile chopped up. No, I think it is exactly that. The only purpose of the GNUTYPE_MULTIVOL header that is at the start of each subsequent volume is to give GNU tar the ability to detect if it is reading the correct volume. It is not essential and could as well be left out. I'm not going to discuss this, because I think that we can implement it in the way you propose to implement it anyway. But my patch supports it and I think it's an *useful* feature, so I want it in :-P -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18321 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length
Martin v. Löwis added the comment: FWIW, using l for file_read goes back to http://hg.python.org/cpython/diff/f44a56e697fb/Objects/fileobject.c from Fri, 09 May 1997 22:27:31 + -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Serhiy Storchaka added the comment:
$ LC_ALL=en_US.iso88591 ./python -c print('\u20ac')
Traceback (most recent call last):
File string, line 1, in module
UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in position
0: ordinal not in range(256)
$ LC_ALL=en_US.iso88591 ./python -c input('\u20ac')
Traceback (most recent call last):
File string, line 1, in module
UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in position
0: ordinal not in range(256)
$ LC_ALL=en_US.iso88591 ./python -c import getpass; getpass.getpass('\u20ac')
Traceback (most recent call last):
File string, line 1, in module
File /home/serhiy/py/cpython/Lib/getpass.py, line 78, in unix_getpass
passwd = _raw_input(prompt, stream, input=input)
File /home/serhiy/py/cpython/Lib/getpass.py, line 138, in _raw_input
stream.write(prompt)
UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in position
0: ordinal not in range(256)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21169
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20701] warning in compileall.rst
Arfrever Frehtes Taifersar Arahesis added the comment: It seems to have been fixed by: New changeset f8dbec87dbfe by Georg Brandl in branch '3.4': Fix option description that is a warning in new Sphinx versions. http://hg.python.org/cpython/rev/f8dbec87dbfe -- nosy: +Arfrever resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20701 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21210] Warnings in Doc/library/json.rst
New submission from Arfrever Frehtes Taifersar Arahesis:
Warnings during building of documentation (with Sphinx 1.2.2):
${cpython_working_copy}/Doc/library/json.rst:593: WARNING: Malformed option
description '[infile]', should look like opt, -opt args, --opt args or
/opt args
${cpython_working_copy}/Doc/library/json.rst:609: WARNING: Malformed option
description '[outfile]', should look like opt, -opt args, --opt args or
/opt args
Probably introduced by:
New changeset a2ad16e86e60 by Benjamin Peterson in branch 'default':
improve the command-line interface of json.tool (closes #21000)
http://hg.python.org/cpython/rev/a2ad16e86e60
--
assignee: docs@python
components: Documentation
messages: 216012
nosy: Arfrever, benjamin.peterson, berker.peksag, docs@python
priority: normal
severity: normal
status: open
title: Warnings in Doc/library/json.rst
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21210
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20702] warning in cmdline.rst
Arfrever Frehtes Taifersar Arahesis added the comment: I cannot reproduce it with Sphinx 1.2.2. Can you still reproduce it? Which version of Sphinx? -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20702 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Arfrever Frehtes Taifersar Arahesis added the comment: Martin v. Löwis: In this case, device support non-ASCII characters, but Python's getpass module forgets to properly encode string. Message 215697 contains example with C locale. -- resolution: invalid - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21210] Warnings in Doc/library/json.rst
Berker Peksag added the comment: Thanks for the report Arfrever. Here's a patch to silence the warnings. -- keywords: +patch Added file: http://bugs.python.org/file34797/issue21210.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21210 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18321] Multivolume support in tarfile module
Lars Gustäbel added the comment: [...] but remember, we split a volume only in the middle of a big file, not in any other case (AFAIK). Hopefully you don't get huge pax headers or anything strange. [...] Hopefully? Sorry, but have you tested this? I did. I let GNU tar create a two volume archive that is split exactly between the two blocks of an XHDTYPE pax header. The result is terrifying. At the beginning of the second volume GNU tar creates an XGLTYPE header as the pax replacement for a GNUTYPE_MULTIVOL header, followed by an XHDTYPE header (GNUFileParts) that somehow decorates the following REGTYPE(!) tar header that contains the continuation of the split XHDTYPE header data from the previous volume. After that comes the REGTYPE file that the split XHDTYPE header was actually meant for as decoration. I attached the archive to this issue. What happens if a GNUTYPE_LONGNAME header is split in two? I don't wanna know... write() will need to take into account blocks (BLOCKSIZE), just to be able to split the volumes correctly. It is mandatory to do the split on a block boundary (a multiple of 512). * multivolume logic in write() needs read/write access to the current tarinfo being written [...]. How do you propose this object should be accessed from write()? I don't know and this problem seems to be quite hard to address with my approach. That's too bad. BTW, my version of GNU tar refuses to create compressed multiple-volume archives which is why I doubt the usefulness of this feature overall. But it has multivolume support right? Which is what I am proposing here. Also, you can gzip (or encrypt or anything) the volumes after creating the volumes.. Yeah, it has multivolume support, but a very limited one that is not only weird but isn't even usable together with compression. And sure, I can compress and encrypt the volumes afterwards, but I can also create a compressed archive and pipe it through split(1) to split it into parts. Both ways create tar archives that are not readable by GNU tar because they're non-standard. So what? Please tell me, what is your actual personal use-case for this feature? -- Added file: http://bugs.python.org/file34798/split-xhdtype.tar.gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18321 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length
Josh Rosenberg added the comment: So it predates the existence of type code 'n', which would be the appropriate type code, but no one updated it. Antoine: Inability to perform a 2GB+ read properly is not something that should be worked around on a case by case basis. There is one compatibility risk here, which is that 'n' requires index integers (__index__), where 'l' will accept coercible types (__int__). If you think people are reading from files using Fraction and Decimal, then this would be a compatibility issue (and you could work around it be making it use type code 'L' only on 64 bit Windows), but this just looks like an oversight from the upgrade from int to Py_ssize_t across the Python code base. -- nosy: +josh.rosenberg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21171] Outdated usage str.encode('rot-13') in rot13 codec
Roundup Robot added the comment: New changeset a81f0caab279 by Serhiy Storchaka in branch '3.4': Issue #21171: Fixed undocumented filter API of the rot13 codec. http://hg.python.org/cpython/rev/a81f0caab279 New changeset f86504da2fcc by Serhiy Storchaka in branch 'default': Issue #21171: Fixed undocumented filter API of the rot13 codec. http://hg.python.org/cpython/rev/f86504da2fcc -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21171 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray
Paul Sokolovsky added the comment:
array.array('i', [0]) * 3
@Serhiy Storchaka:
The keyword is efficiently. Let's analyze: this creates useless
array.array('i', [0]) object destined only for garbage collection. Then, it
forces using loop of loops to fill in a new object. Whereas array.array('i', 3)
immediately reduces to a memset().
You can say that these implementation efficiency issues are of little concert
to CPython. But what's being reported here is that, while generally Python is
pretty good in allowing to efficiently process raw binary data (memoryview and
all other bits and pieces), there are inconsistent accidental gaps in API here
and there which jeopardize efficiency, in obvious way (and also obvious to
resolve), what may be of concern for other Python implementations (my case).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21180
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
Changes by Ned Deily n...@acm.org: -- nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20998] fullmatch isn't matching correctly under re.IGNORECASE
Serhiy Storchaka added the comment:
After stepping through the code for that regex that fails, I concluded
that the condition shouldn't depend on ctx-match_all at that point
after all.
Tests are passed without this check. But I'm not sure it is not needed. At
least without this check the code is not equivalent to the code before adding
support for fullmatch(). So I prefer to left it as is.
I thought I'd initialised it in all the places it's used.
I admit that I find the code a little hard to follow at times... :-(
Indeed, it is initialized in Modules/_sre.c, and it is always 0. Perhaps it
will be more consistent to get rid of the match_all field in the SRE_STATE
structure and pass it as argument.
--
Added file: http://bugs.python.org/file34799/issue20998_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20998
___diff -r f86504da2fcc Lib/test/test_re.py
--- a/Lib/test/test_re.py Sun Apr 13 17:08:51 2014 +0300
+++ b/Lib/test/test_re.py Sun Apr 13 18:23:53 2014 +0300
@@ -1223,6 +1223,11 @@
pat.scanner(string='abracadabra', pos=3,
endpos=10).search().span(),
(7, 9))
+def test_bug_20998(self):
+# Issue #20998: Fullmatch of repeated single character pattern
+# with ignore case.
+self.assertEqual(re.fullmatch('[a-c]+', 'ABC', re.I).span(), (0, 3))
+
class PatternReprTests(unittest.TestCase):
def check(self, pattern, expected):
diff -r f86504da2fcc Modules/_sre.c
--- a/Modules/_sre.cSun Apr 13 17:08:51 2014 +0300
+++ b/Modules/_sre.cSun Apr 13 18:23:53 2014 +0300
@@ -505,14 +505,14 @@
}
LOCAL(Py_ssize_t)
-sre_match(SRE_STATE* state, SRE_CODE* pattern)
+sre_match(SRE_STATE* state, SRE_CODE* pattern, int match_all)
{
if (state-charsize == 1)
-return sre_ucs1_match(state, pattern);
+return sre_ucs1_match(state, pattern, match_all);
if (state-charsize == 2)
-return sre_ucs2_match(state, pattern);
+return sre_ucs2_match(state, pattern, match_all);
assert(state-charsize == 4);
-return sre_ucs4_match(state, pattern);
+return sre_ucs4_match(state, pattern, match_all);
}
LOCAL(Py_ssize_t)
@@ -576,7 +576,7 @@
TRACE((|%p|%p|MATCH\n, PatternObject_GetCode(self), state.ptr));
-status = sre_match(state, PatternObject_GetCode(self));
+status = sre_match(state, PatternObject_GetCode(self), 0);
TRACE((|%p|%p|END\n, PatternObject_GetCode(self), state.ptr));
if (PyErr_Occurred())
@@ -609,12 +609,11 @@
if (!string)
return NULL;
-state.match_all = 1;
state.ptr = state.start;
TRACE((|%p|%p|FULLMATCH\n, PatternObject_GetCode(self), state.ptr));
-status = sre_match(state, PatternObject_GetCode(self));
+status = sre_match(state, PatternObject_GetCode(self), 1);
TRACE((|%p|%p|END\n, PatternObject_GetCode(self), state.ptr));
if (PyErr_Occurred())
@@ -2572,7 +2571,7 @@
state-ptr = state-start;
-status = sre_match(state, PatternObject_GetCode(self-pattern));
+status = sre_match(state, PatternObject_GetCode(self-pattern), 0);
if (PyErr_Occurred())
return NULL;
diff -r f86504da2fcc Modules/sre.h
--- a/Modules/sre.h Sun Apr 13 17:08:51 2014 +0300
+++ b/Modules/sre.h Sun Apr 13 18:23:53 2014 +0300
@@ -86,7 +86,6 @@
SRE_REPEAT *repeat;
/* hooks */
SRE_TOLOWER_HOOK lower;
-int match_all;
} SRE_STATE;
typedef struct {
diff -r f86504da2fcc Modules/sre_lib.h
--- a/Modules/sre_lib.h Sun Apr 13 17:08:51 2014 +0300
+++ b/Modules/sre_lib.h Sun Apr 13 18:23:53 2014 +0300
@@ -173,7 +173,7 @@
}
}
-LOCAL(Py_ssize_t) SRE(match)(SRE_STATE* state, SRE_CODE* pattern);
+LOCAL(Py_ssize_t) SRE(match)(SRE_STATE* state, SRE_CODE* pattern, int
match_all);
LOCAL(Py_ssize_t)
SRE(count)(SRE_STATE* state, SRE_CODE* pattern, Py_ssize_t maxcount)
@@ -259,7 +259,7 @@
/* repeated single character pattern */
TRACE((|%p|%p|COUNT SUBPATTERN\n, pattern, ptr));
while ((SRE_CHAR*) state-ptr end) {
-i = SRE(match)(state, pattern);
+i = SRE(match)(state, pattern, 0);
if (i 0)
return i;
if (!i)
@@ -490,7 +490,7 @@
/* check if string matches the given pattern. returns 0 for
error, 0 for failure, and 1 for success */
LOCAL(Py_ssize_t)
-SRE(match)(SRE_STATE* state, SRE_CODE* pattern)
+SRE(match)(SRE_STATE* state, SRE_CODE* pattern, int match_all)
{
SRE_CHAR* end = (SRE_CHAR *)state-end;
Py_ssize_t alloc_pos, ctx_pos = -1;
@@ -507,7 +507,7 @@
ctx-last_ctx_pos = -1;
ctx-jump = JUMP_NONE;
ctx-pattern = pattern;
-ctx-match_all = state-match_all;
+ctx-match_all = match_all;
ctx_pos = alloc_pos;
entrance:
@@ -824,7 +824,7 @@
}
if (ctx-pattern[ctx-pattern[0]] == SRE_OP_SUCCESS
-
[issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray
Paul Sokolovsky added the comment:
@Terry J. Reedy:
Thanks for the pointer. My inital response is sadness, another bloating of
namespace. But I'm adjusting.
But that PEP shows the issue with all that activity: CPython stdlib got so big
and bloated, that it lives its own life and people consider it normal. So,
there're PEPs to perfectalize bytearray, without paying attention to the fact
that array.array('B') is pretty much the same thing, but apirots (cf. bitrot)
behind it.
So, following PEP467, this request should be updated to call for
array.array.zero(typecode, size) factory method. Note that it would need to
take 2 arguments to follow array.array API. Is that good or bad? IMHO, not much
worse than introducing separate factory method at all. But again, author of
PEP467 should rather consider how those proposals extend to other related types.
If you participate in the discussion of the PEP, I'd appreciate if shared there
link to this ticket - I'm not in loop of general CPython development and have
limited resources to learn/follow them. Thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21180
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray
Martin v. Löwis added the comment:
Paul: Discussion of the PEP is out of the scope of this issue. The primary
point of the PEP process is that it steers discussion. So if you object to the
PEP, contact the PEP author and ask for your objection to be considered, and if
not that, at least be recorded.
I feel that your proposed change is highly confusing. People might expect that
array.array('i', 3)
creates an array with the single value 3 (just as they factually do expect that
for bytes). Keyword-only parameters might clear that ambiguity, e.g.
array.array('i', len=3)
array.array(type='i', len=3, value=0)
In any case, it is unlikely that anything will be done with this issue unless
you provide a patch (and that still would be no guarantee that somebody accepts
it).
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21180
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20998] fullmatch isn't matching correctly under re.IGNORECASE
Serhiy Storchaka added the comment: Gareth, this is unrelated issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length
Martin v. Löwis added the comment: Josh: it's not as simple as just changing the type code and variable type. Systems used to require all kinds of types in the length parameter of read(2) and fread(3), including int, long, and size_t. If it was int, passing size_t would lead to silent truncation. So at a minimum, a careful review of the further processing, and a test case is necessary. I'm personally not interested in Python 2.7 anymore, so I certainly won't work on this. As for why this isn't reported frequently, I guess a number of causes: a) people don't use Python on Windows that much to process large files b) when they do and run into this problem, they feel guilty for actually asking for a such large chunk, which could well exhaust the memory of the system. c) there is a straight-forward work-around d) people that do read large files typically either read them at once, or in much smaller chunks So it may well be that this remains the only report of this for the rest of Python 2.7's life. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18983] Specify time unit for timeit CLI
Quentin Pradet added the comment: The branch appears to exist now. -- nosy: +Quentin.Pradet ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21180] Cannot efficiently create empty array.array of given size, inconsistency with bytearray
Paul Sokolovsky added the comment:
Martin:
People might expect that array.array('i', 3) creates an array with the single
value 3.
I don't know which people would expect that. Personally I recognize the need to
create an empty array of of given size, and have read the docs for builtin
bytearray type, and expect extension type array.array to work the same. I'd
even say that I found any other expectations ungrounded, in particular, a way
to create an array of single int is obviously bytearray([3]) or
array.array('i', [3]).
Anyway, as I say in 2014-04-13 15:29 comment, I'm only glad to follow with
PEP467 changes. Unfortunately, I don't seem to be able to update initial ticket
description with updated proposal.
array.array('i', len=3)
The whole scope of this ticket is to have consistent API between bytearray and
array.array. So, the only way I could suggest (or back) the above is if PEP467
was changed too, and as you suggest, I don't do that. (I personally also
dislike overuse of keyword args.)
In any case, it is unlikely that anything will be done with this issue unless
you provide a patch (and that still would be no guarantee that somebody
accepts it).
The ending is the saddest. As I mentioned, the best outcome I could imagine of
such reports is that people who consider changing builtin types to also
consider obvious stdlib counterparts too. (There's another issue - stdlib is
indeed enormous, so it would be nice to separate it (speculatively) into
[builtin types/lib], core stdlib, and extended stdlib. There's clear
difference between array module and for example unittest or logging.
Thanks for hint re: mailing Nick Coghlan - nice to know that's acceptable,
that's certainly easier than figuring out which mailing list to use and then to
follow it. (I see that Nick is in noselist of this ticket, but I guess I'll
mail him anyway to have my conscience clear that I did everything to make
Python better (== more consistent)).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21180
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length
Antoine Pitrou added the comment: Antoine: Inability to perform a 2GB+ read properly is not something that should be worked around on a case by case basis. Really we are talking about Python 2.7 here. Anyone having this problem *has* to work it around in order for their code to work on published versions. The benefit of fixing this in the next 2.7.x iteration is small compared to the cost of a potential regression in the core I/O implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20635] Fix the grid geometry manager and add tests for geometry managers
Roundup Robot added the comment: New changeset e8c184d8407d by Serhiy Storchaka in branch '3.4': Issue #20635: Added tests for Tk geometry managers. http://hg.python.org/cpython/rev/e8c184d8407d New changeset e8acef4f8567 by Serhiy Storchaka in branch 'default': Issue #20635: Added tests for Tk geometry managers. http://hg.python.org/cpython/rev/e8acef4f8567 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20635 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20635] Fix the grid geometry manager and add tests for geometry managers
Serhiy Storchaka added the comment: Here is a patch for 2.7. -- Added file: http://bugs.python.org/file34800/test_geometry_managers_2-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20635 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20635] Fix the grid geometry manager and add tests for geometry managers
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20635 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20998] fullmatch isn't matching correctly under re.IGNORECASE
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20636] Better repr for tkinter widgets
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20636 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21180] Efficiently create empty array.array, consistent with bytearray
Terry J. Reedy added the comment: A few notes: This issue depends on PEP467, but there is no corresponding tracker issue yet to put in the dependency box. Title and other headers can be edited. Messages and uploaded files can be unlinked from the issue but not edited (or deleted from the database). Nick and other developers are busy with PyCon, so please be patient. Why this issue depends on the PEP: There is a general feeling that a default class constructor can be overloaded too far, and that a separate constructor method is sometimes better. Many people think that byte(s/array) is the worst stdlib example of 'too much'. In particular, few seem to like the 0 initializaiton and many dislike it. Changing it is the motivation for the PEP. From Guido's comments, I expect that some version of this change will be accepted even if other parts of the PEP are rejected and eliminated (as some already have been). In summary, while Martin and I agree that 'copy the existing bytearray api' should be rejected, we also think that 'copy the new api' can be considered if and when there is one. -- stage: - test needed title: Cannot efficiently create empty array.array of given size, inconsistency with bytearray - Efficiently create empty array.array, consistent with bytearray type: performance - enhancement versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21180 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] Add match parameter to filecmp.dircmp to ignore using patterns
Nikolaus Rath added the comment: Updated patch to acknowledge original authors in Misc/ACKS. -- Added file: http://bugs.python.org/file34801/issue1738_r3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1738 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7776] http.client.HTTPConnection tunneling is broken
Nikolaus Rath added the comment: Refreshed patch. -- Added file: http://bugs.python.org/file34802/issue7776_r7_Py3.4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7776] http.client.HTTPConnection tunneling is broken
Changes by Nikolaus Rath nikol...@rath.org: Added file: http://bugs.python.org/file34803/issue7776_r7_Py3.5.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19414] iter(ordered_dict) yields keys not in dict in some circumstances
Nikolaus Rath added the comment: The patch applies cleanly to 3.4 and 3.5, not sure why the review link does not show up. I'm attaching the file again, maybe that helps. -- Added file: http://bugs.python.org/file34804/issue19414_r2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19414 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Xavier de Gaye added the comment: The NameError exception occuring on a generator expression referencing a local variable when the generator is called within exec() is the object of multiple entries in the bug tracker, see issue 13557. msg 149096 in this issue suggests using exec(code, locals()) to fix the problem. It seems that what does currently the do_interact() method, and what is proposed in the patch is the recommended practice to handle this problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20635] Fix the grid geometry manager and add tests for geometry managers
Ned Deily added the comment: test_tk with test_geometry_managers_2-2.7.patch applied passed on OS X 10.9 linked with Carbon Tk 8.4.20, Cocoa 8.5.15, Cocoa 8.6.1, and X11 8.6.1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20635 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
Guido van Rossum added the comment: I'll be darned. It appears that generator's send() method uses METH_O, which means that it really expects a single argument, but if you pass it a tuple, it assumes that you meant each item in the tuple as a separate argument. I think a more correct fix is attached -- don't add a dummy *args to the send() method, but call self.gen.send((value,)). I'd like to fix this upstream and add some tests first; also see http://code.google.com/p/tulip/issues/detail?id=163 (which touches upon a different problem in CoroWrapper not emulating the real generator object well enough). -- assignee: - gvanrossum keywords: +patch Added file: http://bugs.python.org/file34805/gen_send.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
Changes by Terry J. Reedy tjre...@udel.edu: -- assignee: docs@python - terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18321] Multivolume support in tarfile module
Eduardo Robles Elvira added the comment: [...] but remember, we split a volume only in the middle of a big file, not in any other case (AFAIK). Hopefully you don't get huge pax headers or anything strange. [...] Hopefully? Sorry, but have you tested this? I did. I let GNU tar create a two volume archive that is split exactly between the two blocks of an XHDTYPE pax header. The result is terrifying. At the beginning of the second volume GNU tar creates an XGLTYPE header as the pax replacement for a GNUTYPE_MULTIVOL header, followed by an XHDTYPE header (GNUFileParts) that somehow decorates the following REGTYPE(!) tar header that contains the continuation of the split XHDTYPE header data from the previous volume. After that comes the REGTYPE file that the split XHDTYPE header was actually meant for as decoration. I attached the archive to this issue. What happens if a GNUTYPE_LONGNAME header is split in two? I don't wanna know... write() will need to take into account blocks (BLOCKSIZE), just to be able to split the volumes correctly. It is mandatory to do the split on a block boundary (a multiple of 512). BTW, my version of GNU tar refuses to create compressed multiple-volume archives which is why I doubt the usefulness of this feature overall. But it has multivolume support right? Which is what I am proposing here. Also, you can gzip (or encrypt or anything) the volumes after creating the volumes.. Yeah, it has multivolume support, but a very limited one that is not only weird but isn't even usable together with compression. And sure, I can compress and encrypt the volumes afterward, but I can also create a compressed archive and pipe it through split(1) to split it into parts. Both ways create tar archives that are not readable by GNU tar because they're non-standard. So what? Please tell me, what is your actual personal use-case for this feature? I'm willing modify the patch to remove the weirdness you refer to. I differ on that it's not usable: it might not be useful to you, but it's certainly a feature that covers part of the functionality of GNU tar. Actually, some of the unit tests are like this: use GNU Tar to compress, then extract with tarfile - and viceversa. Of course you can use split. And I could use Ruby or Perl, but I'm using python and tarfile, and this is a GNU tar feature that is just not supported in python tarfile upstream, and I'm just trying to contribute this feature, if possible :-). BTW, If I create a multivol tar file and then compress the volumes, that does not make it non-standard, in the same way that if I create a PNG file and then compress it and then store it in EXTFS, it doesn't make it non-standard. I'm just using multiple layers of standards. I'm a contractor, and I have been asked by a client to develop a python-based backup tool. The client is technical and had already an idea of what he wanted to do: use python-tarfile and add support to multivolume and some other goodies, and the client also wanted to try to push the changes upstream as we believe it is the correct thing to do. BTW, when we designed the backup tool, we ruled out the possibility of using split because split wouldn't allow to correctly list all the files in each file-slice separately. We wanted to be able to recover all the files of each volume so that if we lose other volumes, we can still recover all the data from the volumes we have. Anyway, if you are the maintainer of tarfile and you think it's not possible to push tar-multivolume support upstream in python tarfile for whatever reason, please tell me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18321 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6623] Lib/ftplib.py Netrc class should be removed.
Matt Chaput added the comment: Created patch to remove the Netrc class and its unit tests (for Python 3.5). -- nosy: +maatt Added file: http://bugs.python.org/file34806/remove_Netrc_class.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6623 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
Terry J. Reedy added the comment:
The doc bug is that the grammar block uses 'integer' (linked to
https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-integer)
in
arg_name ::= [identifier | integer]
element_index ::= integer | index_string
when it should use 'decimalinteger' or even more exactly 'digit+'. The int()
builtin uses the same relaxed rule when no base is given.
011
SyntaxError: invalid token
int('011')
11
'{[011]}'.format('abcdefghijlmn')
'm'
One possibity is to replace 'integer' in the grammar block with 'digit+' and
perhaps leave the text alone. Another is to replace 'integer' with
'index_number', to go with 'index_string, and add the production index_number
::= digit+. My though for the latter is that 'index_number' would connect
better with 'number' as used in the text. A further option would be to actually
replace 'number' in the text with 'index_number'.
PS to Todd. As much as possible, doc content changes should be separated from
re-formatting. I believe the first block of your patch is purely a re-format
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7951
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21210] Warnings in Doc/library/json.rst
Roundup Robot added the comment: New changeset 399bf1638911 by Benjamin Peterson in branch 'default': correct sphinx mark up for cmdline options (closes #21210) http://hg.python.org/cpython/rev/399bf1638911 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21210 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21208] Change default behavior of arguments with type bool when options are specified
Karl Richter added the comment: That's a pity, I still think it's confusing. Thanks for your feedback! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21208 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Kushal Das added the comment: Here is a new patch which uses stream.encoding instead getting the encoding from the locale as suggested by David. It also contains the new test. -- Added file: http://bugs.python.org/file34807/issue21169_v5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6623] Lib/ftplib.py Netrc class should be removed.
R. David Murray added the comment: This looks good, except that if we are not going to delete that test routine (and we aren't because we didn't deprecate it :) I think we should instead replace the usage of Netrc with the netrc module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6623 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21200] pkgutil.get_loader() fails on __main__
Eric Snow added the comment: Here's a patch that checks for modules that don't have __spec__ set. The patch will fix the problem. However note that the docs and docstring imply (to me) that we should turn any ImportError coming out of the find_loader() call into returning None. Fixing that will also fix this bug, so this patch may be unnecessary. -- keywords: +patch stage: test needed - patch review Added file: http://bugs.python.org/file34808/issue21200-pkgutil-main.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21200 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
Guido van Rossum added the comment: Heh. METH_O was *also* a red herring. But upstream (Tulip) issue 163 *was* a good clue. I now believe that the real bug is that CoroWrapper.__iter__() has return self rather than return iter(self.gen). That fix is in the 2nd attachment. -- Added file: http://bugs.python.org/file34809/gen_send_2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Kushal Das added the comment: New patchset with updated test, now sending ascii stream into the call as argument. -- Added file: http://bugs.python.org/file34810/issue21169_v6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7776] http.client.HTTPConnection tunneling is broken
Senthil Kumaran added the comment: I am reviewing this patch right now and you will see my action soon. It is completely and I am reviewing to validating the technical details/fix. Thanks for patch, Nikolaus. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21211] pkgutil.find_loader() raises ImportError instead of returning None
New submission from Eric Snow: In 3987667bf98f pkgutil.find_loader() switched from using pkgutil.iter_importers() to importlib.find_module(). importlib.find_module() checks the module's __loader__ (and raises ImportError when invalid) whereas iter_importers() does no such check. In 3.4 pkgutil.find_loader() switched over to importlib.util.find_spec(), but the same issue remains. The documentation (and the previous behavior) implies that the ImportError case coming out of find_spec() should result in pkgutil.find_loader() returning None rather than propagating the ImportError. However, it may make more sense to do an explicit check for module.__spec__ before calling find_spec(). -- components: Library (Lib) keywords: 3.3regression messages: 216047 nosy: brett.cannon, eric.snow, ncoghlan priority: high severity: normal stage: test needed status: open title: pkgutil.find_loader() raises ImportError instead of returning None type: behavior versions: Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21211 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21200] pkgutil.get_loader() fails on __main__
Eric Snow added the comment: I've opened #21211 to more directly address the find_loader() issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21200 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Martin v. Löwis added the comment: Arfrever: If you set the locale to C, the device does *not* (anymore) support the character. The terminal application you are using may, but the system does not. It only supports the characters available in the locale, which your character is not. There simply is no way in which Python *could* encode the character. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20578] BufferedIOBase.readinto1 is missing
Nikolaus Rath added the comment: Here's a little script to estimate the performance difference between using read1 and readinto1 to read large amounts of data. On my system, I get: C readinto1: 4.960e-01 seconds C read1: 4.055e-01 seconds Python readinto1: 1.066e+00 seconds Python read1: 2.565e+00 seconds In other words, _pyio.BufferedReader.readinto1 is more than a factor of 2 faster than _pyio.BufferedReader.read1 and io.readinto1 is faster than io.read1 by about 20%. On its own, I think this would justify keeping an implementation of readinto1 in _pyio.BufferedReader instead of falling back on the default (that is implemented using read1). However, I believe that people who need performance are probably not using _pyio but io, so *my* argument for keeping it implemented in _pyio is to keep the implementations similiar. I found studying _pyio very helpful to understand the C code in io. If we implement BufferedReader.readinto1 in io, but not in _pyio.BufferedReader, this advantage would be reduced. That said, I am primary interested in getting readinto1 into io. So I'm happy to either extend the patch to also provide a fast readinto implementation for _pyio (to align it with io), or to remove the readinto1 implementation in _pyio. -- Added file: http://bugs.python.org/file34811/benchmark.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20578 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Roundup Robot added the comment: New changeset f430fdd1628e by R David Murray in branch '3.4': #21169: fix getpass to use replace error handler on UnicodeEncodeError. http://hg.python.org/cpython/rev/f430fdd1628e New changeset 461f5863f2aa by R David Murray in branch 'default': Mierge #21169: fix getpass to use replace error handler on UnicodeEncodeError. http://hg.python.org/cpython/rev/461f5863f2aa -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
R. David Murray added the comment: Since we don't want the prompting for the password to fail, what we do in the patch is use the replace error handler so that you get as much as could be encoded of the prompt. (Note: this approach was reviewed by both Toshio and Marc Andre.) Thanks for the patch, Kushal. -- resolution: - fixed status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20578] BufferedIOBase.readinto1 is missing
Martin v. Löwis added the comment: Can you please extend your benchmark to also measure read and readinto? I'm puzzled why you are treating readinto1 differently from readinto. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20578 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Martin v. Löwis added the comment: Ok. I wish the patch had a comment saying that, or better even a documentation change pointing out that feature. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20578] BufferedIOBase.readinto1 is missing
Nikolaus Rath added the comment: (Rietveld is giving me errors, so I'm replying here) On 2014/04/13 02:22:23, loewis wrote: Again, why a separate implementation here? For performance reasons. Relying on the default implementation would fall back to using read1(), which means a new bytes object is created first. Hmm. a) if performance was relevant, it should apply to readinto() as well. I didn't even notice the readinto implementation was missing. But I agree, if we keep readinto1(), we should also add readinto(). b) if the code is duplicated for performance only, a comment should state that explicitly. I'm very sorry, but I still don't see which code in readinto1() is duplicate. You don't mean duplicate between io and _pyio, do you? c) to justify a performance argument, you should really provide hard numbers that demonstrate a performance gain justifying the code duplication. I posted a small benchmark to the issue tracker. Personally, I think the more important argument is to keep the Python and C implementations similar. It's really nice if you can look at _pyio to find out at least roughly what happens in io. (Yes, I did put performance first in my last reply, but only because I thought you were asking about readinto1 in general, rather than the additional Python implementation in _pyio.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20578 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20578] BufferedIOBase.readinto1 is missing
Nikolaus Rath added the comment: Can you please extend your benchmark to also measure read and readinto? Yes - but I don't quite understand why it matters (if you need read1/readinto1, you cannot just use read/readinto instead). C readinto1: 4.638e-01 seconds C read1: 4.026e-01 seconds C readinto: 4.655e-01 seconds C read: 4.028e-01 seconds Python readinto1: 1.056e+00 seconds Python read1: 2.429e+00 seconds Python readinto: 1.895e+00 seconds Python read: 1.218e+00 seconds That shows that the Python readinto is definetely not up-to-par and could use improvement as well. Is that what you're getting at? I'm puzzled why you are treating readinto1 differently from readinto. Maybe this is why we seem to be talking past each other :-). I did not look or work on readinto at all. All I noticed is that there is a read1, but no readinto1. So I implemented a readinto1 as well as I could. -- Added file: http://bugs.python.org/file34812/benchmark.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20578 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
STINNER Victor added the comment: The error occurs at line v = yield from q.get(): Traceback (most recent call last): File /home/haypo/prog/python/default/Lib/asyncio/events.py, line 39, in _run self._callback(*self._args) File /home/haypo/prog/python/default/Lib/asyncio/tasks.py, line 357, in _wakeup self._step(value, None) File /home/haypo/prog/python/default/Lib/asyncio/tasks.py, line 309, in _step self.set_exception(exc) File /home/haypo/prog/python/default/Lib/asyncio/tasks.py, line 301, in _step result = coro.send(value) File put_get_bug.py, line 23, in t2 v = yield from q.get() TypeError: send() takes 2 positional arguments but 7 were given Task._step() is called with value=(0, 1, 2, 3, 4, 5) (and exc is None). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
STINNER Victor added the comment: gen_send.diff doesn't look like a fix but a workaround. gen_send_2.diff lacks a unit test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20578] BufferedIOBase.readinto1 is missing
Martin v. Löwis added the comment: I didn't even notice the readinto implementation was missing. But I agree, if we keep readinto1(), we should also add readinto(). [...] Maybe this is why we seem to be talking past each other :-). I did not look or work on readinto at all. All I noticed is that there is a read1, but no readinto1. So I implemented a readinto1 as well as I could. I see. It's not actually true that there is no readinto - it's inherited from the base class. I think it is more important that the implementation is consistent than that it is performant (but achieving both should be possible). Whether or not _pyio needs to be performant, I don't know. Having it consistent with _io would be desirable, but might not be possible. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20578 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
STINNER Victor added the comment: I don't think that the bug comes from asyncio, but it looks like a bug in the implementation of yield from in CPython directly! Try with ceval.patch. ceval.c has a fast path if the object is a generator. With PYTHONASYNCIODEBUG=1, the object is a CoroWrapper, not a generator. In this case, the slow path is used: retval = _PyObject_CallMethodId(reciever, PyId_send, O, v); This line comes from the initial commit introducing yield-from: --- changeset: 74356:d64ac9ab4cd0 user:Nick Coghlan ncogh...@gmail.com date:Fri Jan 13 21:43:40 2012 +1000 files: Doc/library/dis.rst Doc/library/exceptions.rst Doc/reference/expressions.rst Doc/reference/simple_stmts.rst Doc/whatsnew/3. description: Implement PEP 380 - 'yield from' (closes #11682) --- (The exact line changed and the line was moved, but O format didn't change.) Still no unit test, I'm too tired to write one, and I'm not sure that it's a bug in ceval.c. -- nosy: +ncoghlan Added file: http://bugs.python.org/file34813/ceval.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
Gene Wood added the comment:
One workaround to this is described here :
http://stackoverflow.com/a/4999510/168874
It involves prefixing all of the elements with the namespace like this :
from xml.etree import ElementTree as ET
# build a tree structure
root = ET.Element({http://www.company.com}STUFF;)
body = ET.SubElement(root, {http://www.company.com}MORE_STUFF;)
body.text = STUFF EVERYWHERE!
# wrap it in an ElementTree instance, and save as XML
tree = ET.ElementTree(root)
tree.write(page.xml,
xml_declaration=True,encoding='utf-8',
method=xml,default_namespace='http://www.company.com')
--
nosy: +gene_wood
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17088
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
Guido van Rossum added the comment: Wow. So many fixes! :-) Are you going to be at the CPython sprint tomorrow? I'll be there in the morning but my plane leaves in the afternoon. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
STINNER Victor added the comment: Are you going to be at the CPython sprint tomorrow? I'll be there in the morning but my plane leaves in the afternoon. I organize a Port OpenStack to Python3 sprint, but I may come also to the CPython sprint. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
Roundup Robot added the comment: New changeset 05b3a23b3836 by Benjamin Peterson in branch '3.4': fix sending tuples to custom generator objects with yield from (closes #21209) http://hg.python.org/cpython/rev/05b3a23b3836 New changeset d1eba2645b80 by Benjamin Peterson in branch 'default': merge 3.4 (#21209) http://hg.python.org/cpython/rev/d1eba2645b80 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21209] q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
Yury Selivanov added the comment: Hm... Can we also commit this to 3.3? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21209 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21191] os.fdopen() may eat file descriptor and still raise exception
Benjamin Peterson added the comment: Feel free to submit a patch. On Fri, Apr 11, 2014, at 2:40, Dima Tisnek wrote: Dima Tisnek added the comment: I think consistency between Python versions is just as important as consistency between fd types. Here's my hack quickfix outline: fd = os.open(...) try: if not stat.S_ISREG(os.fstat(fd).st_mode): raise OSError(None, Not a regular file, ...) f = os.fdopen(fd, ...) except EnvironmentError: os.close(fd) Can something like this be implemented in os.py There's already a check `if not isinstance(fd, int): raise ...` Granted we'd have to get fd type check exactly right. Well, you just have check exactly what it's checking now, which seems to be !S_ISDIR. fdopen should probably succeed for regular files, pipes, char devices, block device, ptry's ... fdopen should fail where underlying implementation fails, i.e. directories, sockets(?), epoll(?), timerfd(?) There's a list at http://en.wikipedia.org/wiki/File_descriptor I'm not sure about some types. P.S. I wish there was a way to rescue fd from FILE*, but nothing like that seems to exist... Yes, this is one of the main problems. P.P.S. another option is to always use dup(), but that may break existing programs is they expect fd == fdopen(fd).fileno() -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21191 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
