[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

[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

[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

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

[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

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

[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

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

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