Larry Hastings <larry at hastings.org> wrote: > > Josiah Carlson wrote: > > Larry Hastings <larry at hastings.org> wrote: > > > >> Josiah Carlson wrote: > >> > >>> one thing to note with your method - you can't guarantee the order > >>> of the attributes as they are being displayed. > >>> > >> Actually, my record type *can*; see the hack using the __names__ field. > > Actually, it *can't*. The ordering of the dict produced by the **kwargs > > arguments is exactly same as a regular dictionary. > > Just to set the record.py straight, more for posterity than anything else: > > Actually, it *does*, because my prototype has explicit support for > imposing such an ordering. That's what the "__names__" field is used > for--it's an optional array of field names, in the order you want them > displayed from __repr__(). > > Mr. Carlson's posting, while correct on general principles, was just > plain wrong about my code; I suspect he hadn't bothered to read it, and > instead based his reply on speculation about how it "probably" worked. No, I just didn't notice the portion of your code (in the 'if __name__ == "__main__" block) that modified the __names__ field after record construction. In the other record types that were offered by Steven and Raymond, the point is to have an ordering that is fixed. I didn't notice it because I expected that it was like Raymond and Steven's; static layout after construction - but that is not the case. - Josiah
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4