It appears that the main python.org page is announcing the release of 2.3.3
final, but the release page http://www.python.org/2.3.3/ does not show a
place to download the Windows executable.
Have I caught it in mid-transition?
i tried to reuse some code that i wrote for a project back when
python 2.0 and 2.1 were in use.
i must be about the only person in existence who wrote some code
that uses - and totally relies on - the rexec.py module.
what that code does (did) was to provide a database-based
method of running restricted programs for use to monitor and
manage remote servers.
i.e. it became in effect a distributed python operating system.
what happened was that the name of a python script, its
arguments, a relevant ip address and the server on which the
script was to be run were all entered into a database table,
and the server picked that up, loaded the script and its
arguments from the database and then ran the script, which
usually involved contacting the remote ip address.
so, not only was rhooks used to overload "import" such that
libraries used by scripts in the database could _also_ be
loaded from the database, but rexec.py was also used to restrict
what functions could be accessed.
i was quite happy with rexec.py as it stood.
it was the c++ functional equivalent of the "protected" convention
for c++ classes.
at the time that i tried to reuse the code, i discovered the lovely
"this module is broken in python 2.2 and 2.3" message.
well, uhm, if it's broken, why hasn't it been reverted to the 2.0
i noted, some time about a year ago, that someone attempted to drill
down the rexec security into sub-modules.
i.e. they attempted to add the c++ functional equivalence of
the "private" convention for c++ classes.
consequently, a number of routines that wrote to files that i had
DELIBERATELY wrapped and made available to first-level rexec-restricted
library routines, e.g. the logging functions which output debug
information to log files, suddenly stopped working.
why? whereas before, the debug routine could be called directly
but the write operation could not, because of the drill-down
effect, all of a sudden the write operation, as called _by_
the debug routine, is now restricted in the 2.1 (or early 2.2)
code, and my debug library routine now doesn't work, nor indeed
does anything else.
the thing is that the functionality of the python 2.0 rexec.py was
_exactly_ as i would have expected it to be, and it was working
_perfectly_ according to my expectations of that code.
i therefore believe that the attempts to take rexec one step further,
aka a "drill-down" effect, by making all functions that rexec functions
import _also_ restricted, to have been a mistake.
or, at least, not carefully thought out.
if such additional restrictions are to be added, i believe that they
should be added as a user-configureable parameter (e.g. named
_please_ could the functionality of rexec.py be restored to python 2.0
functionality, with the "rexec.py is broken" message only coming
up when the suggested-named parameter "recursive-restrict" is set.
maybe then i can consider reviving that code and re-releasing it,
because at the moment it's totally going to waste.
many many thanks,
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
then expecting someone to call you (and to be able to call you).
every day, people send out email expecting it to be received
without being tampered with, read by other people, delayed or
simply - without prejudice but lots of incompetence - destroyed.
please therefore treat email more like you would a CB radio
to communicate across the world (via relaying stations):
ask and expect people to confirm receipt; send nothing that
you don't mind everyone in the world knowing about...
> ... INSTANCES of 'file' and could access
> f.__class__. [...] so for restricted code we return something
> like this:
> class FakeFile:
> def __eq__(self, other):
> return other == file
> Are you aware of the original issue, which is that as soon as you have
> a file *instance* (which might have been given to you by a very
> restrictive open() variant), you can always get to the file *class*
> using the __class__ attribute? Access to the __class__ attribute is
> useful for all sorts of reasons.
Yes, I'm aware of that issue... in fact that's what I'm trying to
address here, but I'm obviously not doing a good job of expressing
myself. I was thinking of the restricted code having access to an
instance of 'file' named 'myFileInstance'. This instance has peculiar
behavior when you access 'myFileInstance.__class__'. Instead of
returning the class object 'file', it returns a class object like
'FakeFile' (which I *should* have made a subclass of 'type').
This whole plan is based on two misconceptions. The first is that
access to __class__ is the only way to use introspection to access
things of greater power (like the class) from an instance. It's
NOT the only way, I'm just hoping that the others can be fully
enumerated (somewhat shaky, but perhaps possible) and can be fixed
in similar ways (maybe true). The other misconception (apparently)
is that the only real USE for accessing the __class__ attribute
is for testing class membership. You said above that it's useful
"for all sorts of reasons"... I'm wondering what they are.
And yes... I *also* realize that there's not a whole lot of
difference between an instance which behaves oddly under
introspection and one which is wrapped in a proxy. But I realize
that providing a secure proxy is somewhat difficult and I'm
wondering if the other approach is more useful.
> Yes, even for 3.0 this is still a dream...
True enough. So feel free to just drop the issue if you've got
better (ie, more immediate) things to spend your time on. I
wouldn't want to see you get a pie by default because there
wasn't time to complete a test suite!
-- Michael Chermside
I am +10e6 on disambiguating imports.
I am +0 on "scan".
I am +0.01 on "explicit relative".
I can live with any syntax Guido can, so I'm just voting on
The use cases for "ambiguous" imports amount to:
1) I use this cool package, but I'm too lazy to keep up with
new releases or document the release required & ensure
that it's available & further I'm so arrogant that I don't care
that my users might run into problems having 2 copies of
the code or that the package developer might be offended
by my end run.
2) I structured my package wrong, and now I want to fix
it with the mouse.
I'm not sure I go as far as Tim, but I think perhaps the PSU
should have a regulation about writing import hooks without
The python-mode.el file in the python-mode project is now at 4.41, while the
version in Python's Misc directory is still at 4.38. Is there a way to sync
them in one cvs operation so they have the same version?
Michael Chermside <mcherm(a)mcherm.com>:
> > In light of this, it may have been a serious mistake to
> > unify the 'file' type and the 'open' function. Is it too
> > late to back out of that decision?
> > I think so.
> I disagree. Right now, having access to a class object basically
> gives one the ability to create new objects of that type. I
> think that's just fine... and I don't mind applying it to the
> file object. I'd think that the thing to do with untrusted code
> is to deny it access to the 'file' type object, thus denying it
> the ability to create new 'file's directly.
It would be a lot better if we could get away from the idea
of a "restricted mode" in the sense of a flag somewhere that
a bunch of things have to take notice of in order to behave
securely, because that model of security is prone to springing
leaks -- as happened in a big way when new-style classes were
The spirit behind my suggestion was to start thinking about
ways in which functionality could be separated out so that
this kind of special-casing for security purposes isn't
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
Today I got the wheels turning on my masters thesis by getting an
adviser. Now I just need a topic. =) The big goal is to do something
involving Python for a thesis to be finished by fall of next year (about
October) so as to have it done, hopefully published (getting into LL4
would be cool), and ready to be used for doctoral applications come
So, anyone have any ideas? The best one that I can think of is optional
type-checking. I am fairly open to ideas, though, in almost any area
involving language design.
There is no deadline to this, so if an idea strikes you a while from now
still let me know. I suspect I won't settle on an idea any sooner than
December, and that is only if the idea just smacks me in the face and
says, "DO THIS!" Otherwise it might be a while since I don't want to
take up a topic that won't interest me or is not helpful in some way.
Python's Doc/ tree is closed on the release23-maint branch. Commits
may still be made on the trunk.
The final 2.3.3 documentation will appear in the development area on
The branch will be open once the 2.3.3 release has been completed.
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation