[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling
Rick Teachey <ri...@teachey.org> added the comment: Lending my voice to the suggestion of limiting the class attribute check to `typing.ClassVar` and `ClassVar`. It can always be expanded later if it is needed. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling
Rick Teachey <ri...@teachey.org> added the comment: > Is there any scenario where the following code would be useful... Perhaps if someone, in search of a speedup, were sort of rolling their own lighter-weight equivalent to the typing module (in order to avoid importing the full typing module), but duck typed enough to fool the average type checker? Is that possible? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33452] add user notification that parent init will not be called in dataclass init method
Rick Teachey <ri...@teachey.org> added the comment:
The init method that comes up for int, str, float, etc is just the object init:
assert int.__init__ is object.__init__
Probably the thing to do is grab any init methods that aren't the
object.__init__ while stripping out the dataclass-created init methods? Maybe
something like:
import warnings
if cls.__dataclass_params__.init:
for pcls in cls.mro():
if pcls.__init__ is not object.__init__:
try:
d_params = getattr(pcls, "__dataclass_params__")
except AttributeError:
warnings.warn('Found a not called init')
else:
if not d_params.init:
warnings.warn('Found a custom dataclass init')
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33452>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33453] from __future__ import annotations breaks dataclasses ClassVar handling
Rick Teachey <ri...@teachey.org> added the comment: Sorry, mean to say it works just fine *without* the import. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33453] from __future__ import annotations breaks dataclasses ClassVar handling
Rick Teachey <ri...@teachey.org> added the comment: To be clear: it works just fine with the annotations import. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33453] from __future__ import annotations breaks dataclasses ClassVar handling
New submission from Rick Teachey <ri...@teachey.org>:
This is broken in 3.7 (both beta 3 and 4):
from __future__ import annotations
from dataclasses import dataclass
from typing import ClassVar, Any
@dataclass
class C():
class_var: ClassVar[Any] = object()
data: str
Traceback:
Traceback (most recent call last):
File "", line 1, in
File
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py",
line 850, in dataclass
return wrap(_cls)
File
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py",
line 842, in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen)
File
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py",
line 763, in _process_class
else 'self',
File
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py",
line 442, in _init_fn
raise TypeError(f'non-default argument {f.name!r} '
TypeError: non-default argument 'data' follows default argument
--
components: Library (Lib)
messages: 316333
nosy: Ricyteach, eric.smith
priority: normal
severity: normal
status: open
title: from __future__ import annotations breaks dataclasses ClassVar handling
type: behavior
versions: Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33453>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33452] add user notification that parent init will not be called in dataclass init method
New submission from Rick Teachey <ri...@teachey.org>: The dataclasses module is incredibly easy to use. This is a good thing. BUT one downside is it will definitely be utilized by people who don't have a thorough understanding of how it does what it does. Even for me, despite having a very good understanding of how it works, after heavily using it on a project for about 3 weeks now I made a mistake like the one below: class ImportantMixin: def __init__(self): super().__init__() important_task() @dataclass class NaiveDClass(ImportantMixin): data1 = int data2 = int I then went on along my merry way. Obviously, ImportantMixin.__init__ never gets called and I didn't realize this until it was a bigger problem than it should have been (should have written better tests! but I digress). It would seem like a good idea for the dataclasses module to let the user know they did this, probably via the warning system. Seems like it would be relatively easy to do: if there is an init method being create, just inspect the MRO for any previously defined init methods that weren't created by dataclasses. Thanks. -- components: Library (Lib) messages: 316331 nosy: Ricyteach, eric.smith priority: normal severity: normal status: open title: add user notification that parent init will not be called in dataclass init method type: enhancement versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33328] pdb error when stepping through generator
Rick Teachey <ri...@teachey.org> added the comment: Closed as duplicate of issue 13044. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33328] pdb error when stepping through generator
Rick Teachey <ri...@teachey.org> added the comment: I am on Anaconda 4.5.1 on Windows 10 (Python 3.6.5). I have confirmed that I DO get the error on another machine with the same version installed, so the lack of an error seems specific to my current machine. I do not know what could be causing this; it is very odd. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33328] pdb error when stepping through generator
Change by Rick Teachey <ri...@teachey.org>: -- components: +Library (Lib) type: -> behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33328] pdb error when stepping through generator
Rick Teachey <ri...@teachey.org> added the comment: The interactive session result is below: GeneratorExit Exception ignored in: Traceback (most recent call last): File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\types.py", line 27, in _ag File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 90, in trace_dispatch File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 128, in dispatch_call File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 250, in break_anywhere File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 49, in canonic AttributeError: 'NoneType' object has no attribute 'abspath' -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33328] pdb error when stepping through generator
New submission from Rick Teachey <ri...@teachey.org>: Hello: The attached python file runs a pdb interactive session for a generator. It produces an error in Python 3.7 Beta 3, but no error in 3.6. I searched for this issue and there do seem to be things that are related to it already, but I haven't investigated the cause of this issue and am not acquainted with the details of the pdb module, so I was unable to determine whether previous reports discuss this same problem. -- files: demo.py messages: 315586 nosy: Ricyteach priority: normal severity: normal status: open title: pdb error when stepping through generator versions: Python 3.7 Added file: https://bugs.python.org/file47545/demo.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class
Rick Teachey <ri...@teachey.org> added the comment: Thank you; I gave it a go. Hopefully didn't cause too much additional work for someone. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class
Change by Rick Teachey <ri...@teachey.org>: -- keywords: +patch pull_requests: +6033 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
Rick Teachey <ri...@teachey.org> added the comment: I'll also say: one of the biggest reasons I was excited to read the `dataclasses` PEP was because I thought "AWESOME! Now I can delete all of the stupid boilerplate __init__ and __repr__ methods for those `typing.Sequences`, `typing.Mapping`, etc etc subclasses!" -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
Rick Teachey <ri...@teachey.org> added the comment:
> passing keyword arguments to metaclass will be much more rare for dataclasses
> than passing a ready namespace
The impetus of my running into these issues was assuming that things like
`Generic[MyTypeVar]` would "just work" with `make_dataclass`, which seemed like
a valid assumption since the class creation approach made heavy use of by
`dataclasses` implies this:
@dataclass
class MyDclass(Generic[MyTypeVar]):
var: MyTypeVar
The fact that I cannot do this, then, without error is surprising:
MyDclass = make_dataclass("MyDclass", (("var", MyTypeVar),),
bases=(Generic[MyTypeVar],))
I'm not stating it HAS to be fixed. Maybe it doesn't have to. But to me, the
above seems like the reason to do it if it's going to be done.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33188>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
Rick Teachey <ri...@teachey.org> added the comment: Eric: see also Ivan's comment on Issue 33190, which will factor into the solution to this I think. It seems you can't just pass the `namespace` to the `kwds` argument (as I have done in my solution above). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class
Rick Teachey <ri...@teachey.org> added the comment: Excellent; thank you very much for the explanation. I have never done a PR on a project this size but I'll give it a try. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class
New submission from Rick Teachey <ri...@teachey.org>: I am pretty sure this is a bug. If not I apologize. Say I want to dynamically create a new `C` class, with base class `MyABC` (and dynamically assigned abstract method `m`). This works fine if I use `type`, but if I use `new_class`, the keyword argument to the `m` method implementation gets lost somewhere in the call to `ABCMeta.__prepare___`. I've attached a file to demo. Thanks. -- components: Library (Lib) files: abcmeta_prepare.py messages: 314714 nosy: Ricyteach, levkivskyi priority: normal severity: normal status: open title: problem with ABCMeta.__prepare__ when called after types.new_class type: behavior versions: Python 3.7, Python 3.8 Added file: https://bugs.python.org/file47509/abcmeta_prepare.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
Rick Teachey <ri...@teachey.org> added the comment:
Same error on 3.7.
Probably getting beyond my knowledge here but from the error message, it seems
like the answer is simply that:
type('MyChild', (MyParent[int],), {})
...is just the wrong way to make a new `type` when utilizing type variables.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33188>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
Rick Teachey <ri...@teachey.org> added the comment: Sorry: to be clear, the error only occurs when attempting to create the class using `make_dataclass`. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError
New submission from Rick Teachey <ri...@teachey.org>: I'm getting the following error at when attempting to create a new `dataclass` with any base class that is supplied a type variable: TypeError: type() doesn't support MRO entry resolution; use types.new_class() In principle, it seems like this shouldn't cause any problems, since this works as expected: @dataclass class MyClass(Generic[MyTypeVar]): pass The problem seems to be the call to `type` in `make_dataclass` for instantiating the class object, since `type` doesn't support type variables. If I replace the `dataclass` line that produces the error with the following code block, it seems to work: try: cls = type(cls_name, bases, namespace) except TypeError: cls = types.new_class(cls_name, bases, namespace) I haven't tested, but it might be possible to just remove the call to `type` altogether. I've attached a file demonstrating the issue. -- components: Library (Lib) files: dataclass_metaclass_issue.py messages: 314703 nosy: Ricyteach, eric.smith priority: normal severity: normal status: open title: dataclass MRO entry resolution for type variable metaclasses: TypeError type: behavior versions: Python 3.7, Python 3.8 Added file: https://bugs.python.org/file47508/dataclass_metaclass_issue.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey <ri...@teachey.org> added the comment: Looks great to me. Thanks! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey <ri...@teachey.org> added the comment: Yeah and I think lines 2709-2712 of TestDescriptors also needs removed. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey <ri...@teachey.org> added the comment:
Eric, looking at the PR; note that if you do this for the __set_name__ check:
if inspect.ismethoddescriptor(self.default):
...an object like the one below will not get its __set_name__ called, even
though PEP 487 says it should:
class D:
def __set_name__(self, o, n):
self.name = n
class C:
d: int = D()
if __name__ == "__main__":
print(f"C.d.name = {C.d.name}") # __set_name__ was called
assert inspect.ismethoddescriptor(C.d) # Error
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33141>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey <ri...@teachey.org> added the comment: I suppose one downside of that solution is __set_name__ will be called for every Field whether or not it is need. Probably can't be helped without major complications. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey <ri...@teachey.org> added the comment: Sounds like a relatively easy solution then. Hopefully it makes the beta 3 so I can use it immediately- thanks! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
Rick Teachey <ri...@teachey.org> added the comment: hmmm... if I check the C.d class attribute it seems to return the descriptor instance object (not a field object) before any C instances have been created. i guess this is just a part of how the dataclass implementation works. i didn't realize there's nothing "special" going on with descriptors here- the descriptors "just work" by virtue of being set to the class attribute at creation time. interesting. maybe because of this descriptors should short-circuit the field creation process entirely? that would be a shame though. having the option of auto-including a descriptor in the class repr turns out to be very useful and i'm already playing around with it in a project. one idea: what if it there were a keyword argument to mark a field as a descriptor, allowing tje descriptor to be set at type creation? this would need to disallow init=True, i think. and setting a field default to a descriptor class would then raise a type error. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler On Mon, Mar 26, 2018 at 6:47 AM, Eric V. Smith <rep...@bugs.python.org> wrote: > > Eric V. Smith <e...@trueblade.com> added the comment: > > I suppose I could, when overwriting the class member, check for > inspect.ismethoddescriptor and call __set_name__ myself. > > -- > components: +Library (Lib) > versions: +Python 3.8 > > ___ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue33141> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields
New submission from Rick Teachey <ri...@teachey.org>: Summary: The descriptor `__set_name__` functionality (introduced in Python 3.6) does not seem to be working correctly for `dataclass.Field` objects with a default pointing to a descriptor. I have attached a file demonstrating the trouble. Details: If I set a `dataclass` class object field to a `dataclass.field` with a descriptor object for the `default` argument, the descriptor's `__set_name__` method is not called during initialization. This is unexpected because descriptors themselves seem to work pretty much flawlessly, otherwise. (Bravo on that by the way! Working descriptors isn't mentioned at all in the PEP as a feature but I was very pleased to see them working!!) System details: Python 3.7b02 Windows 10 PyCharm Community Edition btw this is my first ever Python bug report; I hope I did a good job. -- files: broken__set_name__.py messages: 314438 nosy: Ricyteach, eric.smith priority: normal severity: normal status: open title: descriptor __set_name__ feature broken for dataclass descriptor fields type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file47499/broken__set_name__.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
