[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Eric V. Smith]

Eric V. Smith  added the comment:

Correct. I'm working on that one now. I'll open it tonight or tomorrow.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

@Eric
> I'm closing this, and will open another issue to raise an error for: ...

I think we also need a separate issue for not overriding __repr__ etc, if 
'__repr__' in cls.__dict__.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Eric V. Smith]

Eric V. Smith  added the comment:

I'm closing this, and will open another issue to raise an error for:

@dataclass
class C:
x = field()

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> There is no real conflict with PEP 526 though. PEP 526 introduces ClassVar so 
> the type checker can be made to understand. PEP 557 allows omitting ClassVar 
> in case you don't care about type checkers. So I think we should stick with 
> the current spec of PEP 557 (which lets you omit ClassVar), except for this 
> special case: ...

OK.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Guido van Rossum]

Guido van Rossum  added the comment:

> > I liked the original design better, where things without annotations would 
> > just be ignored. What changed?

> With the original proposal the ignored variables without annotations will 
> behave as class variables. This "conflicts" with PEP 526 which requires class 
> variables to be annotated with ClassVar[...]. On the other hand some people 
> may be unhappy that they need to import `typing` to define a class variable 
> in a dataclass. So this is a convenience vs consistence question. I am more 
> in favour of consistence here, but only +0.

There is no real conflict with PEP 526 though. PEP 526 introduces ClassVar so 
the type checker can be made to understand. PEP 557 allows omitting ClassVar in 
case you don't care about type checkers. So I think we should stick with the 
current spec of PEP 557 (which lets you omit ClassVar), except for this special 
case:

> I still think that flagging this
> 
> @dataclass
> class C:
> x = field()
> 
> is important, since simply ignoring a ``field()`` will be too confusing 
> (especially for ``attrs`` users).

Agreed. That's a special case and I'm fine with flagging it as an error.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Just to clarify the previous comment, I still think that flagging this

@dataclass
class C:
x = field()

is important, since simply ignoring a ``field()`` will be too confusing 
(especially for ``attrs`` users).

The previous comment is about

@dataclass
class C:
x = 42

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> I liked the original design better, where things without annotations would 
> just be ignored. What changed?

With the original proposal the ignored variables without annotations will 
behave as class variables. This "conflicts" with PEP 526 which requires class 
variables to be annotated with ClassVar[...]. On the other hand some people may 
be unhappy that they need to import `typing` to define a class variable in a 
dataclass. So this is a convenience vs consistence question. I am more in 
favour of consistence here, but only +0.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Guido van Rossum]

Guido van Rossum  added the comment:

I liked the original design better, where things without annotations would
just be ignored. What changed?

On Dec 27, 2017 5:19 PM, "Ivan Levkivskyi"  wrote:

>
> Ivan Levkivskyi  added the comment:
>
> > I'm not sure I understand the distinction.
>
> Initially I thought about only flagging code like this:
>
> @dataclass
> class C:
> x = field()
>
> But not this:
>
> @dataclass
> class C:
> x = 42
>
> Now I think we should probably flag both as errors.
>
> > How do we only pick out `y` and probably `prop`, and ignore the rest,
> without being overly fragile to new things being added? I guess ignoring
> dunders and things in `__annotations__`. Is that close enough?
>
> We had a similar problem while developing Protocol class (PEP 544).
> Currently we just a have a whitelist of names that are skipped:
>
> '__abstractmethods__', '__annotations__', '__weakref__', '__dict__',
> '__slots__', '__doc__', '__module__'
>
> (plus some internal typing API names)
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> I'm not sure I understand the distinction.

Initially I thought about only flagging code like this:

@dataclass
class C:
x = field()

But not this:

@dataclass
class C:
x = 42

Now I think we should probably flag both as errors.

> How do we only pick out `y` and probably `prop`, and ignore the rest, without 
> being overly fragile to new things being added? I guess ignoring dunders and 
> things in `__annotations__`. Is that close enough?

We had a similar problem while developing Protocol class (PEP 544). Currently 
we just a have a whitelist of names that are skipped:

'__abstractmethods__', '__annotations__', '__weakref__', '__dict__',
'__slots__', '__doc__', '__module__'

(plus some internal typing API names)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Eric V. Smith]

Eric V. Smith  added the comment:

I'm not sure I understand the distinction. You have to look through everything 
in `__dict__`, then exclude those things that are any type of field (so, real 
fields or pseudo-fields). Those are the things that are in `__annotations__`, 
anyway.

The trick is what else to exclude.  In this class:

class C:
x: int = 0
y = 0

def func(self): pass

@staticmethod
def staticmeth() : pass

@classmethod
def classmeth(cls) : pass

@property
def prop(self): pass

These are the non-callables:

print([k for k in C.__dict__ if not callable(getattr(C, k))])

['__module__', '__annotations__', 'x', 'y', 'prop', '__dict__', '__weakref__', 
'__doc__']

How do we only pick out `y` and probably `prop`, and ignore the rest, without 
being overly fragile to new things being added? I guess ignoring dunders and 
things in `__annotations__`. Is that close enough?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

A possible question here is should we give an error for any non-callable name 
in `__dict__` which is not in `__annotations__` or only for `Field`s?

After some thinking I am actually leaning towards the first option.

--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

[Eric V. Smith]

New submission from Eric V. Smith :

For this class:

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

Generate a TypeError. 'y' is not a field (as defined by @dataclass). It should 
either be a regular field (by giving it a type annotation) or a ClassVar field.

--
assignee: eric.smith
components: Library (Lib)
messages: 309065
nosy: eric.smith
priority: normal
severity: normal
status: open
title: dataclasses: make it an error to have initialized non-fields in a 
dataclass
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com