In article <[EMAIL PROTECTED]>, greg <[EMAIL PROTECTED]> wrote:
> Paul Rubin wrote: > > > Do you anticipate having parameters like socket.AF_INET that are > > currently integers, become enumeration members in future releases? > > Since these are derived from values defined > as integers in C, it's probably better to leave > them that way. There may be code that relies > on them being integers or having those integer > values. On a thin API like python's socket module, adding anything which isn't there in the lower level is a mistake (and making AF_INET an enum member would be adding something which isn't there). I just finished adding IPv6 support to a product that didn't have it before. We've got a "platform independent" socket interface which treats the address family as opaque data. It turns out, I had to make ZERO changes to this shim layer. Had the layer known more about address families, I would have had a lot more work to do. Consider, for example, Python running on a system with experimental AF_INET8 support at some point in the future. As it stands now, the Python library code doesn't need to know there's a new address family if all you want to do is open raw AF_INET8 sockets. -- http://mail.python.org/mailman/listinfo/python-list
