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

Eric Snow added the comment: Traceback when run verbosely: Traceback (most recent call last): File "", line 1, in File "", line 1529, in _find_and_load File "", line 1496, in _find_and_load_unlocked File "", line 583, in _check_name_wrapper File "", line 498, in set_package_wrapper

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

Eric Snow added the comment: The files, post-run: $ find /tmp/test/ /tmp/test/ /tmp/test/my_test_package /tmp/test/my_test_package/__init__.cpython-33dm.so /tmp/test/my_test_package/a.cpython-33dm.so /tmp/test/my_test_package/a.c /tmp/test/my_test_package/a.py /tmp/test/my_test_package/__init__.

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

Eric Snow added the comment: I was able to reproduce the error using a fresh build from tip (34d5ec8a1019): /tmp/test$ PYTHON=/opt/python3.3/bin/python3 ./test.sh ['__main__', '_bisect', '_codecs', '_collections', '_frozen_importlib', '_functools', '_heapq', '_imp', '_io', '_locale', '_sre', '_

[issue15619] set.pop() documentation is confusing

Raymond Hettinger added the comment: I concur with Georg and Eli. The word "arbitrary" was chosen intentionally. -- nosy: +rhettinger ___ 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

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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

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

[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

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

[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

[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

[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

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

[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

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

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

[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

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

[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

[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

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

[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

[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

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

[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

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

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

[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

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

[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

[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

[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

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

[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

[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

[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

[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

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

[issue15557] Tests for webbrowser module

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

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

[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

[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

[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

[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

[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

[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

[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

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

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

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

[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

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

[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

[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

[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

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

[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

[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

[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

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

[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

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

[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

[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

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

[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

[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

[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

[issue3132] implement PEP 3118 struct changes

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

[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

[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

[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 Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[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

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

[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

[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

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

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

[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

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

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

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

  1   2   >