[issue15527] Double parens in functions references
Georg Brandl added the comment: Is anyone even reading my messages...? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Georg Brandl added the comment: Deferring. -- priority: release blocker - deferred blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
New submission from Martin v. Löwis: PEP 3118 specifies that the 'c'format denotes UCS-1 characters, yet .tolist() converts the memoryview into a list of bytes objects. This is incorrect; it ought to be a list of string objects (as it should for 'u' and 'w' codes). The same holds for item access. -- messages: 167937 nosy: loewis, skrah priority: normal severity: normal status: open title: memoryview.to_list() incorrect for 'c' format versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
Martin v. Löwis added the comment:
To reproduce:
memoryview(array.array('B',b'foo')).cast('c').tolist()
[b'f', b'o', b'o']
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15622
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15527] Double parens in functions references
Serhiy Storchaka added the comment: Georg, I see that :meth: with arguments works in the form :meth:`name(args) module.class.name`. I believe that the hyperlinks are helpful and it was designed that way. Replacing :meth:/:func:/:c:func: for names with arguments on double backquotes can be done almost automatically. Here's another patch (I like it less). -- Added file: http://bugs.python.org/file26763/doc_dbl_parens_drop_markup.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
Stefan Krah added the comment: You have rejected the PEP-3118 'u' and 'w' specifiers here: http://mail.python.org/pipermail/python-dev/2012-March/117390.html Otherwise, memoryview follows the existing struct module syntax: http://docs.python.org/dev/library/struct.html#format-characters I hope it did not escape you that _testbuffer.c *uses* the struct module to verify the correctness of memoryview. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Changes by Stefan Krah stefan-use...@bytereef.org: -- title: memoryview.to_list() incorrect for 'c' format - struct module 'c' specifier does not follow PEP-3118 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15620] readline.clear_history() missing in test_readline.py
Roundup Robot added the comment: New changeset 961a15aff2a6 by Georg Brandl in branch '3.2': Closes #15620: check for presence of readline.clear_history(), which is apparently missing on some readline versions, before calling it in the test. http://hg.python.org/cpython/rev/961a15aff2a6 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15620] readline.clear_history() missing in test_readline.py
Roundup Robot added the comment: New changeset dda08ec9fbd5 by Georg Brandl in branch '2.7': Graft a89d654adaa2 from 3.2 branch. Fixes #15620. http://hg.python.org/cpython/rev/dda08ec9fbd5 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15239] Abandoned Tools/unicode/mkstringprep.py
Changes by Georg Brandl ge...@python.org: -- versions: +Python 3.4 -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Martin v. Löwis added the comment: No, I haven't rejected the format codes. What I did ask to revert is that 'u' in the array module denotes Py_UCS4, I requested that it should continue to be compatible with 3.2. I didn't have an opinion on memoryview at all then. It's unfortunate that PEP 3118 deviates from the struct module, however, memoryview is based onthe buffer interface,and its formatcodes ought to conform to the PEP, not to the struct module (IMO). It's easy to see that it *doesn't* follow the struct syntax, as it is possjible to create memoryview objects with other format codes in 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
Martin v. Löwis added the comment: That the struct module hasn't been updated to support the PEP 3118 is already reported as issue 3132, please don't confuse the issues. This issue is about memoryview. One solution would be to revert the PEPs decision that 'c' is UCS-1. -- title: struct module 'c' specifier does not follow PEP-3118 - memoryview.to_list() incorrect for 'c' format ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
Antoine Pitrou added the comment: I don't know which behaviour is more desirable, but I would consider PEP 3118 a historical document more than a normative spec. Especially when it comes to struct format codes. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment: Stefan's proposed definition is correct. Shapes define array types, format strings define entry types, then the actual memory contents define the value. It's not Stefan's definition of equivalence, it's what a statically typed array *means*. The 3.2 way is completely broken, as it considers arrays containing completely different data as equal if the memory layout happens to be the same by coincidence. 3.3 is currently also broken, as it considers arrays that *do* contain the same values to be different. Stefan's patch fixes that by checking the shape and format first, and *then* checking the value. It's exactly the same as doing an instance check in an __eq__ method. The requirement for a canonical format is for sanity's sake: the general equivalence classes are too hard to figure out. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Martin v. Löwis added the comment: Is there anything that still needs to be done on this issue? ISTM that the code is correct as it stands (i.e. Getting a buffer now only uses valid format codes) -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Stefan Krah added the comment: Martin v. L??wis rep...@bugs.python.org wrote: It's unfortunate that PEP 3118 deviates from the struct module, however, memoryview is based onthe buffer interface,and its formatcodes ought to conform to the PEP, not to the struct module (IMO). The struct module itself should conform to PEP-3118, see #3132. I think the struct module should be updated first. The proliferation of subtly different format codes is not manageable. For example, if you use NumPy, there are already differences between NumPy syntax and struct syntax. Also, one should always be able to unpack the tobytes() representation using the struct module and get the same result as from flatten(tolist()). It's easy to see that it *doesn't* follow the struct syntax, as it is possjible to create memoryview objects with other format codes in 3.3. memoryview has *always* allowed arbitrary format strings during construction. In 3.3, it keeps this property for backwards compatibility. It does follow struct syntax whenever it *uses* one of the format codes, like in tolist(). -- title: memoryview.to_list() incorrect for 'c' format - struct module 'c' specifier does not follow PEP-3118 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15239] Abandoned Tools/unicode/mkstringprep.py
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
Stefan Krah added the comment: Martin v. L??wis rep...@bugs.python.org wrote: That the struct module hasn't been updated to support the PEP 3118 is already reported as issue 3132, please don't confuse the issues. This issue is about memoryview. No, it isn't. It was always planned to use struct to do the unpacking for memoryview, see msg71338. On a meta note, I'd appreciate if you were less liberal with words like confusing, especially if you are just beginning to work on an issue that other people have already spent a lot of time on. -- title: struct module 'c' specifier does not follow PEP-3118 - memoryview.to_list() incorrect for 'c' format ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Changes by Stefan Krah stefan-use...@bytereef.org: -- dependencies: +implement PEP 3118 struct changes title: memoryview.to_list() incorrect for 'c' format - struct module 'c' specifier does not follow PEP-3118 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
Antoine Pitrou added the comment:
Victor, your benchmark is buggy (it writes one character at a time). You should
apply the following patch:
$ diff -u bench_stringio_orig.py bench_stringio.py
--- bench_stringio_orig.py 2012-08-11 12:02:16.528321958 +0200
+++ bench_stringio.py 2012-08-11 12:05:53.939536902 +0200
@@ -41,8 +41,8 @@
('bmp', '\u20ac' * k + '\n'),
('non-bmp', '\U0010' * k + '\n'),
):
-bench.bench_func('writer long lines %s' % charset, writer, n // k,
text)
-bench.bench_func('writer-reader long lines %s' % charset,
writer_reader, n // k, text)
+bench.bench_func('writer long lines %s' % charset, writer, n, [text])
+bench.bench_func('writer-reader long lines %s' % charset,
writer_reader, n, [text])
for charset, text in (
('ascii', 'a' * (n // 10) + '\n'),
@@ -50,8 +50,8 @@
('bmp', '\u20ac' * (n // 10) + '\n'),
('non-bmp', '\U0010' * (n // 10) + '\n'),
):
-bench.bench_func('writer very long lines %s' % charset, writer, 10,
text)
-bench.bench_func('writer-reader very long lines %s' % charset,
writer_reader, 10, text)
+bench.bench_func('writer very long lines %s' % charset, writer, 100,
[text])
+bench.bench_func('writer-reader very long lines %s' % charset,
writer_reader, 100, [text])
data = 'abc\n' * n
bench.bench_func('reader ascii', reader, data)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15612
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Martin v. Löwis added the comment: Do you agree or not agree that memoryview.tolist should return a list of str objects for the c code? If you agree, can you please change the title back? If you disagree, please explain why, change the title back, and close the issue as rejected. If you agree, but think that struct should be changed first, create a new issue for the struct change, make that a dependency of this issue, and change the title back. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15528] Better support for finalization with weakrefs
Antoine Pitrou added the comment: In the latest patch, what are broken and priority for? Also, I would question why atexit is false by default. I would find it personally less surprising to be true. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
patrick vrijlandt added the comment: I would not know how to set the MIME-type of a file during upload. This is apparently set by the browser based on the filename (extension). Even (or: especially) if this is a bug in all the current browsers, python should provide the tools to adapt to this situation. I could perhaps request the whole form to be application/octet-stream, but the current multipart/form-data is appropriate for a form. You are right about renaming. The innocent test file test2.txt can be uploaded, but the same file renamed to test2.mht causes an exception. Below is a dump of the posted data (using Chrome in this case); attached a script (requiring bottle.py - www.bottlepy.org or PyPI) that demonstrates the problem. There is no doubt that parsing fails; an exception cannot be the result of successful parsing. The input may be wrong, but python should offer the flexibility to handle wrong input. Instead, are you sure it is appropriate to *automatically* dissect a file? It should be fairly easy to handle for the scripter if he really wants to dig deeper. Headers Origin: http://localhost:10080 Referer: http://localhost:10080/url-get Content-Length: 349 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cache-Control: max-age=0 Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.75 Safari/537.1 Host: localhost:10080 Accept-Encoding: gzip,deflate,sdch Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4,en-GB;q=0.2 Content-Type: multipart/form-data; boundary=WebKitFormBoundaryBsBVBYDTxou89uBj Body --WebKitFormBoundaryBsBVBYDTxou89uBj Content-Disposition: form-data; name=data; filename=test2.mht Content-Type: multipart/related # dit is een test Dit is een regel Dit is het einde. # --WebKitFormBoundaryBsBVBYDTxou89uBj Content-Disposition: form-data; name=value abc123 --WebKitFormBoundaryBsBVBYDTxou89uBj-- -- Added file: http://bugs.python.org/file26764/cgibug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15444] Incorrectly written contributor's names
Antoine Pitrou added the comment: The patch looks ok to me so, unless someone is opposed to using utf-8 in the doc files, I think it can be committed in 3.x. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files
Brett Cannon added the comment: So that test case is hard for me to follow since I don't know what a .srctree file is and the file seems to have some magical comments in it. If my assumptions are correct you are generating a C file that does a relative import in the extension module's init function? Has that actually worked in the past? The error you are seeing suggests that the module is not being inserted into sys.modules before executing the body which I have no control over since that's the purview of imp.load_dynamic(). If you skip the relative imports does the import work otherwise? -- resolution: fixed - stage: committed/rejected - test needed status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files
Brett Cannon added the comment: The reason I ask this is that if I simply move e.g. audioop.so to audioop/__init__.so everything works fine in terms of being able to import that module as a package. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Nick Coghlan added the comment: Whatever the struct module produces for a format code is the same thing that memoryview.to_list() should produce. PEP 3118 contains way too many errors (as has been found out the hard way) to be considered a normative document. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?)
Jordi Puigsegur added the comment: It looks like the change from old to new style classes in python could have triggered this issue. I've created an issue in PyYaml (http://pyyaml.org/ticket/283). Thanks again! -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15616 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15600] expose the finder details used by the FileFinder path hook
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15600 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files
Stefan Behnel added the comment: Hmm, yes, sounds more like a separate issue than something to add to this ticket. It worked before (starting with Py2.5, which was the first Python version to support relative imports) and only stopped working in 3.3 now. The .srctree test file basically just unfolds into a file system hierarchy with each file named as in the preceding magical comment. The commands in the lines before the first comment line are then executed for the test (usually: build module with distutils, import it, do something with it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Nick Coghlan added the comment: Closing with rationale, as Martin requested The struct module documentation takes precedence over PEP 3118 when it comes to pre-existing format codes, as changing struct is not feasible due to backwards compatibility concerns, and we don't want two conflicting notations for binary format descriptions. PEP 3118 was intended only to define *additional* format characters, which may or may not yet be understood by the struct module. As 'c' is defined by the struct module as returning a bytes object of length one, this is the same interpretation used by memoryview. Thus the current behaviour of both memoryview and struct are considered correct, while it is PEP 3118 that is incorrect in this case: the 'c' entry should not have been in the table, as 'c' was already defined at least as long ago as 1.5.2 (returning an 8-bit string, which then became a bytes object in 3.x). The PEP was also written in a 2.x context (note the mention of 2.5 above the table of new format codes), where the idea of providing a separate code that implicitly performed x.decode(latin-1) to produce a unicode object instead of an 8-bit string object wouldn't necessarily come up. -- dependencies: -implement PEP 3118 struct changes resolution: - invalid stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15444] Incorrectly written contributor's names
Serhiy Storchaka added the comment:
Non-ascii characters already used in a lot (43-50) of doc files.
LC_ALL=C find Doc/ -type f -name '*.rst' -exec egrep --color $(printf
'[\x80-\xFF]+') '{}' +
All touched files already contains non-ascii characters (and Misc/HISTORY
contains invalid UTF-8 sequence).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15444
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Nick Coghlan added the comment:
Following up here after rejecting #15622 as invalid
The unicode codes in PEP 3118 need to be seriously rethought before any
related changes are made in the struct module.
1. The 'c' and 's' codes are currently used for raw bytes data (represented as
bytes objects at the Python layer). This means the 'c' code cannot be used as
described in PEP 3118 in a world with strict binary/text separation.
2. Any format codes for UCS1, UCS2 and UCS4 are more usefully modelled on 's'
than they are on 'c' (so that repeat counts create longer strings rather than
lists of strings that each contain a single code point)
3. Given some of the other proposals in PEP 3118, it seems more useful to
define an embedded text format as S{encoding}.
UCS1 would then be S{latin-1}, UCS2 would be approximated as S{utf-16} and
UCS4 would be S{utf-32} and arbitrary encodings would also be supported.
struct packing would implicitly encode from text to bytes while unpacking would
implicitly decode bytes to text. As with 's' a length mismatch in the encoded
form would mean an error.
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15444] Incorrectly written contributor's names
Roundup Robot added the comment: New changeset 3654c711019a by Antoine Pitrou in branch '3.2': Issue #15444: Use proper spelling for non-ASCII contributor names. http://hg.python.org/cpython/rev/3654c711019a New changeset 867de88b69f0 by Antoine Pitrou in branch 'default': Issue #15444: Use proper spelling for non-ASCII contributor names. http://hg.python.org/cpython/rev/867de88b69f0 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15444] Incorrectly written contributor's names
Antoine Pitrou added the comment: Ok, then I've committed the patch. Closing the issue now, thank you. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15615] More tests for JSON decoder to test Exceptions
Antoine Pitrou added the comment: Hi and thank you. The patch looks fine to me. Could you sign a contributor's agreement: http://www.python.org/psf/contrib/ ? -- nosy: +ezio.melotti, pitrou versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15623] Init time relative imports no longer work from __init__.so modules
New submission from Stefan Behnel: Since CPython 2.5, relative imports could be used from __init__.so package modules. This stopped working in CPython 3.3. This is a follow-up ticket to issue15576. This feature is exercised by Cython's initial_file_path test, which now gives this result: Traceback (most recent call last): File string, line 1, in module File __init__.py, line 8, in init my_test_package (my_test_package/__init__.c:1032) SystemError: Parent module 'my_test_package' not loaded, cannot perform relative import It is meant to check that Cython provides a fake __path__ for the package module for the init function (as long as issue13429 isn't resolved). With that, relative imports worked before. The test code is here, failing in line 21 (each section is a separate file), when it tries to do a relative import at the module level, i.e. at module init time. https://github.com/cython/cython/blob/master/tests/run/initial_file_path.srctree I'm running the test like this: python3 runtests.py --no-cpp --no-pyregr --no-unit --debug -vv initial_file_path I also tried printing sys.modules and the package really isn't registered there yet at the time of the import. -- components: Interpreter Core messages: 167967 nosy: scoder priority: normal severity: normal status: open title: Init time relative imports no longer work from __init__.so modules type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15623 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files
Stefan Behnel added the comment: I've created issue15623, so that we can keep this one as fixed. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Nick Coghlan added the comment: However, based on this issue, I have added some comments to #3132 (I think PEP 3118's simplistic approach to embedded text data is broken and a bad idea) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Changes by Nick Coghlan ncogh...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15623] Init time relative imports no longer work from __init__.so modules
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15623 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Chris Jerdonek added the comment: Closing with rationale, as Martin requested Status was still open. Was that a tracker bug? -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
Antoine Pitrou added the comment:
I wonder how other systems respond to [...]
if all interfaces except for lo are down
On Mageia Linux 1:
socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0,
socket.AI_ADDRCONFIG)
Traceback (most recent call last):
File stdin, line 1, in module
socket.gaierror: [Errno -5] No address associated with hostname
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15617
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0
Antoine Pitrou added the comment: No luck there: The tests pass unmodified (100 times with the -F option). You could try -F -j16 or something similar. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Nick Coghlan added the comment: Pretty sure it was just an error on my part. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
STINNER Victor added the comment: Victor, your benchmark is buggy (it writes one character at a time). Oh, it's not what I wanted to test. I attach a new benchmark. Here are the results. PyAccu looks much more appropriate than _PyUnicodeWriter, because it is always faster, except to write 100.000 very long lines. Common platform: CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz CFLAGS: -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Bits: int=32, long=64, long long=64, pointer=64 Python unicode implementation: PEP 393 Platform: Linux-3.4.4-4.fc16.x86_64-x86_64-with-fedora-16-Verne Platform of campaign pyaccu: SCM: hg revision=9804aec74d4a tag=tip branch=default date=2012-08-10 18:55 -0400 Date: 2012-08-11 16:53:46 Python version: 3.3.0b1 (default:9804aec74d4a, Aug 11 2012, 16:53:12) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] Platform of campaign writer: SCM: hg revision=9804aec74d4a+ tag=tip branch=default date=2012-08-10 18:55 -0400 Date: 2012-08-11 16:50:40 Python version: 3.3.0b1 (default:9804aec74d4a+, Aug 11 2012, 16:33:18) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] --+-+--- 10 lines | pyaccu | writer --+-+--- reader short line ascii | 1.53 us (*) |1.46 us writer short line ascii | 4.85 us (*) | 4.48 us (-8%) writer-reader short line ascii| 6.45 us (*) | 5.71 us (-12%) reader short line latin1 | 1.57 us (*) | 1.45 us (-8%) writer short line latin1 | 4.92 us (*) | 4.56 us (-7%) writer-reader short line latin1 | 6.6 us (*) | 5.78 us (-13%) reader short line bmp | 1.64 us (*) | 1.54 us (-6%) writer short line bmp | 5.01 us (*) | 4.43 us (-12%) writer-reader short line bmp | 6.68 us (*) | 5.71 us (-14%) reader short line non-bmp | 1.61 us (*) |1.59 us writer short line non-bmp | 5.1 us (*) | 4.55 us (-11%) writer-reader short line non-bmp | 6.74 us (*) | 5.66 us (-16%) reader long lines ascii | 103 us (*) | 33.4 us (-68%) writer long lines ascii | 998 ns (*) | 836 ns (-16%) writer-reader long lines ascii| 1.45 us (*) | 1.18 us (-19%) reader long lines latin1 | 105 us (*) | 34.2 us (-67%) writer long lines latin1 | 997 ns (*) | 831 ns (-17%) writer-reader long lines latin1 | 1.47 us (*) | 1.2 us (-18%) reader long lines bmp | 121 us (*) | 85.9 us (-29%) writer long lines bmp | 995 ns (*) | 861 ns (-13%) writer-reader long lines bmp | 1.43 us (*) | 1.13 us (-21%) reader long lines non-bmp | 97.1 us (*) |99.7 us writer long lines non-bmp |1 us (*) | 819 ns (-18%) writer-reader long lines non-bmp | 1.4 us (*) | 1.18 us (-16%) reader very long lines ascii | 1.42 us (*) |1.45 us writer very long lines ascii | 3.04 us (*) | 2.88 us (-5%) writer-reader very long lines ascii | 4.59 us (*) | 4.12 us (-10%) reader very long lines latin1 | 1.57 us (*) | 1.47 us (-7%) writer very long lines latin1 | 3.04 us (*) | 2.73 us (-10%) writer-reader very long lines latin1 | 4.66 us (*) | 4.04 us (-13%) reader very long lines bmp| 1.55 us (*) |1.55 us writer very long lines bmp| 3.03 us (*) |2.91 us writer-reader very long lines bmp | 4.72 us (*) | 4.08 us (-14%) reader very long lines non-bmp| 1.55 us (*) |1.49 us writer very long lines non-bmp| 3.09 us (*) | 2.93 us (-5%) writer-reader very long lines non-bmp | 4.59 us (*) | 4.06 us (-12%) --+-+--- Total | 525 us (*) | 342 us (-35%) --+-+--- --+-+--- 1000 lines| pyaccu | writer --+-+--- reader short line ascii | 68.2 us (*) |66.1 us writer short line ascii | 308 us (*) | 307 us writer-reader short line ascii| 378 us (*) | 374 us reader short line latin1 | 72 us (*) |68.5 us writer short line latin1 | 324 us (*) | 313 us writer-reader short line latin1 | 395 us (*) | 383 us reader short line bmp | 74.8 us (*) |71.9 us writer short line bmp | 326 us (*) | 303 us (-7%) writer-reader short line bmp | 397 us (*) | 378 us reader short line non-bmp | 72.9 us (*) |72.6 us writer short line non-bmp | 329 us (*) | 304 us (-8%) writer-reader
[issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
STINNER Victor added the comment: PyAccu looks much more appropriate than _PyUnicodeWriter, because it is always faster, except to write 100.000 very long lines. Oh... I added colors to my tool, but there was a bug: I used the wrong colors... It's just the opposite. _PyUnicodeWriter is almost always faster, except to write more than 100.000 very long lines. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15561] update subprocess docs to reference io.TextIOWrapper
Andrew Svetlov added the comment: Hmm. As I can see in subprocess.py TextIOWrapper is applied to stdin also in non-buffered (write_through=True) mode. So input will be converted to use '\n' as well. Can you reflect this fact in your patches? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15557] Tests for webbrowser module
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15557 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
Antoine Pitrou added the comment: _PyUnicodeWriter is almost always faster Actually, PyAccu is consistently faster for the writer case, while _PyUnicodeWriter is faster for the writer-reader case. This is not because of PyAccu, but because of the way StringIO uses it: when e.g. readline() is called, the PyAccu result is converted into a PyUCS4* buffer, then each readline() result is converted again by finding the max char in the sub-buffer. So I would suggest using PyAccu, but converting its result to a _PyUnicodeWriter rather than a PyUCS4* buffer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
Serhiy Storchaka added the comment: See benchmark results in issue15381 (the patch is not applicable to StringIO). These numbers show that resize strategy can be much slower append/join strategy on Windows. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
Martin v. Löwis added the comment: Antoine: thanks for the report. I fear that this rules out using AI_ADDRCONFIG: IETF has managed to break it. This is really silly. So I'm tempted to close this as won't fix. Comments? Build slaves would be required that a regular lookup of localhost matches the configured loopback addresses (which I feel is a reasonable operational requirement anyway). Floris: another work around is to configure ::1 in your zone. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15617 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Martin v. Löwis added the comment: Nick: that's a reasonable view, thanks - in particular the point that PEP 3118 should not be considered normative. I still think that the c code in struct is fairly redundant (with B) as it stands, so I think it should get deprecated and removed - but that's a different issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment:
Nick: I still disagree. Would you agree that array.array constitutes a
statically typed array? Yet
py array.array('b',b'foo') == array.array('B',b'foo')
True
py array.array('i',[1,2,3]) == array.array('L', [1,2,3])
True
So the array object (rightfully) performs comparison on abstract values, not on
memory representation. In Python, a statically typed array still conceptually
contains abstract values, not memory blocks (this is also what Stefan asserts
for NumPy in msg167862). The static typing only restricts the values you can
store in the container, and defines the internal representation on the C level
(plus it typically implies a value storage, instead of a reference storage).
With your and Stefan's proposed semantics, we would get the weird case that for
two array.arrays a and b, it might happen that
a == b and memoryview(a) != memoryview(b)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15573
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment: it might *still* happen, I should say, since this problem is exactly what Victor says this issue intends to solve (for comparison of two 'u' arrays). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15557] Tests for webbrowser module
Chris Jerdonek added the comment: It seems like these tests can be made more DRY. For example, the line `args = popen.cmd_line` appears in every test. You could make an assert_args() helper method to address this. There also seems to be a lot of overlap between tests for each browser. A DRY approach would let one see more easily how the tests differ across browsers. Do you also need to include the test boilerplate at the bottom? See, for example-- http://hg.python.org/cpython/file/867de88b69f0/Lib/test/test_textwrap.py#l732 -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15557 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Stefan Krah added the comment:
So we have two competing proposals:
1) Py_buffers are strongly typed arrays in the ML sense (e.g. array of float,
array of int).
This is probably what I'd prefer on the C level, imagine a function like
function like PyBuffer_Compare(v, w).
Backwards compatibility problem for users who were thinking in terms of
value comparisons:
x = array.array('b', [127])
y = array.array('B', [127])
x == y
True
memoryview(x) == memoryview(y)
False
2) Compare by value, like NumPy arrays do:
x = numpy.array([1, 2, 3], dtype='i')
y = numpy.array([1, 2, 3], dtype='f')
x == y
array([True, True, True], dtype=bool)
I concede that this is probably what users want to see on the Python level.
Backwards compatibility problem for users who were using complicated
structs:
from _testbuffer import *
x = ndarray([(1,1), (2,2), (3,3)], shape=[3], format='hQ')
x == memoryview(x)
False
Reason: While _testbuffer.ndarray already implements tolist() in full
generality, memoryview does not:
x.tolist()
[(1, 1), (2, 2), (3, 3)]
memoryview(x).tolist()
Traceback (most recent call last):
File stdin, line 1, in module
NotImplementedError: memoryview: unsupported format hQ
So while I'm beginning to like Martin's proposal, the implementation is
certainly trickier and will always be quite slow for complicated format
strings.
It would be possible to keep a fast path for the primitive C types
and use the code from _testbuffer.tolist() for the slow cases.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15573
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15527] Double parens in functions references
Roundup Robot added the comment: New changeset 5e025dc7d728 by Andrew Svetlov in branch 'default': Issue #15527: fix docs, remove double parens by changing markup. http://hg.python.org/cpython/rev/5e025dc7d728 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15527] Double parens in functions references
Andrew Svetlov added the comment: Applied patch uses ``expr(n)`` as Georg prefer. Serhiy, please close the issue if you have not any upcoming patches. Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment: Here is a patch doing the comparison on abstract values if the formats are different. -- Added file: http://bugs.python.org/file26766/abstractcmp.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15527] Double parens in functions references
Serhiy Storchaka added the comment: Thank you Andrew. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0
Stefan Krah added the comment:
With -F -j16 I get these failures both on FreeBSD and Linux, but not
the original failure:
==
FAIL: test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests)
--
Traceback (most recent call last):
File /home/stefan/hg/cpython/Lib/test/test_threaded_import.py, line 131, in
test_parallel_meta_path
self.check_parallel_module_init()
File /home/stefan/hg/cpython/Lib/test/test_threaded_import.py, line 120, in
check_parallel_module_init
self.assertFalse(errors)
AssertionError: [AttributeError('module' object has no attribute
'randrange',)] is not false
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15599
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment:
OK, I think I finally understand what Martin is getting at from a semantic
point of view, and I think I can better explain the background of the issue and
why Stefan's proposed solution is both necessary and correct.
The ideal definition of equivalence for memory view objects would actually be:
memoryview(x) == memoryview(y)
if (and only if)
memoryview(x).tolist() == memoryview(y).tolist()
Now, in practice, this approach cannot be implemented, because there are too
many format definitions (whether valid or invalid) that memoryview doesn't
understand (and perhaps will never understand) and because it would be
completely infeasible on large arrays with complex format definitions.
Thus, we are forced to accept a *constraint* on memoryview's definition of
equality: individual values are always compared via raw memory comparison, thus
values stored using different *sizes* or *layouts* in memory will always
compare as unequal, even if they would compare as equal in Python
This is an *acceptable* constraint as, in practice, you don't perform mixed
format arithmetic and it's not a problem if there's no automatic coercion
between sizes and layouts.
The Python 3.2 memoryview effectively uses memcmp() directly treating
everything as a 1D array of bytes data, completely ignoring both shape *and*
format data. Thus:
ab = array('b', [1, 2, 3])
ai = array('i', [1, 2, 3])
aL = array('L', [1, 2, 3])
ab == ai
True
ab == ai == aL
True
memoryview(ab) == memoryview(ai)
False
memoryview(ab) == memoryview(aL)
False
memoryview(ai) == memoryview(aL)
False
This approach leads to some major false positives, such as a floating point
value comparing equal to an integer that happens to share the same binary
representation:
af = array('f', [1.1])
ai = array('i', [1066192077])
af == ai
False
memoryview(af) == memoryview(ai)
True
The changes in 3.3 are aimed primarily at *eliminating those false positives*
by taking into account the shape of the array and the format of the contained
values. It is *not* about changing the fundamental constraint that memoryview
operates at the level of raw memory, rather than Python objects, and thus cares
about memory layout details that are irrelevant after passing through the
Python abstraction layer.
This contrasts with the more limited scope of the array.array module, which
*does* take into account the Python level abstractions. Thus, there will always
be a discrepancy between the two definitions of equality, as memoryview cares
about memory layout details, where array.array does not.
The problem at the moment is that Python 3.3 currently has *spurious* false
negatives that aren't caused by that fundamental constraint that comparisons
must occur based directly on memory contents. Instead, they're being caused by
memoryview returning False for any equality comparison for a format it doesn't
understand. That's unacceptable, and is what Stefan's patch is intended to fix.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15573
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment: Short version: 3.3 implemented new constraints on memoryview equality comparisons to eliminate cases that were incorrectly returning True when they should have returned False. However, the format constraints are currently too restrictive, so some memoryview comparisons that correctly returned True in 3.2 are now also returning False. This patch fixes *those* comparisons to once again return True. Moving back to deferred blocked status, since the spurious false negatives are a regression from 3.2. It's fine for beta2 to ship with this problem, but it needs to be fixed for rc1. -- priority: high - deferred blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15561] update subprocess docs to reference io.TextIOWrapper
Chris Jerdonek added the comment: Can you reflect this fact in your patches? Sure. (Though for stdin '\n' is converted to os.linesep and no more.) Would you mind if I also updated the following part of the subprocess documentation to reference the part we are updating, so that the documentation is just in one place? If universal_newlines is True, the file objects stdout and stderr are opened as text files, but lines may be terminated by any of '\n', the Unix end-of-line convention, '\r', the old Macintosh convention or '\r\n', the Windows convention. All of these external representations are seen as '\n' by the Python program. The part we're updating is in the Frequently Used Arguments section and so seems like the natural place for expanded details. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment: I can see value in adopting the abstraction approach, but it's not part of this issue. That problem already existed when using memoryview in 3.2, we can wait until 3.4 to fix it. There's an actual, concrete regression in 3.3 that may break code, and comparing with memcmp() when the format strings match is enough to fix it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment: And, to be honest, I'd be quite happy for congratulations, you have reached the threshold where you need NumPy rather than memoryview to be the long term answer to getting by value comparison semantics. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15624] clarify io.TextIOWrapper newline documentation
New submission from Chris Jerdonek: The documentation of io.TextIOWrapper's newline argument is somewhat confusing and perhaps reversed from what was intended. (For example, the subprocess module uses the reverse terminology.) Either way, it can be improved somewhat. Currently, it says-- * On input, if newline is None,... Lines in the input can end in '\n', '\r', or '\r\n', and these are translated into '\n' before being returned to the caller... * On output, if newline is None, any '\n' characters written are translated to the system default line separator, os.linesep... (from http://docs.python.org/dev/library/io.html#io.TextIOWrapper ) It is somewhat confusing because On input does not mean On input to the buffer, and On output does not mean On output from the buffer. It is the reverse. A minimal change to address this would be something along the lines of-- On input - When reading input from the buffer On output - When writing output to the buffer The same change could also be made to the open() documentation: http://docs.python.org/dev/library/functions.html#open I can prepare a patch for affected versions. -- assignee: docs@python components: Documentation keywords: easy messages: 167995 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: clarify io.TextIOWrapper newline documentation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15624 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15624] clarify io.TextIOWrapper newline documentation
Chris Jerdonek added the comment: Andrew, I'm adding you because this is the documentation that the subprocess module will point to after issue 15561. -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15624 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Nick Coghlan added the comment: There's still work to be done. The current status in 3.3 trunk is that: Wide build: memoryview(array(u)).format 'w' Narrow build: memoryview(array(u)).format 'u' Neither of these are valid struct formats, thus they don't play nicely with the assumptions of memoryview (or any other PEP 3118 consumer). Stefan's memoryview changes are needed because there are *valid* struct formats that memoryview doesn't understand (yet), but it's only coincidental that they will reduce the severity of this problem. Victor's latest patch switches the 'w' and 'u' for the appropriate integer sizes 'I' and 'H' which I think is an excellent approach. There are also the post-reversion documentation changes Georg requested to bring the docs back into line with PEP 393 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15528] Better support for finalization with weakrefs
Richard Oudkerk added the comment: In the latest patch, what are broken and priority for? They are for a subclass used by multiprocessing. But it is premature to worry about subclassing, so I will take them out. Also, I would question why atexit is false by default. I would find it personally less surprising to be true. OK. One thing I do worry about is having the loop in the exit function to run any finalizers created during the exit function. The current implementation will run these extra finalizers at the wrong time. Fixing this could probably be done by using a dirty flag and disabling gc while running the finalizers. I wonder if it would be better to not call finalizers created during the exit function. We cannot guarantee that every finalizer created during shutdown is run, so is a best effort attempt really worth the effort? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15606] re.VERBOSE whitespace behavior not completely documented
Steven Collins added the comment: Fair enough, but in that case I still think the current behavior should be documented. Attached is a possible patch. (This is my first interaction with the Python issue tracker, by the way; apologies if I ought to have set some field differently or left some other field alone.) -- assignee: - docs@python components: +Documentation keywords: +patch nosy: +docs@python title: re.VERBOSE doesn't ignore certain whitespace - re.VERBOSE whitespace behavior not completely documented type: behavior - enhancement versions: +Python 3.3 -Python 2.7, Python 3.2 Added file: http://bugs.python.org/file26767/re_whitespace.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15606 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment: However, the format constraints are currently too restrictive, so some memoryview comparisons that correctly returned True in 3.2 are now also returning False. This patch fixes *those* comparisons to once again return True. No, it doesn't - at least not in all cases. If you compare 'b' and 'B' arrays with values in range(128), then 3.2 rightfully returned True, but will still return False under the patch. In any case, whatever the solution is (or even whatever the problem is), it needs to be clearly spelled out in the documentation, since it will be far from obvious. Instead, they're being caused by memoryview returning False for any equality comparison for a format it doesn't understand. That's unacceptable, and is what Stefan's patch is intended to fix. I fail to see why this is unacceptable. If you don't understand the format code, you cannot know how to compare the values - you cannot even know how to compare the memory representation of the values. If the memory compares unequal, it may still be plausible that the values are actually equal (e.g. if this is a numerator-denominator representation of rationals). There are even cases where the memory comparison can compare as equal, yet the values should compare non-equal (e.g. IEEE NaNs, or relative pointers). I also think this is a *really* obscure problem: not many people use memoryview objects, very few desire to compare them for equality (most rather use them for efficient IO, and poking into structures), and of those, nearly nobody uses them with unsupported format codes - in particular not if u and w get implemented (since then standard Python will not have ways to create memoryview objects reasonably with unsupported codes). What specific example did you think of that regresses from 3.2? So I still fail to see why this problem can manage to block the release of 3.3 - but that's for the release manager to decide. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15151] Documentation for Signature, Parameter and signature in inspect module
Andrew Svetlov added the comment: Slightly updated version -- Added file: http://bugs.python.org/file26768/inspect.pep362.5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15151 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment: And, to be honest, I'd be quite happy for congratulations, you have reached the threshold where you need NumPy rather than memoryview to be the long term answer to getting by value comparison semantics. IMO, this threshold is already reached when you start comparing memoryview objects. PEP 3118 apparently introduced it to replace the buffer obejct, and specified that it should have __getitem__ and __setitem__ as magic methods; the PEP doesn't talk about comparison at all. So I wonder where the desire to support comparison for equality comes from (but I can accept that we have to deal with it as it is there now). IMO, it would be reasonable to declare to memory buffers as unequal if they denote different memory blocks in main memory (i.e. at different addresses). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment: Hmm, you're right. OK, here's a simpler proposal for 3.3: 1. Always look at shape first. If they're different, then they're not equal 2. If both formats are known, compare by unpacked value 3. If either format is unknown, compare by memory contents (just like 3.2) The fallback case should then behave exactly like 3.2 (since 3.2 really couldn't handle anything other than 1D data and always ignored the format info). I'd be happier if the compare-by-value didn't make complete copies of the entire array though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Antoine Pitrou added the comment: Le samedi 11 août 2012 à 19:52 +, Nick Coghlan a écrit : I'd be happier if the compare-by-value didn't make complete copies of the entire array though. Ditto. If a and b are bytes objects, comparing memoryview(a) and memoryview(b) should be as cheap as comparing a and b. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Martin v. Löwis added the comment: Wide build: memoryview(array(u)).format 'w' Narrow build: memoryview(array(u)).format 'u' Neither of these are valid struct formats, thus they don't play nicely with the assumptions of memoryview (or any other PEP 3118 consumer). Why do you say that? They have been added by PEP 3118 (and are just not implemented in the struct module yet). If you think that their mentioning in PEP 3118 is a mistake, and they should not get implemented in struct, we should a) get consensus on that interpretation of the PEP, and b) actually remove them from the PEP, since otherwise it is very confusing that they keep being mentioned. I believe that the addition of these codes was fully intended by the PEP author, and also part of its acceptance. If these codes are indeed meant to be in the struct module, this usage in the array module looks right to me - hence my proposal to close the issue (the documentation problem aside). I agree that it is then desirable that the memoryview object supports the codes. However, this is separate issue from this one (as the codes are not invalid, just unsupported). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment: Am 11.08.12 21:59, schrieb Antoine Pitrou: Le samedi 11 août 2012 à 19:52 +, Nick Coghlan a écrit : I'd be happier if the compare-by-value didn't make complete copies of the entire array though. Ditto. If a and b are bytes objects, comparing memoryview(a) and memoryview(b) should be as cheap as comparing a and b. I agree with Antoine's requirement, generalizing it to the simple cases should be efficient. I wonder why the procedure couldn't instead be 1. compare shapes 2. if the format strings are string-equal, compare the memory representation 3. else unpack values Then, comparing two 1D 'B' memoryviews would be a memcmp (i.e. it wouldn't do compare-by-value in this case). For unpacking, I don't see any way to have it efficient and still maintainable, since mixed-type comparisons are quite tedious to write in C, and really best done with type normalization and multiple dispatch in the way that unpacking will do it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
Glenn Linderman added the comment: I didn't call the current behaviour of browsers in assigning MIME types automatically based on file extension a bug; I would consider it more of a missing capability, an oversight due to the rareness of attempts to upload MHTML files. This is similar to the situation of email clients automatically choosing the Content-Disposition for attachments (which is just a recommendation) about whether to suggest they be displayed inline, or provided as attachments to be saved. Most automatically select a Content-Disposition based on their own capability to deal with an attachment of a particular MIME type, rather than the (unknown) capability of the email client of the ultimate recipient. I think in both cases, the default behavior works well enough for a large enough subset of cases, that there has been little demand for increased functionality, even though one can contrive reasonable sounding cases for that functionality. As a point of discussion, my perception is that MHTML files have two uses: to email an image of a web page (something typically done implicitly by bundled email/web-browser client software, and not generally explicit in the creation of a standalone MHTML file), and to archive a web page for local reference. Neither of these uses involves upload MHTML files to web sites, although saving a web page, and then attempting to email it to a friend as an attachment via a web mail client might encounter the same difficulty you are having. Another use I have heard discussed (but I've forgotten where, so have no references), is as a source for custom browsers to prepackage responses for particular WEB forms. In that case, I think it would be the custom browser's responsibility to supply the MHTML file content as a response to the form request, rather than to supply it as an uploaded file, expecting the server to dissect it... I think it is obvious that my personal, first reaction is that the parsing problem should be fixed... if the MIME type states it is multipart, it should dissected into its parts... and if that is not the desired behavior, then the MIME type should be different. Email standards, the source of MIME type specifications, certainly use and support nested multipart dissection, although various email software performs it in various manners and to various levels. Naturally, if the content syntax of the multipart file is incorrect, it should produce an exception, the same as if the multipart content a (buggy) browser produced from an HTML form were syntactically incorrect. Given a lack of capability of browser to allow specification of MIME type (this is .mht, but treat it as application/octet-stream rather than multipart/related), it does seem that web server toolkits such as cgi.FieldStorage might want to offer an option or hook to allow an application to disable the otherwise automatic parsing of multipart/* files. This is a rather murky area, indeed. Research into whether and how other web toolkits handle such a situation would be interesting in deciding how to proceed. While there is no need for Python to slavishly follow the lead of any other particular web toolkit, it would be interesting to know if any actually successfully parse such files, and it would be interesting to know if any ignore the MIME type for uploaded files, and it would be interesting to know if any support options for handling uploaded files with multipart/* MIME types. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15615] More tests for JSON decoder to test Exceptions
Kushal Das added the comment: Contributor's agreement signed and sent to the given email address. Thanks for the input. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15593] urlparse.parse_qs documentation wrong re: urlencode
Changes by Senthil Kumaran sent...@uthcode.com: -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15625] Support u and w codes in memoryview
New submission from Martin v. Löwis:
Currently, the following test case fails:
import array
a=array.array('u', 'foo')
memoryview(a)==memoryview(a)
False
This is because the memoryview object doesn't support the u and w codes, as it
should per PEP 3118. This patch fixes it.
--
files: uwcodes.diff
keywords: patch
messages: 168009
nosy: loewis, ncoghlan, skrah
priority: normal
severity: normal
status: open
title: Support u and w codes in memoryview
Added file: http://bugs.python.org/file26769/uwcodes.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15625
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15625] Support u and w codes in memoryview
Changes by Martin v. Löwis mar...@v.loewis.de: -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15625 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment: Here is a more formal definition of my last proposal, v and w are equal iff v.shape() == w.shape() and ((v.format == w.format and v.tobytes() == w.tobytes()) or v.tolist() == w.tolist()) if tolist raises an exception for unsupported codes, they are not equal As usual, the implementation can deviate from the spec as long as it behaves as-if it would use this exact algorithm (assuming unlimited memory). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15611] devguide: add core mentors area to Experts Index
Chris Jerdonek added the comment: Here is an initial patch based on the core developers who responded on core-mentorship. In response to Ezio's comment (after thinking further), I think the goal would be to provide a list of people that new contributors should feel welcome to add to the nosy list in interest areas that are not otherwise covered (or perhaps on any issue they would like advice on?). Reasons for limiting this to new contributors and core mentors are (1) to prevent the core developers listed from being added to the nosy list for *every* issue that falls into an area not covered, and (2) in recognition that new contributors benefit from the mentorship and welcome that core mentors are especially interested in providing. I see that the core mentorship label does not fully capture this, but I'm open to other suggestions (e.g. choosing a different label, adding a footnote, or adding another section). Having this be part of the Experts Index simplifies things like populating the tracker pull-down. -- keywords: +patch nosy: +brett.cannon, r.david.murray Added file: http://bugs.python.org/file26770/issue-15611-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15623] Init time relative imports no longer work from __init__.so modules
Brett Cannon added the comment: The trigger of that exception is importlib._bootstrap._sanity_check() (http://hg.python.org/cpython/file/5e025dc7d728/Lib/importlib/_bootstrap.py#l1466). It's called very early on to verify certain things, including that the parent package is already loaded when importing a submodule. It's that last bit that's failing. If you look at 3.2 vs. 3.3 for imp.load_dynamic() which does extension module loading for importlib, there is essentially no change, even as far as looking into Python/importdl.c:_PyImport_LoadDynamicModule() (http://hg.python.org/cpython/file/5e025dc7d728/Python/import.c#l1773 vs. http://hg.python.org/cpython/file/3654c711019a/Python/import.c#l3446). The problem is that the check for the parent module is also in Python/import.c from 3.2 so this isn't a new check. Is it possible that Cython is doing something differently now that it didn't do before? I know you said this worked in 3.2 and earlier, Stefan, but was that with the same version of Cython? Did the actual C call and setup for that call change? Otherwise I can't think of how anything specifically changed between 3.2 and 3.3 that would fundamentally change this. -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15623 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15626] unittest.main negates -bb option and programmatic warning configuration
New submission from Ben Darnell: In python 3.2, unittest.main by default modifies the warning configuration if no -W options were given on the command line. This undoes the effect of -bb, turning BytesWarning back into a warning instead of an error. If both -bb and -Werror::BytesWarning are given, then unittest does not tamper with the warning configuration and byte operations raise errors as expected (but note that -Werror doesn't work in the current version of virtualenv due to https://github.com/pypa/virtualenv/issues/194 ). unittest.main should check for the -bb flag in addition to sys.warnoptions. Additionally, if warning filters were modified programmatically before calling unittest.main, unittest will still modify the configuration and potentially override the user's settings. This is a rarer case, but I've done it before to avoid the problem with -W in a virtualenv (https://github.com/facebook/tornado/blob/master/tornado/test/runtests.py). It would be good for there to be some way to tell unittest.main not to touch the warnings at all. main(warnings=False) currently works, but that's relying on an implementation detail (any non-None, non-truthy value works), so either this should be documented or an official way to do the same thing should be added. The attached test file demonstrates the problem: when run with -bb, an warning is logged, but the test passes. -- files: testbb.py messages: 168013 nosy: Ben.Darnell priority: normal severity: normal status: open title: unittest.main negates -bb option and programmatic warning configuration type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file26771/testbb.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15031] Split .pyc parsing from module loading
Changes by Brett Cannon br...@python.org: -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15031] Split .pyc parsing from module loading
Brett Cannon added the comment: So the more I think about this, the more I'm willing to do this in Python 3.4. First, though, the docs would need to be updated in importlib to distinguish between bytecode and byte-compiled files. From there, I think importlib.abc.SourceLoader.parse_byte_compiled_file(data) could exist. It would be a classmethod so people can call it directly if they really want. It would verify the magic number, and if that's good, return a dict that can be directly compared against what path_stats() returns plus the bytecode for the module. This should properly shield the format of bytecode from users while still providing an API people can rely on. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15627] Add a method to importlib.abc.SourceLoader for converting source to a code object
New submission from Brett Cannon: A classmethod called importlib.abc.SourceLoader.source_to_code(source_bytes, path) would return a code object. By default it would be equivalent to ``compile(source_bytes, source_path, 'exec', dont_inherit=True)``, but others could override this to e.g. convert the source to an AST, optimize the AST, and then call compile() to get the desired code object. -- components: Library (Lib) messages: 168015 nosy: brett.cannon, eric.snow priority: low severity: normal stage: test needed status: open title: Add a method to importlib.abc.SourceLoader for converting source to a code object versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15627 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15626] unittest.main negates -bb option and programmatic warning configuration
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
Glenn Linderman added the comment: I forgot to mention that the file you provided in your test doesn't look like a well-formed MHTML file, and so an exception would be expected in this case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15628] Add import ABC hierarchy to docs for importlib
New submission from Andrew Svetlov: It would be useful to show import ABC hierarchy in the docs. See attached patch. -- files: import_abc.diff keywords: patch messages: 168017 nosy: asvetlov priority: normal severity: normal status: open title: Add import ABC hierarchy to docs for importlib versions: Python 3.3 Added file: http://bugs.python.org/file26772/import_abc.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15628 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15628] Add import ABC hierarchy to docs for importlib
Andrew Svetlov added the comment: Brett, what do you think about? -- assignee: - docs@python components: +Documentation keywords: +easy nosy: +brett.cannon, docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15628 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15623] Init time relative imports no longer work from __init__.so modules
Stefan Behnel added the comment: We are continuously testing Cython against all CPython versions starting from 2.4, so I can assure you that it's still working for all other versions. Here's our CI server: https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/618/ I just tried it and it definitely works for me in 3.2 and prints the right module names. I attached the unfolded test directory. The only changes I applied were to change the setup.py script so that you can build it without Cython, and to replace the absolute paths stored in the C files by relative paths (which happily continue to work). Just run python3.3 setup.py build_ext -i and then PYTHON=python3.3 ./test.sh. Note that the output for FILE will be the original Python source file. Cython sets this at init time because CPython fails to provide the correct import file path at that point. The value is actually written down verbatimly in the C sources. It prints sys.modules at module init time, so you can see that it contains my_test_package in Py3.3 but does not contain it in Py3.3. The code for the relative import in __init__.c starts in line 1097. It actually calls __import__() internally. -- Added file: http://bugs.python.org/file26773/test.tgz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15623 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15557] Tests for webbrowser module
R. David Murray added the comment: Regrtest has evolved. For new test files (ie: 3.3 and later) the preferred (at least by me :) idiom now is just: if __name__ == '__main__': unittest.main() Everything else is now automatic, using the unittest machinery. For an example, see test_smptd. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15557 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
