Martin v. Löwis added the comment: > So v.format must equal w.format, where format is a format string in > struct module syntax. The topic of this issue is to determine under > what circumstances two strings in struct module syntax are considered > equal.
And that is exactly my question: We don't need a patch implementing it (yet), but a specification of what is to be implemented first. I know when two strings are equal (regardless of their syntax): if they have the same length, and contain the same characters in the same order. Apparently, you have a different notion of "equal" for strings in mind, please be explicitly what that notion is. > memoryview can compare against any object with a getbufferproc, in this > case array.array. memoryview_richcompare() calls PyObject_GetBuffer(other) > and proceeds to compare its own internal Py_buffer v against the obtained > Py_buffer w. Can this be expressed on Python level as well? I.e. is it correct to say: an array/buffer/memoryview A is equal to an object O iff A is equal to memoryview(O)? Or could it be that these two equivalences might reasonably differ? > Hence my proposal to demand a strict canonical form for PEP-3118 format > strings, which would be a proper subset of struct module format strings. Can you kindly phrase this as a specification? Who is demanding what from whom? Proposal: two format strings are equal if their canonical forms are equal strings. The canonical form C of a string S is created by ??? However, it appears that you may have something different in mind where things are rejected/fail to work if the canonical form isn't originally provided by somebody (whom?) So another Proposal: two format strings are equal iff they are in both in canonical form and are equal strings. This would imply that a format string which is not in canonical form is not equal to any other strings, not even to itself, so this may still not be what you want. But I can't guess what it is that you want. ---------- _______________________________________ 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
