We already support sets but not empty sets.  After the PR, this now works:

    >>> from ast import literal_eval
    >>> literal_eval('set()')
    set()

If we wanted, it would be a simple matter to extend it frozensets:

    >>> literal_eval('frozenset({10, 20, 30})')
    frozenset({10, 20, 30})

set() is neither literal nor container display.

> set() is neither literal nor container display.

Yes, that is obvious.  However, we do support sets and set() is how make an empty set.   

It is weird to support sets but not empty sets, especially when it is so easy to do so safely.

New changeset 4fcf5c12a37a8d3d8d6303c44c223dbc8d568cfd by Raymond Hettinger in branch 'master':
bpo-39158: ast.literal_eval() doesn't support empty sets (GH-17742)
https://github.com/python/cpython/commit/4fcf5c12a37a8d3d8d6303c44c223dbc8d568cfd

The function literal_eval is not safe anymore as the constructor can be intercepted:

>>> import builtins
>>> def evil_code(*args):
...     print("Something evil")
...
>>> builtins.set = evil_code
>>> ast.literal_eval("set()")
Something evil


I think we should either use {0}.__class__.

Also, the documentation now is wrong as the function does more than evaluate literals or container displays.

> The function literal_eval is not safe anymore as the constructor can be intercepted:

Well, actually it can also be done with any other builtin via the same trick, so this is no different but is only slightly more obvious that it can be done.

I still find a bit weird that the documentation says "literal or container display" but 'set' is neither.

I am re-closing the issue as I don't think is worth complicating the docs for this edge case and the security concern is non existent.

Apologies for the noise. If someone feels strongly about the documentation, they can reopen the issue.

The documentation for ast.literal_eval():

   Safely evaluate an expression node or a string containing a Python literal or
   container display.  The string or node provided may only consist of the
   following Python literal structures: strings, bytes, numbers, tuples, lists,
   dicts, sets, booleans, and ``None``.

https://docs.python.org/3/library/ast.html#ast.literal_eval

If we are going to add support of a function call set(), we should change the documentation.

And if add support of non-literals, where should we stop? Should we support also frozenset() and bytearray()? inf and nan? infj and nanj? complex()? Ellipsis? __debug__?

> And if add support of non-literals, where should we stop? Should we support also frozenset() and bytearray()? inf and nan? infj and nanj? complex()? Ellipsis? __debug__?

Then the name of the function would be a bit misleading (for frozenset() and bytearray()), no? I think the set() change is somehow inconsistent already with the function name.

> The function literal_eval is not safe anymore as the 
> constructor can be intercepted

"Safe" means safe from user input to literal_eval().

If a person can already write arbitrary code that redefines a builtin, then they can already do anything they want.

> "Safe" means safe from user input to literal_eval().

Yup, apologies. I had something in mind and I realized after writing my initial comment. That is why I said afterwards:

> and the security concern is non-existent.