Sunny K added the comment: New patch for 3.4 adds the following:
1. _fields 2. _replace() 3. _asdict() 4. eval(repr(s)) == s Now the issues: 1. _asdict() returns a normal dictionary. I don't know if this is what is required. 2. Both _asdict() and _replace() assume that unnamed visible fields are at the end of the visible sequence. A comment at the beginning says they are allowed for indices < n_visible_fields. Is there another way to map members to values? Because tp->members is (visible named fields + invisible named fields) whereas values array is (visible named fields + visible unnamed fields + invisible named fields) 3. The mismatch mentioned above is present in the current implementation of repr: In os.stat_result, the last three visible fields are unnamed (i.e integer a_time, m_time and c_time). However they are present in the repr output with keys which are the first three keys from the invisible part(float a_time, m_time and c_time). Was this intentional? Also, the above logic causes duplicate keys when invisible fields are included in the repr output as per issue11629. In my patch for that issue, i put invisible fields under the 'dict' keyword argument. This output format utilises code already present in structseq_new and makes eval work as expected when invisible fields are present in repr. Also, it sidesteps the question of duplicated keys because they are present inside a dict. 4. Raymond stated that _fields should contain only the visible positional fields. So _fields of os.stat_result contains only 7 fields because of the three unnamed fields. Is this the expected implementation? 5. Is there a way to declare a member function in C that accepts only keyword arguments(like _replace())? I could not find one. This is my first real C patch. So some of the issues might just be a lack of understanding. Apologies. ---------- keywords: +patch nosy: +sunfinite Added file: http://bugs.python.org/file32525/structseq_1.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1820> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com