Actually my motivation for doing this is that I want to introduce a third type of port connection (for internal use only, for now), and scaling the current approach to a third type really compounds the ugliness, particularly because it requires modifying pyobject.cc directly (i.e., it can't be done via EXTRAS).  The advantage of this change is that it makes the port connection paradigm independent of the type of ports, meaning it's easy to add more types.  Sorry for not explaining that up front.

The different ports do indeed have little in common other than their method of connection, but I contend that if they are going to share the same method of connection, the new code is a much better way of doing that.  Another approach that I considered would be to forget using python assignment to bind Ethernet devices and links.  If we add the constraints that (1) all Ethernet connections are made via point-to-point links and (2) those links are always symmetric in delay and bandwidth, then we could just pass in an EtherLink pointer as a param for each object that wants a connection.  While I would be fine with that, particularly if we had started out that way, switching to that approach now both introduces more constraints and would require modifications to the (admittedly few) scripts that use Ethernet links, so I thought this approach was preferable.

I'm not sure what you mean by "makes the port/interface separation much more difficult"; to me, it makes the port concept more abstract, which should make it more separable from other issues.

The last statement was referring to the changes needed to support: http://reviews.gem5.org/r/1301/. I fear this additional level of Port makes that binding process more challenging.

I definitely support the approach you mention with the EtherLink pointers. Supposedly that also avoids the (in my opinion rather confusing) binding by =.