[Python-3000] Reminder: Py3k PEPs due by April
Phillip J. Eby
pje at telecommunity.com
Tue Apr 10 22:47:44 CEST 2007
At 12:25 PM 4/10/2007 -0700, Brett Cannon wrote:
>On 4/10/07, Phillip J. Eby
><<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:
>>At 12:03 PM 4/10/2007 -0700, Brett Cannon wrote:
>> >2. Remove file.__init__, code.__init__, and object.__subclasses__ for
>> >security reasons.
>>The __subclasses__ method is useful -- even more so in 3.x than in 2.x,
>>because in 3.x there are no classic classes.
>>I was planning to make use of this in my generic function libraries to
>>allow automatic checking for completeness and ambiguity of a ruleset, given
>>the classes that are currently defined. Currently, this is limited by the
>>inability to access classic classes' subclasses, but in 3.x __subclasses__
>>is an ideal way to locate active classes.
>The problem with it, though, is it does expose *so* much.
From my POV, that's a feature, not a bug. :)
> If I have a class defined that is not exposed within the interpreter
> but is live in the process, I can still get to it with this
> method. That's a problem if the class has a security component to it
> where there is a class attribute that should not be exposed within the
>This can be discussed more if/when I get my security paper out in the
>public and get a PEP written to actually push for the removals.
If you're using a capabilities-based system (or a multiparadigm system like
Zope 3's zope.security), it's easy enough to restrict access to special
attributes like __subclasses__ (or for that matter, any other sensitive
attributes), so I don't see why the feature itself needs to be removed.
More information about the Python-3000