Re: [Python-Dev] Is static typing still optional?

[Eric V. Smith]

On 12/21/2017 1:46 AM, Chris Barker wrote:
On Wed, Dec 20, 2017 at 5:29 PM, Eric V. Smith > wrote:


There is definitely a passive bias towards using types with
dataclasses in that the Eric (the author) doesn't appear to want an
example without them in the pep/docs.


I'm not sure what such an example would look like. Do you mean
without annotations? 



IIUC, there is not way to make a dataclass without annotations, yes? 
That it, using annotations to determine the fields is the one and only 
way the decorator works. So it's impossible to give an example without 
annotations, yes?


Correct. Well, you will be able to use make_dataclass() without type 
information after I fix bpo-32278, but most users won't be using that.


I suggest that it be clear in the docs, and ideally in the PEP, that the 
dataclass decorator is using the *annotation" syntax, and that the the 
only relevant part it uses is that an annotation exists, but the value 
of the annotation is essentially (completely?) ignored. 


I think the PEP is very clear about this: "The dataclass decorator 
examines the class to find fields. A field is defined as any variable 
identified in __annotations__. That is, a variable that has a type 
annotation. With two exceptions described below, none of the Data Class 
machinery examines the type specified in the annotation."


I agree the docs should also be clear about this.

So we should 
have examples like:


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

Then maybe:

@dataclass
class C:
     a: "the a parameter" # field with no default
     b: "another, different parameter" = 0.0 # field with a default

Then the docs can go to say that if the user wants to specify a type for 
use with a static type checking pre-processor, they can do it like so:


@dataclass
class C:
     a: int # integer field with no default
     b: float = 0.0 # float field with a default

And the types will be recognized by type checkers such as mypy.

And I think the non-typed examples should go first in the docs.


I'll leave this for others to decide. The docs, and how approachable 
they are to various audiences, isn't my area of expertise.


This is completely analogous to how all the other parts of python are 
taught. Would anyone suggest that the very first example of a function 
definition that a newbie sees would be:


def func(a: int, b:float = 0.0):
     body_of_function

Then, _maybe_ way down on the page, you mention that oh, by the way, 
those types are completely ignored by Python. And not even give any 
examples without types?



 > Re-reading my post you referenced, is it just an example using 
typing.Any?


I actually think that is exactly the wrong point -- typing.Any is still 
using type hinting -- it's an explicit way to say, "any type will do", 
but it's only relevant if you are using a type checker. We really need 
examples for folks that don't know or care about type hinting at all.


typing.Any is for use by people that are explicitly adding type hinting, 
and should be discussed in type hinting documentation.


 >  I'm okay with that in the docs, I just didn't want to focus on it in 
the PEP. I want the PEP to only
 > have the one reference to typing, for typing.ClassVar. I figure the 
people reading the PEP can
 > extrapolate to all of the possible uses for annotations that they 
don't need to see a typing.Any

 > example.

no they don't, but they DO need to see examples without type hints at all.


I'm not opposed to this in the documentation. Maybe we should decide on 
a convention on what to use to convey "don't care". I've seen 
typing.Any, None, ellipsis, strings, etc. all used.


Eric.
___
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

Re: [Python-Dev] Is static typing still optional?

[Terry Reedy]

On 12/21/2017 4:22 AM, Eric V. Smith wrote:

On 12/21/2017 1:46 AM, Chris Barker wrote:


I suggest that it be clear in the docs, and ideally in the PEP, that 
the dataclass decorator is using the *annotation" syntax, and that the 
the only relevant part it uses is that an annotation exists, but the 
value of the annotation is essentially (completely?) ignored. 


I think the PEP is very clear about this: "The dataclass decorator 
examines the class to find fields. A field is defined as any variable 
identified in __annotations__. That is, a variable that has a type 
annotation. With two exceptions described below, none of the Data Class 
machinery examines the type specified in the annotation."


This seems clear enough.  It could come after describing what a 
dataclass *is*.



I agree the docs should also be clear about this.




So we should have examples like:

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

Then maybe:

@dataclass
class C:
 a: "the a parameter" # field with no default
 b: "another, different parameter" = 0.0 # field with a default

Then the docs can go to say that if the user wants to specify a type 
for use with a static type checking pre-processor, they can do it like 
so:


@dataclass
class C:
 a: int # integer field with no default
 b: float = 0.0 # float field with a default

And the types will be recognized by type checkers such as mypy.

And I think the non-typed examples should go first in the docs.


Module some bike-shedding, the above seems pretty good to me.


I'll leave this for others to decide. The docs, and how approachable 
they are to various audiences, isn't my area of expertise.


--
Terry Jan Reedy


___
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

Re: [Python-Dev] Is static typing still optional?

[Sven R. Kunze]

On 21.12.2017 11:22, Terry Reedy wrote:



@dataclass
class C:
 a: int # integer field with no default
 b: float = 0.0 # float field with a default

And the types will be recognized by type checkers such as mypy.

And I think the non-typed examples should go first in the docs.




I still don't understand why "I don't care" can be defined by "leaving out"

@dataclass
class C:
 b = 0.0 # float field with a default


For non-default fields, I like ellipsis too.

Cheer,
Sven
___
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

Re: [Python-Dev] Is static typing still optional?

[Ivan Levkivskyi]

On 21 December 2017 at 11:22, Terry Reedy  wrote:

> On 12/21/2017 4:22 AM, Eric V. Smith wrote:
>
>> On 12/21/2017 1:46 AM, Chris Barker wrote:
>>
>
> I suggest that it be clear in the docs, and ideally in the PEP, that the
>>> dataclass decorator is using the *annotation" syntax, and that the the only
>>> relevant part it uses is that an annotation exists, but the value of the
>>> annotation is essentially (completely?) ignored.
>>>
>>
>> I think the PEP is very clear about this: "The dataclass decorator
>> examines the class to find fields. A field is defined as any variable
>> identified in __annotations__. That is, a variable that has a type
>> annotation. With two exceptions described below, none of the Data Class
>> machinery examines the type specified in the annotation."
>>
>
> This seems clear enough.  It could come after describing what a dataclass
> *is*.
>
> I agree the docs should also be clear about this.
>>
>
>
> So we should have examples like:
>>>
>>> @dataclass
>>> class C:
>>>  a: ...  # field with no default
>>>  b: ... = 0 # filed with a default value
>>>
>>> Then maybe:
>>>
>>> @dataclass
>>> class C:
>>>  a: "the a parameter" # field with no default
>>>  b: "another, different parameter" = 0.0 # field with a default
>>>
>>> Then the docs can go to say that if the user wants to specify a type for
>>> use with a static type checking pre-processor, they can do it like so:
>>>
>>> @dataclass
>>> class C:
>>>  a: int # integer field with no default
>>>  b: float = 0.0 # float field with a default
>>>
>>> And the types will be recognized by type checkers such as mypy.
>>>
>>> And I think the non-typed examples should go first in the docs.
>>>
>>
> Module some bike-shedding, the above seems pretty good to me.
>

For me, the three options for "don't care" have a bit different meaning:

* typing.Any: this class is supposed to be used with static type checkers,
but this field is too dynamic
* ... (ellipsis): this class may or may not be used with static type
checkers, use the inferred type in the latter case
* "field docstring": this class should not be used with static type checkers

Assuming this, the second option would be the "real" "don't care". If this
makes sense,
then we can go the way proposed in
https://github.com/python/typing/issues/276 and make ellipsis semantics
"official" in PEP 484.
(pending Guido's approval)

--
Ivan
___
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

Re: [Python-Dev] Is static typing still optional?

[Eric V. Smith]

On 12/21/17 6:25 AM, Sven R. Kunze wrote:

On 21.12.2017 11:22, Terry Reedy wrote:



@dataclass
class C:
 a: int # integer field with no default
 b: float = 0.0 # float field with a default

And the types will be recognized by type checkers such as mypy.

And I think the non-typed examples should go first in the docs.




I still don't understand why "I don't care" can be defined by "leaving out"

@dataclass
class C:
 b = 0.0 # float field with a default


Because you can't know the order that x and y are defined in this example:

class C:
x: int
y = 0

'x' is not in C.__dict__, and 'y' is not in C.__annotations__.

Someone will suggest a metaclass, but that has its own problems. Mainly, 
interfering with other metaclasses.


Eric.





For non-default fields, I like ellipsis too.

Cheer,
Sven


___
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/eric%2Ba-python-dev%40trueblade.com


___
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

Re: [Python-Dev] Is static typing still optional?

[Terry Reedy]

On 12/21/2017 9:23 AM, Eric V. Smith wrote:



On 12/21/17 6:25 AM, Sven R. Kunze wrote:

On 21.12.2017 11:22, Terry Reedy wrote:



@dataclass
class C:
 a: int # integer field with no default
 b: float = 0.0 # float field with a default

And the types will be recognized by type checkers such as mypy.

And I think the non-typed examples should go first in the docs.




I still don't understand why "I don't care" can be defined by "leaving 
out"


@dataclass
class C:
 b = 0.0 # float field with a default


Because you can't know the order that x and y are defined in this example:

class C:
     x: int
     y = 0

'x' is not in C.__dict__, and 'y' is not in C.__annotations__.


I think the understanding problem with this feature arises from two 
factors: using annotations to define possibly un-initialized slots is 
non-obvious; a new use of annotations for something other than static 
typing is a bit of a reversal of the recent pronouncement 'annotations 
should only be used for static typing'.  Therefore, getting the 
permanent doc 'right' is important.


The following naively plausible alternative does not work and cannot 
sensibly be made to work because the bare 'x' in the class scope, as 
opposed to a similar error within a method, causes NameError before the 
class is created.


@dataclass
class C:
x
y = 0

I think the doc should explicitly say that uninitialized fields require 
annotation with something (anything, not necessarily a type) simply to 
avoid NameError during class creation.  It may not be obvious to some 
readers why x:'anything' does not also raise NameError, but that was a 
different PEP, and the dataclass doc could here link to wherever 
name:annotation in bodies is explained.


--
Terry Jan Reedy


___
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

Re: [Python-Dev] Is static typing still optional?

[Steve Holden]

On Thu, Dec 21, 2017 at 7:55 PM, Terry Reedy  wrote:

> On 12/21/2017 9:23 AM, Eric V. Smith wrote:
>
>>
>>
>> On 12/21/17 6:25 AM, Sven R. Kunze wrote:
>>
>>> On 21.12.2017 11:22, Terry Reedy wrote:
>>>

 @dataclass
>> class C:
>>  a: int # integer field with no default
>>  b: float = 0.0 # float field with a default
>>
>> And the types will be recognized by type checkers such as mypy.
>>
>> And I think the non-typed examples should go first in the docs.
>>
>

>>> I still don't understand why "I don't care" can be defined by "leaving
>>> out"
>>>
>>> @dataclass
>>> class C:
>>>  b = 0.0 # float field with a default
>>>
>>
>> Because you can't know the order that x and y are defined in this example:
>>
>> class C:
>>  x: int
>>  y = 0
>>
>> 'x' is not in C.__dict__, and 'y' is not in C.__annotations__.
>>
>
>
​Solely because, annotations being optional, the interpreter is not allowed
to infer from its presence  that an annotated name should be ​allocated an
entry in __dict__, and clearly the value associated with it would be
problematical.

I think the understanding problem with this feature arises from two
> factors: using annotations to define possibly un-initialized slots is
> non-obvious; a new use of annotations for something other than static
> typing is a bit of a reversal of the recent pronouncement 'annotations
> should only be used for static typing'.  Therefore, getting the permanent
> doc 'right' is important.
>

​Indeed. So annotations are optional, except where they aren't?​


> The following naively plausible alternative does not work and cannot
> sensibly be made to work because the bare 'x' in the class scope, as
> opposed to a similar error within a method, causes NameError before the
> class is created.
>
> @dataclass
> class C:
> x
> y = 0
>
> ​Quite. Could this be handled the same way not-yet initilialised slots
are? (Pardon my ignornace).
​


> I think the doc should explicitly say that uninitialized fields require
> annotation with something (anything, not necessarily a type) simply to
> avoid NameError during class creation.  It may not be obvious to some
> readers why x:'anything' does not also raise NameError, but that was a
> different PEP, and the dataclass doc could here link to wherever
> name:annotation in bodies is explained.
>
>
​This contortion is why I feel a better solution would be desirable. Alas I
do not have one to hand.

regards
 Steve​
___
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

Re: [Python-Dev] Is static typing still optional?

[Chris Barker]

On Thu, Dec 21, 2017 at 11:55 AM, Terry Reedy  wrote:

I think the understanding problem with this feature arises from two
> factors: using annotations to define possibly un-initialized slots is
> non-obvious; a new use of annotations for something other than static
> typing is a bit of a reversal of the recent pronouncement 'annotations
> should only be used for static typing'.


you know, that may be where part of my confusion came from -- all the talk
lately has been about "type hints" and "type annotations" -- the idea of
"arbitrary annotations" has been lost.


> Therefore, getting the permanent doc 'right' is important.
>

yup.


> @dataclass
> class C:
> x
> y = 0
>
> I think the doc should explicitly say that uninitialized fields require
> annotation with something (anything, not necessarily a type) simply to
> avoid NameError during class creation.


would this be possible?

@dataclass
class C:
x:
y: = 0

That is -- the colon indicates an annotation, but in this case, it's a
"nothing" annotation.

It's a syntax error now, but would it be possible to change that? Or would
the parsing be ambiguous? particularly in other contexts.

of course, then we'd need something to store in as a "nothing" annotation
-- empty string? None? (but None might mean something) create yet anther
type for "nothing_annotation"

Hmm, I may have talked myself out of it

-CHB


-- 

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

Re: [Python-Dev] Is static typing still optional?

[MRAB]

On 2017-12-21 22:45, Chris Barker wrote:
On Thu, Dec 21, 2017 at 11:55 AM, Terry Reedy > wrote:


I think the understanding problem with this feature arises from two
factors: using annotations to define possibly un-initialized slots
is non-obvious; a new use of annotations for something other than
static typing is a bit of a reversal of the recent pronouncement
'annotations should only be used for static typing'. 



you know, that may be where part of my confusion came from -- all the 
talk lately has been about "type hints" and "type annotations" -- the 
idea of "arbitrary annotations" has been lost.


Therefore, getting the permanent doc 'right' is important.


yup.

@dataclass
class C:
     x
     y = 0

I think the doc should explicitly say that uninitialized fields
require annotation with something (anything, not necessarily a type)
simply to avoid NameError during class creation. 



would this be possible?

@dataclass
class C:
     x:
     y: = 0

That is -- the colon indicates an annotation, but in this case, it's a 
"nothing" annotation.




"..." or "pass", perhaps?

@dataclass
class C:
 x: ...
 y: ... = 0

or:

@dataclass
class C:
 x: pass
 y: pass = 0

It's a syntax error now, but would it be possible to change that? Or 
would the parsing be ambiguous? particularly in other contexts.


of course, then we'd need something to store in as a "nothing" 
annotation -- empty string? None? (but None might mean something) create 
yet anther type for "nothing_annotation"


Hmm, I may have talked myself out of it


___
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

[Python-Dev] pep-0557 dataclasses top level module vs part of collections?

[Gregory P. Smith]

It seems a suggested use is "from dataclasses import dataclass"

But people are already familiar with "from collections import namedtuple"
which suggests to me that "from collections import dataclass" would be a
more natural sounding API addition.

But the dataclasses module has additional APIs beyond @dataclass which
clearly do not belong at the top level in collections.

Idea: How about making the current dataclasses.dataclass decorator function
instead be a callable class instance (ie: it still functions as property,
todays dataclasses.dataclass becomes collections.dataclass.__call__) with
all of the current contents of the dataclasses module as attributes of a
collections.dataclass class/instance singleton?

It feels like a more natural API to me:

from collections import dataclass
@dataclass
class ...

and the following APIs show up on dataclass itself:

dataclass.Field, dataclass.field, dataclass.fields, dataclass.make,
dataclass.astuple, dataclass.replace, dataclass.asdict,
dataclass.FrozenInstanceError, dataclass.InitVar

instead of being in a separate dataclasses module and being a different
style of thing to import than namedtuple.

[ if this was discussed earlier for this pep and rejected and I missed it,
my apologies, just drop me a reference to that thread if you've got one ]

This isn't a blocker for me.  I like having a dataclass implementation no
matter how we arrange it.  If we go with what's checked in today, a top
level dataclasses module, so be it.  I'm not going to bikeshed this to
death it just feels odd to have such an API outside of collections but
figured it was worth suggesting.

Part of me just doesn't like the plural dataclasses module name.  I can get
over that.

-gps
___
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

Re: [Python-Dev] Is static typing still optional?

[Gregory P. Smith]

On Thu, Dec 21, 2017 at 3:10 PM MRAB  wrote:

> On 2017-12-21 22:45, Chris Barker wrote:
> > On Thu, Dec 21, 2017 at 11:55 AM, Terry Reedy  > > wrote:
> >
> > I think the understanding problem with this feature arises from two
> > factors: using annotations to define possibly un-initialized slots
> > is non-obvious; a new use of annotations for something other than
> > static typing is a bit of a reversal of the recent pronouncement
> > 'annotations should only be used for static typing'.
> >
> >
> > you know, that may be where part of my confusion came from -- all the
> > talk lately has been about "type hints" and "type annotations" -- the
> > idea of "arbitrary annotations" has been lost.
> >
> > Therefore, getting the permanent doc 'right' is important.
> >
> >
> > yup.
> >
> > @dataclass
> > class C:
> >  x
> >  y = 0
> >
> > I think the doc should explicitly say that uninitialized fields
> > require annotation with something (anything, not necessarily a type)
> > simply to avoid NameError during class creation.
> >
> >
> > would this be possible?
> >
> > @dataclass
> > class C:
> >  x:
> >  y: = 0
> >
> > That is -- the colon indicates an annotation, but in this case, it's a
> > "nothing" annotation.
> >
> >
> "..." or "pass", perhaps?
>
> @dataclass
> class C:
>   x: ...
>   y: ... = 0
>
> or:
>
> @dataclass
> class C:
>   x: pass
>   y: pass = 0
>

pass does not currently parse in that context.  Otherwise I was thinking
the same thing.  But we already have ... which does - so I'd suggest that
for people who are averse to importing anything from typing and using the
also quite readable Any.  (ie: document this as the expected practice with
both having the same meaning)

While I consider the annotation to be a good feature of data classes, it
seems worth documenting that people not running a type analyzer should
avoid declaring a type. A worse thing than no-type being specified is a
wrong type being specified. That appearing in a library will break people
who need their code to pass the analyzer and pytype, mypy, et. al. could be
forced to implement a typeshed.pypi of sorts containing blacklists of known
bad annotations in public libraries and/or actually correct type
specification overrides for them.

As for problems with order, if we were to accept

@dataclass
class Spam:
beans = True
ham: bool

style instead, would it be objectionable to require keyword arguments only
for dataclass __init__ methods?  That'd get rid of the need to care about
order.  (but would annoy people with small 2-3 element data classes... so
I'm assuming this idea is already rejected)

-gps


>
> > It's a syntax error now, but would it be possible to change that? Or
> > would the parsing be ambiguous? particularly in other contexts.
> >
> > of course, then we'd need something to store in as a "nothing"
> > annotation -- empty string? None? (but None might mean something) create
> > yet anther type for "nothing_annotation"
> >
> > Hmm, I may have talked myself out of it
> >
> ___
> 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/greg%40krypto.org
>
___
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

Re: [Python-Dev] Is static typing still optional?

[Chris Barker]

On Thu, Dec 21, 2017 at 3:36 PM, Gregory P. Smith  wrote:


>  But we already have ... which does - so I'd suggest that for people who
> are averse to importing anything from typing and using the also quite
> readable Any.  (ie: document this as the expected practice with both having
> the same meaning)
>

I don't think they do, actually - I haven't been following the typing
discussions, but someone in this thread said that ... means "use the type
of teh default" or something like that.


> While I consider the annotation to be a good feature of data classes, it
> seems worth documenting that people not running a type analyzer should
> avoid declaring a type.
>

+1 !


> A worse thing than no-type being specified is a wrong type being
> specified. That appearing in a library will break people who need their
> code to pass the analyzer and pytype, mypy, et. al. could be forced to
> implement a typeshed.pypi of sorts containing blacklists of known bad
> annotations in public libraries and/or actually correct type specification
> overrides for them.
>

and the wrong type could be very common -- folks using "int", when float
would do just fine, or "list" when any iterable would do, the list goes on
and on. Typing is actually pretty complex in Python -- it's hard to get
right, and if you aren't actually running a type checker, you'd never know.

One challenge here is that annotations, per se, aren't only for typing. Bu
tit would be nice if a type checker could see whatever "non-type" is
recommended for dataclasses as "type not specified". Does an ellipses spell
that? or None? or anything that doesn't have to be imported from typing :-)

As for problems with order, if we were to accept
>
> @dataclass
> class Spam:
> beans = True
> ham: bool
>
> style instead, would it be objectionable to require keyword arguments only
> for dataclass __init__ methods?  That'd get rid of the need to care about
> order.
>

wouldn't  that make the "ham: bool" legal -- i.e. no default?

-CHB

-- 

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

Re: [Python-Dev] is typing optional in dataclasses?

[Gregory P. Smith]

(subject for this sub-thread updated)

On Thu, Dec 21, 2017 at 4:08 PM Chris Barker  wrote:

> On Thu, Dec 21, 2017 at 3:36 PM, Gregory P. Smith  wrote:
>
>
>>  But we already have ... which does - so I'd suggest that for people who
>> are averse to importing anything from typing and using the also quite
>> readable Any.  (ie: document this as the expected practice with both having
>> the same meaning)
>>
>
> I don't think they do, actually - I haven't been following the typing
> discussions, but someone in this thread said that ... means "use the type
> of teh default" or something like that.
>

indeed, they may not.  though if that is the definition is it reasonable to
say that type analyzers recognize the potential recursive meaning when the
_default_ is ... and treat that as Any?

another option that crossed my mind was "a: 10" without using =.  but that
really abuses __attributes__ by sticking the default value in there which
the @dataclass decorator would presumably immediately need to undo and fix
up before returning the class.  but I don't find assigning a value without
an = sign to be pythonic so please lets not do that! :)


>
>> While I consider the annotation to be a good feature of data classes, it
>> seems worth documenting that people not running a type analyzer should
>> avoid declaring a type.
>>
>
> +1 !
>
>
>> A worse thing than no-type being specified is a wrong type being
>> specified. That appearing in a library will break people who need their
>> code to pass the analyzer and pytype, mypy, et. al. could be forced to
>> implement a typeshed.pypi of sorts containing blacklists of known bad
>> annotations in public libraries and/or actually correct type specification
>> overrides for them.
>>
>
> and the wrong type could be very common -- folks using "int", when float
> would do just fine, or "list" when any iterable would do, the list goes on
> and on. Typing is actually pretty complex in Python -- it's hard to get
> right, and if you aren't actually running a type checker, you'd never know.
>

Yeah, that is true.  int vs float vs Number, etc.  It suggests means we
shouldn't worry about this problem at all for the pep 557 dataclasses
implementation.  Type analyzers by that definition are going to need to
deal with incorrect annotations in data classes as a result no matter what
so they'll deal with that regardless of how we say dataclasses should work.

-gps


>
> One challenge here is that annotations, per se, aren't only for typing. Bu
> tit would be nice if a type checker could see whatever "non-type" is
> recommended for dataclasses as "type not specified". Does an ellipses spell
> that? or None? or anything that doesn't have to be imported from typing :-)
>
> As for problems with order, if we were to accept
>>
>> @dataclass
>> class Spam:
>> beans = True
>> ham: bool
>>
>> style instead, would it be objectionable to require keyword arguments
>> only for dataclass __init__ methods?  That'd get rid of the need to care
>> about order.
>>
>
> wouldn't  that make the "ham: bool" legal -- i.e. no default?
>
> -CHB
>
> --
>
> 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

Re: [Python-Dev] is typing optional in dataclasses?

[MRAB]

On 2017-12-22 00:19, Gregory P. Smith wrote:

(subject for this sub-thread updated)

On Thu, Dec 21, 2017 at 4:08 PM Chris Barker > wrote:


On Thu, Dec 21, 2017 at 3:36 PM, Gregory P. Smith mailto:g...@krypto.org>> wrote:

 But we already have ... which does - so I'd suggest that for
people who are averse to importing anything from typing and
using the also quite readable Any.  (ie: document this as the
expected practice with both having the same meaning)


I don't think they do, actually - I haven't been following the
typing discussions, but someone in this thread said that ... means
"use the type of teh default" or something like that.


indeed, they may not.  though if that is the definition is it 
reasonable to say that type analyzers recognize the potential 
recursive meaning when the _default_ is ... and treat that as Any?


another option that crossed my mind was "a: 10" without using =.  but 
that really abuses __attributes__ by sticking the default value in 
there which the @dataclass decorator would presumably immediately need 
to undo and fix up before returning the class.  but I don't find 
assigning a value without an = sign to be pythonic so please lets not 
do that! :)


If you allowed "a: 10" (an int value), then you might also allow "a: 
'foo'" (a string value), but wouldn't that be interpreted as a type 
called "foo"?


If you can't have a string value, then you shouldn't have an int value 
either.


[snip]

___
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

Re: [Python-Dev] is typing optional in dataclasses?

[Eric V. Smith]

On 12/21/2017 7:55 PM, MRAB wrote:

On 2017-12-22 00:19, Gregory P. Smith wrote:

(subject for this sub-thread updated)

On Thu, Dec 21, 2017 at 4:08 PM Chris Barker > wrote:


    On Thu, Dec 21, 2017 at 3:36 PM, Gregory P. Smith mailto:g...@krypto.org>> wrote:

     But we already have ... which does - so I'd suggest that for
    people who are averse to importing anything from typing and
    using the also quite readable Any.  (ie: document this as the
    expected practice with both having the same meaning)


    I don't think they do, actually - I haven't been following the
    typing discussions, but someone in this thread said that ... means
    "use the type of teh default" or something like that.


indeed, they may not.  though if that is the definition is it 
reasonable to say that type analyzers recognize the potential 
recursive meaning when the _default_ is ... and treat that as Any?


another option that crossed my mind was "a: 10" without using =.  but 
that really abuses __attributes__ by sticking the default value in 
there which the @dataclass decorator would presumably immediately need 
to undo and fix up before returning the class.  but I don't find 
assigning a value without an = sign to be pythonic so please lets not 
do that! :)


If you allowed "a: 10" (an int value), then you might also allow "a: 
'foo'" (a string value), but wouldn't that be interpreted as a type 
called "foo"?


As far as dataclasses are concerned, both of these are allowed, and 
since neither is ClassVar or InitvVar, they're ignored. Type checkers 
would object to the int, and I assume also the string unless there was a 
type foo defined. See 
https://www.python.org/dev/peps/pep-0484/#the-problem-of-forward-declarations 
and typing.get_type_hints().


It's a bug that dataclasses currently does not inspect string 
annotations to see if they're actually ClassVar or InitVar declarations. 
PEP 563 makes it critical (and not merely important) to look at the 
string annotations. Whether or not that involves typing.get_type_hints() 
or not, I haven't yet decided. I'm waiting for PEPs 563 and 560 to be 
implemented before taking another look at it.


Eric.



If you can't have a string value, then you shouldn't have an int value 
either.


[snip]

___
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/eric%2Ba-python-dev%40trueblade.com 



___
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

Re: [Python-Dev] pep-0557 dataclasses top level module vs part of collections?

[Eric Snow]

On Thu, Dec 21, 2017 at 4:21 PM, Gregory P. Smith  wrote:
> It seems a suggested use is "from dataclasses import dataclass"
>
> But people are already familiar with "from collections import namedtuple"
> which suggests to me that "from collections import dataclass" would be a
> more natural sounding API addition.

FWIW, I'd consider this a good time to add a new top-level
classtools/classutils module (a la functools).  There are plenty of
other things that would fit there that we've shoved into other places.

-eric
___
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

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Stephen J. Turnbull]

Chris Barker writes:

 > Nathaniel Smith has pointed out that eval(pprint(a_dict)) is
 > supposed to return the same dict -- so documented behavior may
 > already be broken.

Sure, but that's because we put shoes on a snake.  Why anybody expects
no impediment to slithering, I don't know!

I understand the motivation to guarantee order, but it's a programmer
convenience that has nothing to do with the idea of mapping, and the
particular (insertion) order is very special and usually neither
relevant nor reproducible.  I have no problem whatsoever with just
documenting any failure to preserve order while reproducing dicts,
*except* that a process that inserts keys in the same order had better
result in the same insertion order.

Steve

___
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

Re: [Python-Dev] f-strings

[Stephen J. Turnbull]

Eric Fahlgren writes:
 > On Tue, Dec 19, 2017 at 8:47 AM, Stephen J. Turnbull <
 > turnbull.stephen...@u.tsukuba.ac.jp> wrote:
 > 
 > > If I were Bach, I'd compose a more-itertools-like module to be named
 > > Variations_on_the_F_String. :-)
 > >
 > 
 > Would that be P.D.Q. Bach to whom you are referring?

It's a curried function, supply your own arguments.  "No, I won't!"

Steve

___
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

Re: [Python-Dev] pep-0557 dataclasses top level module vs part of collections?

[Raymond Hettinger]

> On Dec 21, 2017, at 3:21 PM, Gregory P. Smith  wrote:
> 
> It seems a suggested use is "from dataclasses import dataclass"
> 
> But people are already familiar with "from collections import namedtuple" 
> which suggests to me that "from collections import dataclass" would be a more 
> natural sounding API addition.

This might make sense if it were a single self contained function.  But 
dataclasses are their own little ecosystem that warrants its own module 
namespace:

>>> import dataclasses
>>> dataclasses.__all__
['dataclass', 'field', 'FrozenInstanceError', 'InitVar', 'fields', 'asdict', 
'astuple', 'make_dataclass', 'replace']

Also, remember that dataclasses have a dual role as a data holder (which is 
collection-like) and as a generator of boilerplate code (which is more like 
functools.total_ordering).

I support Eric's decision to make this a separate module.


Raymond


___
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