This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: set.__or__, __and__, etc create subclass types, but ignore __new__
Type: Stage:
Components: Versions:
process
Status: closed Resolution: out of date
Dependencies: Superseder: A subclass of set doesn't always have __init__ called.
View: 1721812
Assigned To: Nosy List: Jon.Obermark, amaury.forgeotdarc, benjamin.peterson, r.david.murray
Priority: normal Keywords:

Created on 2012-09-07 15:44 by Jon.Obermark, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg169986 - (view) Author: Jon Obermark (Jon.Obermark) Date: 2012-09-07 15:44
If they are not going to call the __metaclass__ or the class __new__, then they should return `set` objects instead of subclass objects, so that it is clear what is going on.

As it is, the results of set operations receive some subclass information but not all.  So they are not really obeying the notion of a subclass: the results are neither `set` objects, nor properly-constructed objects of the `set` subclass.

e.g. 
class Fooset(Set):
  def __new__(cls, s = []):
    print 'New called'
    self = super(Fooset, cls).__new__(cls)
    self.update(s)
    if isinstance(s, Fooset):
      self.foo = s.foo
    else:
      self.foo = 'default'
    return self

x = Fooset([1,2,5])
y = x|x


The object `y` reports being of the type `Fooset`, but has not been constructed by the `type` that makes `Fooset` objects.
msg169989 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-09-07 16:31
It is probably true that this is a bug, but subclasses of mutable classes do not normally override __new__.  (I'm curious what your use case is for doing so.)
msg169991 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2012-09-07 16:44
This was already fixed (in the 3.x releases) by issue1721812.
msg169997 - (view) Author: Jon Obermark (Jon.Obermark) Date: 2012-09-07 17:26
The closing author is correct, the use case is adequately covered by __init__, and that has been fixed in 3.  It makes sense this will not be backported.
History
Date User Action Args
2022-04-11 14:57:35adminsetgithub: 60083
2012-09-07 17:26:30Jon.Obermarksetmessages: + msg169997
2012-09-07 16:44:39amaury.forgeotdarcsetstatus: open -> closed

nosy: + amaury.forgeotdarc
messages: + msg169991

superseder: A subclass of set doesn't always have __init__ called.
resolution: out of date
2012-09-07 16:31:15r.david.murraysetnosy: + r.david.murray, benjamin.peterson
messages: + msg169989
2012-09-07 15:44:41Jon.Obermarkcreate