[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 acce

[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 ___

[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) `. 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 automati

[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

[issue15622] struct module 'c' specifier does not follow PEP-3118

Changes by Stefan Krah : -- title: memoryview.to_list() incorrect for 'c' format -> struct module 'c' specifier does not follow PEP-3118 ___ Python tracker ___ _

[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 ---

[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 ___

[issue15239] Abandoned Tools/unicode/mkstringprep.py

Changes by Georg Brandl : -- versions: +Python 3.4 -Python 3.2, Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[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 311

[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: stru

[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 <

[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 comp

[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

[issue15622] struct module 'c' specifier does not follow PEP-3118

Stefan Krah added the comment: Martin v. L??wis 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 confo

[issue15239] Abandoned Tools/unicode/mkstringprep.py

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15622] struct module 'c' specifier does not follow PEP-3118

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15622] memoryview.to_list() incorrect for 'c' format

Stefan Krah added the comment: Martin v. L??wis 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 unpacki

[issue15622] struct module 'c' specifier does not follow PEP-3118

Changes by Stefan Krah : -- 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

[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

[issue3132] implement PEP 3118 struct changes

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[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 agre

[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

[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

[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 ___

[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 fun

[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

[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. -- _

[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 ___ Pytho

[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15600] expose the finder details used by the FileFinder path hook

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[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 u

[issue15622] struct module 'c' specifier does not follow PEP-3118

Nick Coghlan added the comment: 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. P

[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 UT

[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 obj

[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 prop

[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

[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 __

[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: Tra

[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 ___ __

[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 _

[issue15622] struct module 'c' specifier does not follow PEP-3118

Changes by Nick Coghlan : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue15623] Init time relative imports no longer work from __init__.so modules

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15622] struct module 'c' specifier does not follow PEP-3118

Chris Jerdonek added the comment: > Status was still open. Was that a tracker bug? -- nosy: +cjerdonek ___ Python tracker ___ ___ Py

[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 "", line 1, in so

[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

[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 ___ ___ Python-bugs-list mailing li

[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 1

[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 almo

[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? -- ___

[issue15557] Tests for webbrowser module

Changes by Antoine Pitrou : -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[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(

[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

[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 matche

[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

[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) pe

[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

[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 DR

[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 compatibil

[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

[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

[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

[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 ___ ___

[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) -

[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 memor

[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 comp

[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 documentat

[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 w

[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. -- ___ Pyt

[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-- "

[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

[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 assumpt

[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 >

[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 o

[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

[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 ___ _

[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

[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.

[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 c

[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).

[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 memo

[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 s

[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 ___ ___

[issue15593] urlparse.parse_qs documentation wrong re: urlencode

Changes by Senthil Kumaran : -- nosy: +orsenthil ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[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. ---

[issue15625] Support u and w codes in memoryview

Changes by Martin v. Löwis : -- versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[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 equ

[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

[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

[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 g

[issue15031] Split .pyc parsing from module loading

Changes by Brett Cannon : -- versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[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_compi

[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. conver

[issue15626] unittest.main negates -bb option and programmatic warning configuration

Changes by Chris Jerdonek : -- nosy: +cjerdonek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[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

[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 import

[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

[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 i

[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_s

[issue15564] cgi.FieldStorage should not call read_multi on files

R. David Murray added the comment: I'd like to weigh in on this, but I need time to do research on the question first. It may be a bit before I get that time. -- ___ Python tracker ___

[issue15626] unittest.main negates -bb option and programmatic warning configuration

Changes by R. David Murray : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

  1   2   >