• ev3dev version: 4.4.24-16-ev3dev-ev3
• **ev3dev-lang-python version:**0.8.0

If you look at the special sensor classes for the Color Sensor and the Infrared Sensor you'll see the Color Sensor has a very robust special sensor class:
http://python-ev3dev.readthedocs.io/en/latest/sensors.html#special-sensor-classes

However the Infrared Sensor has only the one property: proximity. There is no support for the IR-SEEK mode within the special sensor class. You can of course use the sensor values directly if you read the sensor page:
http://www.ev3dev.org/docs/sensors/lego-ev3-infrared-sensor/

Your code looks like this, which isn't terrible.

        ir_sensor = ev3.InfraredSensor()
        ir_sensor.mode = "IR-SEEK"
        current_distance_channel1 = ir_sensor.value(0)
        current_heading_channel1 = ir_sensor.value(1)

Two issues:

1. This approach is less elegant than first class properties / methods on the special sensor class. It makes IR-SEEK harder for new people to discover and makes the code feel more manual.
   Maybe we could add a method to call

        current_distance_channel1 = ir_sensor.beacon_distance(1)
        current_heading_channel1 = ir_sensor.beacon_heading(1)
   

or a bunch of properties (8 properties):

        current_distance_channel1 = ir_sensor.beacon_distance_ch1
        current_heading_channel1 = ir_sensor.beacon_heading_ch1

2. This other problem I've noticed with the manual approach is that it's a bit buggy. It has errors sometimes when there is difficulty communicating with the sensor. If fires errors often enough that I've started wrapping calls in try: expect: blocks just in case (can happen when setting the mode too). If you run enough tests you'll see an error thrown too. I'm guessing there is a bit of protection built in with things like .proximity because I never see errors with them. So I'd like the elegance of adding IR-SEEK and the protection from errors that seems to happen with .proximity. :)

Yet again happy to let others drive, just putting in the feature request.