(original) (raw)

Good Bad or Neutral, this discussion makes my point:

Using typing annotation as a necessary part of a standard library module is injecting typing into "ordinary" python in a new way.

It is no longer going to appear to be completely optional, and only of concern to those that choose to use it (and mypy or similar).

And I do think it is really bad UI to have something like:

@dataclass
class C:
a: Int = 1
b: float = 1.0


be the recommended (and shown in all the examples, and really be almost the only way) to define a dataclass, when the type will in fact be completely ignored by the implementation.

Newbies are going to be confused by this -- they really are.

Anyway, clearly I personally don't think this is a very good idea, but I see that annotations are a natural and easy way to express the fields without adding any new syntax.

But most importantly I don't think this should become standard without consideration of the impact and a deliberate decision to do so.

A note: I don't know who everyone is that was engaged in the gitHub discussion working out the details, but at least a few core folks are very engaged in the introduction of type hinting to Python in general -- so I think a certain perspective may have been over-represented.

Are there other options??

plain old:

@dataclass
class C:
a = 1
b = 1.0

would work, though then there would be no way to express fields without defaults:

@dataclass
class C:
a = 1
b = None

almost -- but they is there "no default" or is the default None

Would it be impossible to use the annotation syntax, but with the type optional:

@dataclass
class C:
a : = 1 # filed with default value
b : # field with no default

This is not legal python now, but are there barriers other than not wanting to make yet more changes to it being legal (i.e. hard/impossible to unambiguously parse, etc.

Maybe this can all be addresses by more "Untyped" examples the docs.

-CHB















On Sun, Dec 17, 2017 at 8:54 AM, David Mertz <mertz@gnosis.cx> wrote:
On Sun, Dec 17, 2017 at 8:22 AM, Guido van Rossum <guido@python.org> wrote:
On Sun, Dec 17, 2017 at 2:11 AM, Julien Salort <listes@salort.eu> wrote:
Naive question from a lurker: does it mean that it works also if one
annotates with something that is not a type, e.g. a comment,

@dataclass
class C:
a: "This represents the amplitude" = 0.0
b: "This is an offset" = 0.0

I would personally not use the notation for this, but it is legal code. However static type checkers like mypy won't be happy with this.

Mypy definitely won't like that use of annotation, but documentation systems might. For example, in a hover tooltip in an IDE/editor, it's probably more helpful to see the descriptive message than "int" or "float" for the attribute.

What about data that isn't built-in scalars? Does this look right to people (and will mypy be happy with it)?

@dataclass
class C:
a:numpy.ndarray = numpy.random.random((3,3))
b:MyCustomClass = MyCustomClass("foo", 37.2, 1+2j)

I don't think those look terrible, but I think this looks better:

@dataclass
class C:
a:Infer = np.random.random((3,3))
b:Infer = MyCustomClass("foo", 37.2, 1+2j)

Where the name 'Infer' (or some other spelling) was a name defined in the \`dataclasses\` module. In this case, I don't want to use \`typing.Any\` since I really do want "the type of thing the default value has."

--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov




--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov