[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 
> interpreter.
>
>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 mailing list