Union type aliases valid as expressions

Type aliases can be used in expressions without issues:

from typing import Union
x = Union[int, str]
x.foo # No error
x = [1] # No error

I think using a Union type alias in an expression should probably be disallowed, or it should have a narrow type. Aliases to simple types such as "x = int" should be equivalent to the alias target.

So the following is not supposed to work, correct? Is there any way to define aliases for more complex types? Thanks. -John

from typing import Union

class A(object):

    def __init__(self, a: int) -> None:
        self.a = a

    def __str__(self) -> str:
        return str(self.a)

t = Union[int, A]

def foo(arg: t) -> str:
    return str(arg)

print(foo(1))
print(foo(A(1)))

The use of the alias t in the arg annotation for foo() causes a crash in mypy:

Traceback (most recent call last):
  File "/usr/local/bin/mypy", line 169, in <module>
    main()
  File "/usr/local/bin/mypy", line 34, in main
    type_check_only(path, module, bin_dir, options)
  File "/usr/local/bin/mypy", line 78, in type_check_only
    python_path=options.python_path)
  File "/usr/local/lib/python3.5/site-packages/mypy/build.py", line 164, in build
    result = manager.process(UnprocessedFile(info, program_text))
  File "/usr/local/lib/python3.5/site-packages/mypy/build.py", line 342, in process
    next.process()
  File "/usr/local/lib/python3.5/site-packages/mypy/build.py", line 802, in process
    self.semantic_analyzer_pass3().visit_file(self.tree, self.tree.path)
  File "/usr/local/lib/python3.5/site-packages/mypy/semanal.py", line 1881, in visit_file
    file_node.accept(self)
  File "/usr/local/lib/python3.5/site-packages/mypy/nodes.py", line 139, in accept
    return visitor.visit_mypy_file(self)
  File "/usr/local/lib/python3.5/site-packages/mypy/traverser.py", line 33, in visit_mypy_file
    d.accept(self)
  File "/usr/local/lib/python3.5/site-packages/mypy/nodes.py", line 324, in accept
    return visitor.visit_func_def(self)
  File "/usr/local/lib/python3.5/site-packages/mypy/semanal.py", line 1885, in visit_func_def
    self.analyze(fdef.type)
  File "/usr/local/lib/python3.5/site-packages/mypy/semanal.py", line 1922, in analyze
    type.accept(analyzer)
  File "/usr/local/lib/python3.5/site-packages/mypy/types.py", line 294, in accept
    return visitor.visit_callable_type(self)
  File "/usr/local/lib/python3.5/site-packages/mypy/typeanal.py", line 291, in visit_callable_type
    arg_type.accept(self)
  File "/usr/local/lib/python3.5/site-packages/mypy/types.py", line 453, in accept
    return visitor.visit_union_type(self)
  File "/usr/local/lib/python3.5/site-packages/mypy/typeanal.py", line 299, in visit_union_type
    item.accept(self)
AttributeError: 'NoneType' object has no attribute 'accept'

(This can be avoided by writing out the annotation as Union[int, A]). I think it should just work.

It's a known issue that type aliases are flakey and incomplete: #298, #330

The intention is to have support for complex type aliases. The current prototype implementation of type aliases was implemented as part of a hack week project, and nobody has finished the implementation.

I'm going to look at it today and fix some issues.

Type aliases now work but the this issue is till open (type aliases have type Any).

Two more small upstream typing.py changes by Ivan Levkivskyi (#329, #330

@JukkaL

@JukkaL This issue seems to be fixed now. I get these errors:

testold1.py:3: error: "Type alias to Union" has no attribute "foo"
testold1.py:4: error: Incompatible types in assignment (expression has type List[int], variable has type "Type alias to Union")

Probably, I fixed this accidentally when implemented generic aliases.

Yeah, this seems to work now.

Navigation Menu

Repository navigation

Union type aliases valid as expressions #329

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Union type aliases valid as expressions #329

Description

Activity

jwbaugh commented on Jan 29, 2015

gvanrossum commented on Jan 29, 2015

JukkaL commented on Jan 31, 2015

JukkaL commented on Jan 31, 2015

ilevkivskyi commented on Feb 1, 2017

JukkaL commented on Feb 2, 2017

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions