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 <me...@gnosis.cx> wrote:
> On Sun, Dec 17, 2017 at 8:22 AM, Guido van Rossum <gu...@python.org>
> wrote:
>
>> On Sun, Dec 17, 2017 at 2:11 AM, Julien Salort <lis...@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.bar...@noaa.gov
_______________________________________________
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/archive%40mail-archive.com
