+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 <carl at 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 at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/lukasz%40langa.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: <http://mail.python.org/pipermail/python-dev/attachments/20171130/22765860/attachment-0001.sig>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4