<p dir="ltr"><br>
On 24 Feb 2013 08:14, "Terry Reedy" <<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>> wrote:<br>
><br>
> On 2/23/2013 12:46 PM, Nick Coghlan wrote:<br>
><br>
>> For the standard library, we *really don't care* about any of those<br>
>> things, because we're currently using integers and strings for<br>
>> everything, so we can't add structure without risking breaking other<br>
>> people's code. However, just as we can get away with switching from<br>
>> producing and consuming tuples to producing and consuming namedtuples<br>
>> without breaking backwards compatibility, we *could* get away with<br>
>> producing and consuming names values in many cases, so long as those<br>
>> values behaved exactly like they did previously (i.e. as integers -<br>
>> there's little benefit to replacing our string "enums", since they're<br>
>> generally chosen for ease of debugging).<br>
><br>
><br>
> It seems that what would specifically be useful is a namedint class whose instances would be ints with a .__name__ attribute and a custom .__str__ and __repr__. (Note that None, False, and True do not have such because the name knowledge is elsewhere -- in __str__ I would guess.) In all other respects, lets them be ints, just as named<field>tuples are otherwise tuples.<br>

><br>
> As you say, a namedstring is hardly useful as a string can be considered to be its own name.<br>
><br>
> I personally think we should skip the bikeshedding over how to avoid repeating names to make the bound name match the definition name (as with def, class, and import). Actually, they do not have to match and in cases, one might want a short bound name for retrieval and a longer definition name for display.</p>

<p dir="ltr">I realised last night that "labelled values" might be a better building block than "named values".</p>
<p dir="ltr">I'll see if I can find my old python-ideas posts about the concept (although, to be honest, I'm not sure it has ever been elaborated much further than it has in this thread)</p>
<p dir="ltr">> In any case, compared to the number of functions, classes, and imported modules in the stdlib, there would only be a few namedints, and any typos would be caught very quickly.<br>
><br>
> In io (say)<br>
><br>
> stdin = namedint(1, 'stdin')  # or namedint(1, 'standard input (fd 1)')<br>
> etc<br>
> plus 3 lines for seek.<br>
><br>
><br>
> -- <br>
> Terry Jan Reedy<br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-dev">http://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>