headers
Uwe Schmitt | 1 Feb 2003 01:30
Picon
Picon

rexec/bastion

Hi,

I heard at comp.lang.python that rexec/bastion have
some security holes.
Accidentily I wrote some "sandbox" code for
integrating python into a mathematical appcliation:
users should be able to write some mathematical
functions of their own without doing harm.
So, I'd really be interested if my implementation
is safe, or if has the same drawbacks as
rexec/bastion.
The code with some demonstrations can
be downloaded from
http://pythonstuff.procoders.net.
I'd really appreciate any comments.

Greetings, Uwe Schmitt
Permalink | Reply | 1 comment |
headers
Skip Montanaro | 1 Feb 2003 02:28
Picon
Favicon

Re: rexec/bastion

    Uwe> Accidentily I wrote some "sandbox" code for integrating python into
    Uwe> a mathematical appcliation: ....  The code with some demonstrations
    Uwe> can be downloaded from http://pythonstuff.procoders.net.  I'd
    Uwe> really appreciate any comments.

Uwe,

Your request is more appropriately posted to c.l.py (as in, it's not
appropriate for python-dev, so by default c.l.py is a better choice ;-).
The python-dev list is focused on Python development, not issues related to
specific applications.  I don't know just what the rexec/bastion holes are,
but I've been led to believe they got much bigger when new-style classes
became available.

Skip
Permalink | Reply | 0 comments |
headers
Brett Cannon | 1 Feb 2003 03:21
Picon

Re: StringIO not an iterator?

[Guido van Rossum]

> Well, maybe StringIO should be upgraded to be a self-iterator, to
> more resemble files.
>
> And cStringIO should probably be fixed as well.
>
> Someome please check in the changes, upload a patch to SF, or at least
> enter a bug report at SF!
>

Done; bug #678519 .

-Brett
Permalink | Reply | 0 comments |
headers
Roman Suzi | 1 Feb 2003 08:31
Picon

Python roadmap


Dear Guido and other no less respected Python developers,

latest discussion in python-dev troubles me and some other
Python users, because what is being discussed are details.

Maybe for the sake of clarifying your vision of future Python
features it is more beneficial to make an overall roadmap 
where many planned paths and roads will be marked.

When this will be clear to all, it will be easier to 
invent (or re-invent) new syntax for features.

For example, what is the Python plan for new OO-features?
Are interfaces to go into Python? Etc.

What about new control structures? Are they really needed?

Etc.

There are many PEPs (trees), but what the Python (forest)
will be like?

--

-- 
Sincerely yours, Roman Suzi
rnd <at> onego.ru =\= My AI powered by Linux RedHat 7.3
Permalink | Reply | 10 comments |
headers
Fredrik Lundh | 1 Feb 2003 08:44
Gravatar

Re: Re: native code compiler? (or, OCaml vs. Python)

Brett Cannon wrote:

> > It's unclear to me that scheme is more dynamic than Python.
> 
> I don't think Scheme is more dynamic either.

from a language runtime perspective, I don't think Smalltalk is
more dynamic either.

I'm still waiting for the Parroteers to prove me wrong.

</F>
Permalink | Reply | 1 comment |
headers
Ben Laurie | 1 Feb 2003 13:06
Picon

Re: Capabilities in Python

Ka-Ping Yee wrote:
> Wow, how did this topic end up crossing over to this list while
> i wasn't looking?  :0
> 
> Ben Laurie wrote:
> 
>>I'll admit to being that person. A capability is, in essence, an
>>opaque bound method. Of course, for them to be much use, you
>>want the system to provide some other stuff, like not being able
>>to recreate capabilities (i.e. you get hold of them from on
>>high, and that's the _only_ way to get them).
> 
> 
> Jeremy Hylton wrote:
> 
>>That seems like a funny defintion of a capability.
> 
> 
> A better definition of "capabilitiy" is "object reference".
> 
> "Bound method" isn't enough, because a capability should be able
> to have state, and your system should have the flexibility to
> represent capabilities that share state with other capabilities,
> or ones that don't.  The simple, straightforward way to model this
> is to just equate the word "capability" with "object reference".

You can it that way, too, but it strikes me as more unwieldy in 
practice. A bound method also has state because it is, of course, bound 
to an object reference, so I find that a more elegant way to do it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Sugalski | 1 Feb 2003 16:52
Favicon

Re: Re: native code compiler? (or, OCaml vs. Python)

At 8:44 AM +0100 2/1/03, Fredrik Lundh wrote:
>Brett Cannon wrote:
>
>>  > It's unclear to me that scheme is more dynamic than Python.
>>
>>  I don't think Scheme is more dynamic either.
>
>from a language runtime perspective, I don't think Smalltalk is
>more dynamic either.
>
>I'm still waiting for the Parroteers to prove me wrong.

You'll probably be waiting a long time--it's generally off topic for 
the list, most people who aren't convinced won't believe me anyway, 
and I don't really care enough about this to put in the effort to 
convince you.
--

-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan <at> sidhe.org                         have teddy bears and even
                                       teddy bears get drunk
Permalink | Reply | 0 comments |
headers
Raymond Hettinger | 1 Feb 2003 18:20
Favicon

Re: Python roadmap

From: "Roman Suzi" <rnd <at> onego.ru>
> Maybe for the sake of clarifying your vision of future Python
> features it is more beneficial to make an overall roadmap 
> where many planned paths and roads will be marked.

Guido can speak to the future; Python 2.3 speaks 
to the near future:

* no new syntax
* only one new builtin function
* the bool type for readability
* several new or improved library modules enriching
   the list of what can be done easily or quickly in python.
* several usability improvements (extended slices, codec callbacks,
   use of zip archives, support for international source encodings).
* many bug fixes and performance enhancements
* constantly improving documentation and a more complete test suite

Who wouldn't want all that?

Raymond Hettinger
Permalink | Reply | 6 comments |
headers
Armin Rigo | 1 Feb 2003 18:31
Favicon

Re: Extended Function syntax

Hello,

On Thu, Jan 30, 2003 at 09:02:23PM -0500, Guido van Rossum wrote:
>   v = e:
>      S
> 
> would be equivalent to
> 
>   v = e(T)

Just to throw more oil on the fire, note that this looks quite a lot like

    for v in e:
        S

For example, it is quite messy but you can already define 'newproperty' to let
you do the following in 2.2:

    class X:
       for count in newproperty:
          def get(self):
             return self._count
          def set(self, value):
             self._count = value

Similarily you can "almost" already write the following for locks:

    for _ in acquired(lock):
        ...
(Continue reading)

Permalink | Reply | 75 comments |
headers
Armin Rigo | 1 Feb 2003 18:31
Favicon

Re: Extended Function syntax

Hello,

On Tue, Jan 28, 2003 at 05:44:26PM -0500, Guido van Rossum wrote:
> >     class Parrot(object):
> >         _count = 0
> >         class count(Property):
> >             """The count property."""
> >             def __get__(self):
> >                 return self._count
> >             def __set__(self, value):
> >                 self._count = value
> >             def __del__(self):
> >                 self._count = 0
> 
> These all abuse the class keyword for something that's definitely not
> a class.  That's a fatal flaw.

Too bad Python's metaclasses are powerful enough for doing all the kind of
things that a macro system could do without actually manipulating the syntax,
if it is to hear that actually doing so is fatally flawed :-(

Armin
Permalink | Reply | 2 comments |

Gmane