We've recently released some improvements to the DFP Python Libraryalongside support for v201705. Our goal was to reduce the boilerplate required to construct entities and DFP statements—keep reading to see what's new.

Improved statement creation utility

Previously you had to construct filtering statements manually out of strings, and write a lot of code to bind variables into statements. Here's what the code commonly looked like:

values = [{
    'key': 'startDateTime',
    'value': {
        'xsi_type': 'DateTimeValue',
        'value': {
            'date': {
                'year': start_date.year,
                'month': start_date.month,
                'day': start_date.day
            }
        }
    }
},{
    'key': 'orderName',
    'value': {
        'xsi_type': 'TextValue',
        'value': 'My Order%'
    }
}]
statement = dfp.FilterStatement('WHERE startDateTime > :startDateTime AND '
                                'orderName LIKE :orderName', values)

Dealing directly with strings opens up many potential errors, and we decided that the above was way too much typing just to bind variables. To make things easier, we've introduced a new utility called StatementBuilder. Now you can write code as simple as:

statement = (dfp.StatementBuilder()
             .Where('startDateTime > :startDateTime AND orderName LIKE :orderName')
             .WithBindVariable('startDateTime', start_date)
             .WithBindVariable('orderName', 'My Order%'))

StatementBuilder will automatically infer your variable types and construct the values object. You can then pass this to an API request in the same way that you did with FilterStatement:

response = creative_service.getCreativesByStatement(statement.ToStatement())

Automatic datetime unwrapping

Previously, you had to break out dates and datetimes into our format when constructing entity dictionaries:

line_item = {
    'orderName': 'Awesome New Order',
    'startDateTime': {
        'date': {
            'year': start_date.year,
            'month': start_date.month,
            'day': start_date.day
        },
        'hour': start_date.hour,
        'minute': start_date.minute,
        'second': start_date.second,
        'timezoneid': start_date.tzinfo.zone,
    },
    # ...
}

Starting in this version, you can simply pass a native Python dateor timezone-aware datetime object directly:

start_date = datetime.datetime(2017, 6, 1, 9, 0, 0,
                               tzinfo=pytz.timezone('America/New_York'))
line_item = {
    'orderName': 'Awesome New Order',
    'startDateTime': start_date
    # ...
}

Our library will unwrap the datetime object into our format automatically. We're continuing to support passing the full dictionary, so there's no requirement to migrate your code.

We hope these changes will make building DFP integrations in Python easier. As always, please feel free to get in touch on the forumwith any questions.

 - Gabe Rives-Corbett, DFP API Team

Today we're pleased to announce the v201702 release of the DFP API. This release adds a new PublisherQueryLanguageService table: Change_History. This table contains entries for changes to entities in your network. This allows for the long-awaited ability of querying for DFP entity changes programmatically.

Additionally, v201702 adds the NativeStyleService, which allows you to read, create, and update native styles.

For a full list of API changes in v201702, see the release notes.

With each new release comes a new deprecation. If you're using v201605 or earlier, it's time to look into upgrading. Also remember that v201602 will be sunset at the end of February 2017.

As always, if you have any questions, feel free to drop us a line on the DFP API forums or the Ads Developer Google+ page.

 - Chris Seeley, DFP API Team