Raymond Hettinger writes: > whether users will see any actual benefits (particularly for > internal constants).
I don't understand the parenthetical remark. It seems to me that changing internal constants should have the benefits that Ethan points to for understanding, debugging, and interactive exploration, with the least risk of destabilizing external APIs. I agree with you that the *net* benefit is still likely to be negative due to effects of code churn and the potential for new bugs, but (considering benefit separately from cost) the advertised benefits would be achieved. The point is that I think it's clear that using enums to provide name spaces for the large number of constants whose names are well-known, but not so much the values, in the os module and other OS library wrappers is highest priority, and IMO a net plus. But I would say the next place to look would be exactly these internal constants, where they have similar characteristics (many of them, well-known names, hard-to-remember values: the fds for stdin, stdout, and stderr are non-candidates!) As I said, *I* don't think it's worth doing internal constants, but I couldn't defend that opinion well to somebody who thinks it is worth doing. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
