Add NewType

[ilevkivskyi]

Simple minded implementation of NewType (see #189 and python/mypy#1284 (comment)) plus some tests and a short discussion in the PEP.
Also I added Type and ContextManager to the list of types provided by typing.py.

[bintoro]

@ilevkivskyi I know you're intent on maintaining the distinction between types and classes, so I think here "class" is the correct choice, no? EDIT: Actually, never mind. I was too focused on how they simulate instantiation. I think there's just something about the name NewType that's bugging me.

From an introspection POV, an instance of a class with def __call__(self, x): return x would be easier to detect than a plain function while still avoiding the instantiation overhead.

[gvanrossum]

@JukkaL, what do you think of this design?

[ilevkivskyi]

@bintoro

I know you're intent on maintaining the distinction between types and classes, so I think here "class" is the correct choice, no?

I am intentionally a bit "general" here, see my comment from the issue:
"I do not discuss whether NewType('EURtoUSD', Callable[[float], float]) etc. are allowed. If necessary, we could clarify this later."

Concerning your two other points, the idea here is to be really minimal, to allow minimum overhead. In particular your idea with many base classes is almost equivalent to Intersection, that might be implemented later (there is an issue on this).

[gvanrossum]

Note, see my comment/concern I posted to the corresponding issue. I don't think this is ripe yet...

[gvanrossum]

No comma.

[gvanrossum]

This and the next one I'll apply right now. They're unrelated to this issue.

[ilevkivskyi]

OK, sure, I just posted a link to this PR to python-dev asking for comments.

[JukkaL]

A few things:

• I'd add explicit language about isinstance not being supported for these types (and why not).
• What should we call types defined using NewType? Are they "NewType types"?

[ilevkivskyi]

@JukkaL

I'd add explicit language about isinstance not being supported for these types (and why not).

Good point. I added this in new commit

What should we call types defined using NewType? Are they "NewType types"?

Here I am not sure. Maybe ad-hoc types?

EDIT: replaced by the correct quote

[gvanrossum]

Let's think some more about the name, it feels important. Even if the function is called NewType.

…

--Guido (mobile)

[bintoro]

Appointed types — because they are only nominally distinct.

[lgautier]

• AdhocType- because (presumably) just created for one situation
• NamedType - to play on a naming similarity with namedtuple

[yedpodtrzitko]

LambdaType

[SpotlightKid]

TypeDef

[sietse]

I like @lgautier's NamedType a lot: to me, it expresses "this is otherwise the same type, but it has a different name (and therefore its own meaning)". Also, like he says, it meshes nicely with namedtuple (and typing.NamedTuple).

How I would read it:

UserID = NamedType('UserID', int)
This is a type of int named UserID

---

If NamedType does not make it, what about ValueType?

• ValueType: Scala has the same concept, and calls them Value Classes. It expresses nicely that this type does not say something about the data structure, but about the value it contains.

How I would read it:

UserID = ValueType('UserID', int)
This is an int with a value that is a user ID.

NamedType works better, though.

[gvanrossum]

I could not follow anything from the Scala ValueType description (no news
there :-).

The explanation "it is the same type with a different name" feels wrong --
if it really was the same name it would be a type alias. In fact it is not
the same type, it has a specific relationship to the original type, which
is exactly that it is a subtype (but not every subtype is a NewType).

I will check with Jukka but unless he has strong objections I am going for
Distinct Type (two words) when we're discussing it in English text, but I
will keep NewType (one function) in code.

On Wed, Jun 1, 2016 at 1:42 AM, Sietse Brouwer notifications@github.com
wrote:

I like @lgautier https://github.com/lgautier's NamedType a lot: to me,
it expresses "this is otherwise the same type, but it has a different name
(and therefore its own meaning)". Also, like he says, it meshes nicely with
namedtuple (and typing.NamedTuple).

How I would read it:

UserID = NamedType('UserID', int) -> This is a type of int named UserID

---

If NamedType does not make it, what about ValueType?

• ValueType: Scala has the same concept, and calls them Value Classes
  http://docs.scala-lang.org/overviews/core/value-classes.html. It
  expresses nicely that this type does not say something about the data
  structure, but about the value it contains.

How I would read it:

UserID = ValueType('UserID', int) -> This is an int with a user ID value
type.

NamedType works better, though.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#226 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACwrMiamuJVBxyBPxt4bA0yULC0M3MzVks5qHUXcgaJpZM4IoPSY
.

--Guido van Rossum (python.org/~guido)

[gvanrossum]

I'm going to abandon the "English description" discussion, and merge this as-is. The new function will be called NewType() and in the discussion we'll use "unique type" (like in this PR).

[gvanrossum]

Mypy issue is here: python/mypy#1284