On 04/29/2012 02:01 AM, Eric V. Smith wrote: > On 4/29/2012 4:41 AM, Larry Hastings wrote: >> I'd prefer an object to a dict, but not a tuple / structseq. There's no >> need for the members to be iterable. > I agree with you, but there's already plenty of precedent for this. > [...] Iteration for these isn't very useful, but structseq is the handiest > type we have: The times, they are a-changin'. I've been meaning to start whacking the things which are iterable which really shouldn't be. Like, who uses destructuring assignment with the os.stat result anymore? Puh-leez, that's so 1996. That really oughta be deprecated. Anyway, it'd be swell if we could stop adding new ones. Maybe we need a clone of structseq that removes iterability? (I was thinking, we could hack structseq so it didn't behave iterably if n_in_sequence was 0. But, no, it inherits from tuple, such shenanigans are a bad idea.) //arry/ p.s. MvL gets credit for the original observation, and the suggestion of deprecating iterability. As usual I'm standing on somebody else's shoulders. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120429/ef711e3b/attachment.html>
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