On 7/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:
> On 7/5/06, *Greg Ewing* <[EMAIL PROTECTED]

>     And I would change file() so that it didn't open
>     files. Then it would be harmless for code to have
>     access to the file class.

> Right, that is essentially what I proposed initially with the whole
> crippling idea.
>
> What the capabilities supporters are saying is that if we go that route
> we will be constantly finding objects that require similar crippling.

We've got our wires crossed somewhere. I *am* a capabilities
supporter. But for a capability model to work, the capabilities
need to be isolated and encapsulated in functions or objects
that can be independently provided or not provided. In the
case of file(), that means separating the capability of
being able to open a file from the capability of accessing
an already-opened file. These two things are currently
conflated in the file class.

OK, putting that way makes sense for labelling it as capabilities support.  It just seems like everyone else who has been calling for more capabilities have not been wanting to change file() in any way.

BTW, I object to the term "crippling" in this particular
case. If you have access to open(), there's no need for
file() to be able to do the same thing. And if you don't
have access to open(), it's because someone doesn't want
you to be able to open files.

 But, from the perspective of what file() can do now, it is losing an ability that it once had and not quite as powerful as it was.


-Brett
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to