+1 to (3), I like the type error idea, too. I don't care much about naming... but if I were to bikeshed this, I'd go for
isdataclass (like issubclass) isdatainstance (like isinstance) - Ł > On Nov 30, 2017, at 12:35 PM, Carl Meyer <c...@oddbird.net> wrote: > > On 11/29/2017 05:02 PM, Guido van Rossum wrote: >> I tried to look up the discussion but didn't find much except that you >> flagged this as an issue. To repeat, your concern is that isdataclass() >> applies to *instances*, not classes, which is how Eric has designed it, >> but you worry that either through the name or just because people don't >> read the docs it will be confusing. What do you suppose we do? I think >> making it work for classes as well as for instances would cause another >> category of bugs (confusion between cases where a class is needed vs. an >> instance abound in other situations -- we don't want to add to that). >> Maybe it should raise TypeError when passed a class (unless its >> metaclass is a dataclass)? Maybe it should be renamed to >> isdataclassinstance()? That's a mouthful, but I don't know how common >> the need to call this is, and people who call it a lot can define their >> own shorter alias. > > Yeah, I didn't propose a specific fix because I think there are several > options (all mentioned in this thread already), and I don't really have > strong feelings about them: > > 1) Keep the existing function and name, let it handle either classes or > instances. I agree that this is probably not the best option available, > though IMO it's still marginally better than the status quo). > > 2) Punt the problem by removing the function; don't add it to the public > API at all until we have demonstrated demand. > > 3) Rename it to "is_dataclass_instance" (and maybe also keep a separate > "is_dataclass" for testing classes directly). (Then there's also the > choice about raising TypeError vs just returning False if a function is > given the wrong type; I think TypeError is better.) > > Carl > > > > _______________________________________________ > 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/lukasz%40langa.pl
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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
