[Python-Dev] [Python-ideas] CapPython's use of unbound methods

Guido van Rossum guido at python.org
Tue Mar 31 17:12:11 CEST 2009


[Adding back python-dev, I don't want this discussion fragmented.]

Denis,

I am arguing with Mark because he and others claim that it is possible
to add capabilities to Python *without* changing the flavor of the
language (much), and because he believes that using a subset of Python
is somehow helpful for Python programmers (or helps Python programmers
transitioning to CapPython). I'm trying to point out the limitations
of that approach.

In the past capability zealots have also requested forcefully that
Python should support capabilities natively. This sounds like an
unrealistic evolutionary path for the language, and I'm pointing that
out. (Certainly I don't see CapPython as a step in that direction --
perhaps Tav's approach could be.) If they are happy with a different
language that happens to resemble Python is some syntactic details
that would be fine of course, but then they shouldn't whine that Py3k
breaks their implementation.

I also suspect that Mark's approach might be easily crackable because
he doesn't know the CPython implementation well enough to be aware of
all possible attack vectors.

--Guido

On Tue, Mar 31, 2009 at 4:22 AM, spir <denis.spir at free.fr> wrote:
> Le Mon, 30 Mar 2009 16:19:51 -0500,
> Guido van Rossum <guido at python.org> s'exprima ainsi:
>
> [...]
>> > Fortunately CapPython does not have to make this kind of semantic
>> > change.
>>
>> Well of course it makes a much more severe semantic change by
>> declaring illegal all use of attribute names starting with underscore.
> [...]
>
> Hello,
>
> I wonder what's the meaning of this exchange. As I understand it, the point of CapPython is precisely to build a different dialect which semantic field is restricted, in order to comply with the so-called "Object-Capability" security guidelines.
> We may like it or not. So what? I won't use CapPython, but I'm pleased to see people do language experiments on a Python basis.
> Now, I also understand this: if ever for you CapPython breaks fondamental design choices, then you may not like, as Python inventor, this projects to be called *Python. I would even agree, from a moral point of view, with a demand for a name change.
>
> (Sorry if this sounds a bit rude. Not sure of idiom connotations in english. I prefere clarity to hypocrisy.)
>
> Denis
>
> PS: I had a kind of ProtoPython in mind. If ever someone comments that it's a major semantic change; that it does not let pythonistas use their beloved class-ic idioms; then I'll just laugh... Yes, it's even a major cognitive change. This is precisely the intent. So what?
>
> ------
> la vita e estrany
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list