Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #64049
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: Chanelling Guido - dict subclasses |
| Date | 2014-01-16 17:17 +1300 |
| Message-ID | <bjp4qqFi2tjU1@mid.individual.net> (permalink) |
| References | <52d5e408$0$29970$c3e8da3$5496439d@news.astraweb.com> <mailman.5562.1389840613.18130.python-list@python.org> |
Daniel da Silva wrote: > Just to be pedantic, this /is/ a violation of the Liskov Substution > Principle. According to Wikipedia, the principle states: > > if S is a subtype <http://en.wikipedia.org/wiki/Subtype> of T, then > objects of type <http://en.wikipedia.org/wiki/Datatype> T may be > replaced with objects of type S (i.e., objects of type S may > be /substituted/ for objects of type T) without altering any of the > desirable properties of that program Something everyone seems to miss when they quote the LSP is that what the "desirable properties of the program" are *depends on the program*. Whenever you create a subclass, there is always *some* difference between the behaviour of the subclass and the base class, otherwise there would be no point in having the subclass. Whether that difference has any bad consequences for the program depends on what the program does with the objects. So you can't just look at S and T in isolation and decide whether they satisfy the LSP or not. You need to consider them in context. In Python, there's a special problem with subclassing dicts in particular: some of the core interpreter code assumes a plain dict and bypasses the lookup of __getitem__ and __setitem__, going straight to the C-level implementations. If you tried to use a dict subclass in that context that overrode those methods, your overridden versions wouldn't get called. But if you never use your dict subclass in that way, there is no problem. Or if you don't override those particular methods, there's no problem either. If you're giving advice to someone who isn't aware of all the fine details, "don't subclass dict" is probably the safest thing to say. But there are legitimate use cases for it if you know what you're doing. The other issue is that people are often tempted to subclass dict in order to implement what isn't really a dict at all, but just a custom mapping type. The downside to that is that you end up inheriting a bunch of dict-specific methods that don't really make sense for your type. In that case it's usually better to start with a fresh class that *uses* a dict as part of its implementation, and only exposes the methods that are really needed. -- Greg
Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread
Chanelling Guido - dict subclasses Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-15 01:27 +0000
Re: Chanelling Guido - dict subclasses Ned Batchelder <ned@nedbatchelder.com> - 2014-01-14 21:04 -0500
Re: Chanelling Guido - dict subclasses Terry Reedy <tjreedy@udel.edu> - 2014-01-14 22:48 -0500
Re: Chanelling Guido - dict subclasses F <f@hop2it.be> - 2014-01-15 07:00 +0000
Re: Chanelling Guido - dict subclasses Peter Otten <__peter__@web.de> - 2014-01-15 09:40 +0100
Re: Chanelling Guido - dict subclasses John Ladasky <john_ladasky@sbcglobal.net> - 2014-01-15 08:51 -0800
Re: Chanelling Guido - dict subclasses Peter Otten <__peter__@web.de> - 2014-01-15 19:35 +0100
Re: Chanelling Guido - dict subclasses Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-01-15 22:30 -0800
Re: Chanelling Guido - dict subclasses Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-15 09:10 +0000
Re: Chanelling Guido - dict subclasses Tim Chase <python.list@tim.thechases.com> - 2014-01-15 05:03 -0600
Re: Chanelling Guido - dict subclasses Daniel da Silva <var.mail.daniel@gmail.com> - 2014-01-15 19:50 -0500
Re: Chanelling Guido - dict subclasses Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-01-16 17:17 +1300
csiph-web